So that the TTY/commandline Maple interface people don't feel left out...

`\e[00m\e[03;31mThis is my text.\e[00m`;

It's the Thursday afternoon before the Friday before a long weekend.

acer

ps.

`\e[00m\e[05;35mTTY rules.\e[00m`;

I don't know of any help on this.

Here's what I did. I took your text and entered it as 2D Math input, surrounded by left-ticks in order to enter it as a name. I did not hit <Enter>. For example,

`this is my text`

Then I used my mouse to left-click-select the whole name, including the quotes. Then I used the top-menubar's Format->Character choice to change the color. I did this to that 2D Math input. Then I hit <Enter>, which returned output (which I ignored).

Then I entered the command lprint(%). I copied the output of that lprint call which was,

`#mi("\`this is my text\`",mathcolor = "red")`

What else can be changed in this way? I am not sure. One can add fontweight="bold" to get a bold look. I don't know whether the font, or its size, can also be changed.

There doesn't seem to be much available on programmatic typesetting. You could roll your own procedure that constructed such typeset-enhanced names by simply concatenating your input string/name with the decorating information.

acer

I don't know of any help on this.

Here's what I did. I took your text and entered it as 2D Math input, surrounded by left-ticks in order to enter it as a name. I did not hit <Enter>. For example,

`this is my text`

Then I used my mouse to left-click-select the whole name, including the quotes. Then I used the top-menubar's Format->Character choice to change the color. I did this to that 2D Math input. Then I hit <Enter>, which returned output (which I ignored).

Then I entered the command lprint(%). I copied the output of that lprint call which was,

`#mi("\`this is my text\`",mathcolor = "red")`

What else can be changed in this way? I am not sure. One can add fontweight="bold" to get a bold look. I don't know whether the font, or its size, can also be changed.

There doesn't seem to be much available on programmatic typesetting. You could roll your own procedure that constructed such typeset-enhanced names by simply concatenating your input string/name with the decorating information.

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

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