That is nicely explained, and better laid out than a previous similar suggestion of mine.

Darin, would you be able to explain Joe's questions?

acer

That is nicely explained, and better laid out than a previous similar suggestion of mine.

Darin, would you be able to explain Joe's questions?

acer

This doesn't relate to the OP, but... names of type local can be assigned to variables and then be saved, but the localness can get lost.

> restart:

> t:=`tools/gensym`(x);
                                    t := x
 
> type(t,`local`);
                                     true
 
> save t, "temp.m":

> restart:

> t;
                                       t
 
> read "temp.m";
> t;
                                       x
 
> type(t,`local`);
                                     false

So I would not say that such locals are successfully saved.

I suspect that the inability of ".m" format to handle such locals might be why they do not work properly when conveyed along the context-menu system. See here.

acer

This doesn't relate to the OP, but... names of type local can be assigned to variables and then be saved, but the localness can get lost.

> restart:

> t:=`tools/gensym`(x);
                                    t := x
 
> type(t,`local`);
                                     true
 
> save t, "temp.m":

> restart:

> t;
                                       t
 
> read "temp.m";
> t;
                                       x
 
> type(t,`local`);
                                     false

So I would not say that such locals are successfully saved.

I suspect that the inability of ".m" format to handle such locals might be why they do not work properly when conveyed along the context-menu system. See here.

acer

Yes, the arctrig in Units Standard don't return any units (not even the "dimensionless" radian), so they don't lend themselves well to this treatment using arcdegrees. That's bothered me before. It's likely that such units on the returned quantity would not always be wanted, though. So it becomes a question of how to design it so that it might be toggled on/off easily.

acer

Yes, the arctrig in Units Standard don't return any units (not even the "dimensionless" radian), so they don't lend themselves well to this treatment using arcdegrees. That's bothered me before. It's likely that such units on the returned quantity would not always be wanted, though. So it becomes a question of how to design it so that it might be toggled on/off easily.

acer

Precise calculation of angles and trig, using standard terms, can be done already. Several levels of control are possible, including control over degrees vs radians in exact output, and arcdegree vs degree for input terminology.

> restart:

> x:=28*Unit(arcdeg)+Unit(arcmin)+10*Unit(arcsec);
                   x := 28 [arcdeg] + [arcmin] + 10 [arcsec]

Now load the Units:-Standard subpackage, so that arithmetic terms combine automatically.

> with(Units:-Standard):

> Unit(28.0*arcdeg+1*arcmin+10*arcsec);
                             0.1556635803 Pi [rad]
 
> evalf(sin(%));
                                 0.4697711815

Now set the default unit for angular output as arcdegrees rather than radians.

> with(Units):

> UseSystem(AddSystem(SI,degree[angle])):

> Unit(28.0*arcdeg+1*arcmin+10*arcsec);                                 
                             28.01944445 [arcdeg]
> sin(%);
                                  0.4697711815

> Unit(28*arcdeg+1*arcmin+10*arcsec); 
                                10087
                                ----- [arcdeg]
                                 360

> sin(%);
                                     10087 Pi
                                 sin(--------)
                                      64800

Now make degree, minute and second refer by default to angular rather than temporal dimensions.

> Units:-UseContexts(angle);

> Unit(28.0*deg+1*min+10*sec);
                             28.01944445 [arcdeg]
 
> sin(%);
                                 0.4697711815

acer

Precise calculation of angles and trig, using standard terms, can be done already. Several levels of control are possible, including control over degrees vs radians in exact output, and arcdegree vs degree for input terminology.

> restart:

> x:=28*Unit(arcdeg)+Unit(arcmin)+10*Unit(arcsec);
                   x := 28 [arcdeg] + [arcmin] + 10 [arcsec]

Now load the Units:-Standard subpackage, so that arithmetic terms combine automatically.

> with(Units:-Standard):

> Unit(28.0*arcdeg+1*arcmin+10*arcsec);
                             0.1556635803 Pi [rad]
 
> evalf(sin(%));
                                 0.4697711815

Now set the default unit for angular output as arcdegrees rather than radians.

> with(Units):

> UseSystem(AddSystem(SI,degree[angle])):

> Unit(28.0*arcdeg+1*arcmin+10*arcsec);                                 
                             28.01944445 [arcdeg]
> sin(%);
                                  0.4697711815

> Unit(28*arcdeg+1*arcmin+10*arcsec); 
                                10087
                                ----- [arcdeg]
                                 360

> sin(%);
                                     10087 Pi
                                 sin(--------)
                                      64800

Now make degree, minute and second refer by default to angular rather than temporal dimensions.

> Units:-UseContexts(angle);

> Unit(28.0*deg+1*min+10*sec);
                             28.01944445 [arcdeg]
 
> sin(%);
                                 0.4697711815

acer

Isn't that time-hounoured way (using unprotection and replacement of the global/top-level routines) actually considerably worse? It seems a real stretch to call it better.

Doesn't the replacement method affect the instances of use of the name in routines stored in Maple's own Library archives? Not all such routines will be designed to use such a redefinition. But with the module approach, pretty much only interactive use gets the new name, while savelib'd routines continue to use the global name (eg. :-sin) that they expect and for which they were designed.

Apart from printing needs, it would also need Joe's trick of returning a call to 'procname' for a non-numeric argument. Otherwise sin(x); eval(%,x=30); will simply be wrong.

acer

Isn't that time-hounoured way (using unprotection and replacement of the global/top-level routines) actually considerably worse? It seems a real stretch to call it better.

Doesn't the replacement method affect the instances of use of the name in routines stored in Maple's own Library archives? Not all such routines will be designed to use such a redefinition. But with the module approach, pretty much only interactive use gets the new name, while savelib'd routines continue to use the global name (eg. :-sin) that they expect and for which they were designed.

Apart from printing needs, it would also need Joe's trick of returning a call to 'procname' for a non-numeric argument. Otherwise sin(x); eval(%,x=30); will simply be wrong.

acer

Why is the only answer you could use mainly the one with %(and which is that, by the way)?

I don't think that you've answered the question, at all, of just what is wrong with various approaches presented. What, precisely, are the outstanding problems and objections? I don't mean just examples, but a clear wording of what's wrong with them.

acer

Why is the only answer you could use mainly the one with %(and which is that, by the way)?

I don't think that you've answered the question, at all, of just what is wrong with various approaches presented. What, precisely, are the outstanding problems and objections? I don't mean just examples, but a clear wording of what's wrong with them.

acer

As far as I can tell, the most surefire solution is to run a Maple version only on an operating system (OS) which is or was officially supported for that version. A possible alternative might be to ensure that the glibc (and/or X runtime libs) as well as the JRE will match those of one of the officially supported distributions.

I have only seen the problem you describe on Linux distributions which are somewhat older that the officially supported ones. Perhaps you could try running your Maple 12.02 on a more recent distribution.

note: a clarification for anyone else reading, based on some earlier responses. This is not a problem with 2D Math output, or with any output. It's a redraw problem in the Standard GUI in which the whole session goes blank and is unresponsive for about 5-10sec merely upon pasting in input. It could even be 1D input pasted to a Worksheet, with trailing full colon.

acer

As far as I can tell, the most surefire solution is to run a Maple version only on an operating system (OS) which is or was officially supported for that version. A possible alternative might be to ensure that the glibc (and/or X runtime libs) as well as the JRE will match those of one of the officially supported distributions.

I have only seen the problem you describe on Linux distributions which are somewhat older that the officially supported ones. Perhaps you could try running your Maple 12.02 on a more recent distribution.

note: a clarification for anyone else reading, based on some earlier responses. This is not a problem with 2D Math output, or with any output. It's a redraw problem in the Standard GUI in which the whole session goes blank and is unresponsive for about 5-10sec merely upon pasting in input. It could even be 1D input pasted to a Worksheet, with trailing full colon.

acer

Well, exactly. And most of it is in the same highly inefficient style, so no wonder it is slow.

I'm not sure that it's good form to post other people's complete programs (especially when a link is possible, as Axel showed.)

acer