I agree with you that the task of wholly scripted generation of plots (in any interface of Maple) is important. As far as I know, that is not possible (in any interface) if the plot must have typeset 2D Math and be exported as bmp/gif/jpeg. For some people, the bit about it being wholly scripted is important.

The statement that commandline interface is not "intended" for plotting reads as doublethink for me.

But it could be true that there is no secret, hidden command to get the desired effects. In the commandline interface, plot will eventually call INTERFACE_PLOT. I suspect that is a call to something which is not a Library function, nor a kernel built-in, but rather a function of the interface itself. In Standard, there likely is java code which does the rest of the work, and in commandline it is something inside the cmaple binary.

Trying to fool the commandline interface, by some crude assignments like the following, didn't bypass anything.

IsWorksheetInterface():=true:
Plot:-CheckStandardInterface(('feature') = "caption"):=true:

Now consider, if the commandline interface can fire up the java runtime in order to throw up graphical plots when the plotdevice is set to 'maplets' (and indeed it can and does!) then it could in principle start it up to access Standard's plot export functions too. It should be fixable.

acer

Don't both Axel's and Alec's methods simply create new lists (via `map`) and overwrite the argument name with that? That's not much different from overwriting the name L one level higher with  the assignment L:=newvalues(L). Either way, new lists get created, which is unnecessary creation of structures that will need to get garbage collected.

As far as I know, substituting into a list also does a list copy (although it may render the original immediately garbage-collectible). It too is inefficient and unnecessarily produces garbage.

Perhaps you could use a table for this, as an efficiently mutable data structure? Or an Array, if the number of elements is fixed.

If the task is a highly recursive one then efficiency issues (such as the cost of the extra garbage collection of the unnecessary data structures) may make a big impact on performance.

By "great shortcut" did you mean that you found it easier to code, using side-effects on list argument names, or that you found it ran faster? Could it not be done easily with tables or Arrays, with extra saving to kernelopts(bytesused)?

acer

Don't both Axel's and Alec's methods simply create new lists (via `map`) and overwrite the argument name with that? That's not much different from overwriting the name L one level higher with  the assignment L:=newvalues(L). Either way, new lists get created, which is unnecessary creation of structures that will need to get garbage collected.

As far as I know, substituting into a list also does a list copy (although it may render the original immediately garbage-collectible). It too is inefficient and unnecessarily produces garbage.

Perhaps you could use a table for this, as an efficiently mutable data structure? Or an Array, if the number of elements is fixed.

If the task is a highly recursive one then efficiency issues (such as the cost of the extra garbage collection of the unnecessary data structures) may make a big impact on performance.

By "great shortcut" did you mean that you found it easier to code, using side-effects on list argument names, or that you found it ran faster? Could it not be done easily with tables or Arrays, with extra saving to kernelopts(bytesused)?

acer

I didn't understand the original question correctly, sorry. I don't know a way to get typeset greek symbols (or 2D Math) into a bmp/gif/jpeg image of a plot directly from the commandline interface, using only scripted Maple.

acer

I didn't understand the original question correctly, sorry. I don't know a way to get typeset greek symbols (or 2D Math) into a bmp/gif/jpeg image of a plot directly from the commandline interface, using only scripted Maple.

acer

Taking your plot above as an example, in the Standard GUI I might do it something like this,

plotsetup(ps,plotoutput="/tmp/foo.ps"):

plot(sin(x),x=-Pi..Pi,caption=typeset(y=sin(x),", ",-Pi < x,`< `,Pi));

That produces the plot in the output file, with the greek symbol for pi, and no mouse action required.

It would be nice the mathematical typsetting power separated away from Maple's semantic preconceptions. See above, the trick needed to typeset pi < x < pi.

I don't know of a way entirely programatically to get the symbol for pi in the output file from the commandline interface, without resorting to textplot and changing the font in the plot call. In that interface, one can also issue plotsetup(maplets) and then export with the mouse from the pop-up plotting Maplet's menu. But it's not the same.

acer

Taking your plot above as an example, in the Standard GUI I might do it something like this,

plotsetup(ps,plotoutput="/tmp/foo.ps"):

plot(sin(x),x=-Pi..Pi,caption=typeset(y=sin(x),", ",-Pi < x,`< `,Pi));

That produces the plot in the output file, with the greek symbol for pi, and no mouse action required.

It would be nice the mathematical typsetting power separated away from Maple's semantic preconceptions. See above, the trick needed to typeset pi < x < pi.

I don't know of a way entirely programatically to get the symbol for pi in the output file from the commandline interface, without resorting to textplot and changing the font in the plot call. In that interface, one can also issue plotsetup(maplets) and then export with the mouse from the pop-up plotting Maplet's menu. But it's not the same.

acer

I'm not sure why maplemint is still a Library routine, when it is not kept as up-to-date as the standalone executable `mint` and also does not have as many options.

Perhaps the maplemint command should be changed, to simply call out to mint. Here's a really crude Linux-specific version of that, just to illustrate.

> mint := proc(f,extras::string:="")
> local fname,oldiface;
>   fname := "/tmp/foo";
>   oldiface := interface('verboseproc');
>   interface('verboseproc'=3);
>   writeto(fname);
>   printf("%a := ", f);
>   print(f);
>   printf(":\n");
>   writeto(terminal):
>   fclose(fname);
>   interface('verboseproc'=oldiface);
>   system(cat("/usr/local/maple/maple12.01/bin/mint ",extras," ",fname));
>   NULL;
> end proc:
>
> mint(`convert/CompSeq`);
    |\^/|      Maple 12 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2007
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |
Procedure convert/CompSeq( e1 ) on lines 1 to 77
  These local variables were used but never assigned a value:  result
>
> mint(`convert/CompSeq`,"-i 3");
    |\^/|      Maple 12 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2007
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |
Nested Anonymous Procedure proc( s ) on lines 44 to 56
  There are 2 equations used as statements on lines 50, 54
  Global names usage:  `&:=`, `&function`
Procedure convert/CompSeq( e1 ) on lines 1 to 77
  These local variables were used but never assigned a value:  result
  Global names usage:  `&%`, `&%%`, `&%%%`, `&ERROR`, `&RETURN`, `&args`,
      `&break`, `&done`, `&expseq`, `&for`, `&function`, `&hashtab`, `&if`,
      `&local`, `&next`, `&proc`, `&quit`, `&read`, `&save`, `&series`,
      `&statseq`, `&stop`, CompSeq, globals, locals, params, `||enate`
Global names used in this file:  `convert/CompSeq`

There are many ways to improve the above, naturally. The call to `system` could be replaced by an appropriate `ssystem` call, so that the ascii description at the top of mint's output could be removed. And it could be platform independent, etc, etc.

acer

Yes, I see what you mean.

I suppose that I am just not a fan of such side-effects on argument names, in cases where the task can be programmed by other more straightforward means.

For example, without using lists, it seems to me as if this example can be done most simply by using multiple assignments,

> f := proc(x,y) x+1,y+1; end proc:

> a,b := f(a,b);
Error, recursive assignment

> x,y := 10,20:
> x,y := f(x,y):
> x,y;
                                    11, 21

I realize that the OP and learned responders here would think of that easily, and that it's nothing special. To me, it seems the best way to go. When programming from the top-level, there is some additional protection against recursive assignment. But even more importantly, the straightforwardness makes it harder for the non-expert to get in a muddle.

acer

Yes, I see what you mean.

I suppose that I am just not a fan of such side-effects on argument names, in cases where the task can be programmed by other more straightforward means.

For example, without using lists, it seems to me as if this example can be done most simply by using multiple assignments,

> f := proc(x,y) x+1,y+1; end proc:

> a,b := f(a,b);
Error, recursive assignment

> x,y := 10,20:
> x,y := f(x,y):
> x,y;
                                    11, 21

I realize that the OP and learned responders here would think of that easily, and that it's nothing special. To me, it seems the best way to go. When programming from the top-level, there is some additional protection against recursive assignment. But even more importantly, the straightforwardness makes it harder for the non-expert to get in a muddle.

acer

I'm not sure how try..catch would help in those two particular routines. But, perhaps you meant more generally, and in which case I'd agree.

Calls to those two routines complete OK, even when x and y have not yet been assigned. But does not subsequent accessing of either x or y throw maple into an endless recursion?

acer

I'm not sure how try..catch would help in those two particular routines. But, perhaps you meant more generally, and in which case I'd agree.

Calls to those two routines complete OK, even when x and y have not yet been assigned. But does not subsequent accessing of either x or y throw maple into an endless recursion?

acer

One can observe what happens if `inc` (or Robert's `test2`) are called in the case that x and y have not yet been assigned with values.

It's not that those solutions are badly implemented. It's more that the goal is suspect.

There's always added risk of coding up a recursive assignment inside a procedure. But this request seems almost to go looking for a bit of trouble.

acer

One can observe what happens if `inc` (or Robert's `test2`) are called in the case that x and y have not yet been assigned with values.

It's not that those solutions are badly implemented. It's more that the goal is suspect.

There's always added risk of coding up a recursive assignment inside a procedure. But this request seems almost to go looking for a bit of trouble.

acer

See the ?LinearAlgebra,GenerateMatrix help-page.

acer