I'm not whether this sort of approach will serve your needs,

> p := proc(t::uneval,d)
> global ptable;
>   ptable[d]:=eval(t);
>   plotsetup('jpeg',plotoutput=d);
>   eval(t);
> end proc:

> p( plot(tan(x),x=-Pi/2..Pi/2), "t.jpg" );

> plotsetup('default');
> plots:-display(ptable["t.jpg"]);

If you have many such plots to produce, then you can automatically generate the filenames within Maple, using the cat() command. See here for an example.

The procedure p() above will generate the plot datastructure and both save it to a file as well as store it in a globally accessible table. Once done, the code above shows how to reset the plot device and then view such plots stored in that table, all within the same Maple session.

What might be harder is to set things up to that each plot is visually displayed at the same time as it gets saved to a file, instead of after control returns (to the top level?!).

Looking at this again, I suppose that the uneval on parameter t, and the two calls to eval(), are unnecessary. They just make Maple work twice as hard to generate the plot structure, once for each purpose. Better would be generating the plot structure just once (normal evaluation rules on procedure 'p' would suffice).

acer

Try using using the parse() command.

acer

You are using the older (and now deprecated) matrix & vector objects, which are based in the array structure and so have last name evaluation rules. See the ?last_name_eval help-page.

Switch to uppercase Matrix and Vector objects, and the LinearAlgebra package for dealing with them. Those objects do not have last name evaluation rules.

If you really do insist on using the older structures here, look also at the ?evalm help-page.

acer

In both Maple 11.02 and 12.00, plot(x^2,x=-1..1,legend=phi) worked for me in the Standard GUI.

In Maple 10, it seemed to work OK if I did this,

plot(x^2, x=-1..1, labelfont=[TIMES], font=[SYMBOL], legend = f);

Which version, and interface, are you using?

acer

Even if you get the calculator, at some point in your studies you might well wish to try Maple too. It's a great deal of power for the cost of the student version (much lower than full pricing, but with the same functionality).

Many books on Maple are listed here.

acer

Why are you so sure that calculators all use a series approximation instead of, say, polynomial interpolation alongside table lookup, continued fractions, or a digit-by-digit method?

You might find BKM and CORDIC interesting.

acer

How could we give a sensible reply, with absolutely no information at all about what it is that your computations are doing?

acer

The last time the I looked, so-called wrapperless external calling for C did not work with complex values for returns. One had to use the older, "wrapper-generating" form of external calling.

What happens, if you put WRAPPER in as a first argument to your define_external() call? With C, that makes it write out and compile an actual wrapper file, and link to the resulting dll that it forms (without linking to maplec.dll a runtime stub for wrapperless calling). Maybeit is the same for Fortran, that it would write out a wrapper and compile that, and link it all up (without also linking the resulting dll against maplefortran.dll).

I would try that, with the second version you had above in which a complex[8] return value is expected.

Of course, to use the wrapper-generating forms of define_external, one usually must have the compiler and linker tools availiable in the shell path from which Maple was started. (The compiler/linker values and flags may also be overwritten in maple record/module, however.)

In the first version of external calling, in Maple 6, only such a wrapper-generating version was available. Now there are maplec.dll and maplefortran.dll "runtimes" for it, and no compiler is needed if one already has a working dll.

acer

implicitplot(G, 0..1, 0..1);

plots[implicitplot](G, 0..1, 0..1, grid=[100,100]);

implicitplot('G'(x,y), x=0..1, y=0..1);

Remember that Maple usually evaluates the arguments of procedures, right away, when they are passed. So when you pass G(x,y) in as an argument what implicitplots sees is an unevaluated Int, the result just like you see when you issue G(x,y) by hand. Confusion about the indets of that are likely what follows. Two workarounds, like above, are to either pass G as an operator alone, or to delay the evaluate of G(x,y) when it gets passed in.

Yet another way is to have G return with the same unevaluated call if x and y are not numeric. That is,

> G := proc(x,y)
> if not ( type(x,numeric) and type(y,numeric) ) then
> return 'procname'(args);
> end if;
> evalf(F(x) - y);
> end proc:

> G(x,y);
                                    G(x, y)

> G(1,2);
                                      -2.

> implicitplot(G(x,y), x=0..1, y=0..1);

acer

Oh, maybe the length is not so bad after all, on account of the structure.

> p := proc(n, x)
> local res, i;
>   res := Matrix(n, n);
>   for i to n do res[i, i] := x[i, i] end do;
>   for i to n - 1 do
>     res[i + 1, i], res[i, i + 1] := x[i + 1, i], x[i, i + 1]
>   end do;
>   res
> end proc:

> p(3,t);
                        [t[1, 1]    t[1, 2]       0   ]
                        [                             ]
                        [t[2, 1]    t[2, 2]    t[2, 3]]
                        [                             ]
                        [   0       t[3, 2]    t[3, 3]]
 
> length(LinearAlgebra:-MatrixInverse(p(3,t)));
                                     1464
 
> length(LinearAlgebra:-MatrixInverse(p(11,t)));
memory used=122.4MB, alloc=9.2MB, time=4.37
                                    2610924

So now I'd ask, what commands were tried, that led to the huge memory use? Could the code be posted?

acer

Do you mean that you have a tridiagonal 11x11 Matrix where each and every entry (in the main, first sub-, and first super-diagonal) are nonzero and consist of distinct variable names?

I could envision that the general inverse of such a Matrix would contain entries with very large symbolic expressions in them. At each pivoting step of LU or Gaussian elimination, say, a division involving the previous row's large symbolic expression will result in the current row having even more complicated long expressions. I don't see that tridiagonality in itself would prevent that. Do the entries involve just a few names, or are you really trying to do it for the general form, with a distinct name for each nonzero entry? This could well be the sort of problem where the size of expressions in such a general result increase in length quickly, as the size of the Matrix rises. And It might take many pages just to print it.

So I would ask, what do you plan on doing with the solution? If you plan on substituting values into the solution then you might be better off switching that order of tasks: first instantiate, then solve.

acer

There are several possible mechanisms to accomplish this in Maple. In general, how to do it neatly might depend on how you want to identify the pieces -- that which to manipulate and that which to leave alone.

The following is quite specific to your particular example.

> expr := (1+x)*(1+2*x)^2:
> map(expand,expr,x+1);
                                                 2
                           (1 + x) (1 + 4 x + 4 x )
 
> expr := (1+x)^3*(1+2*x)^2:
> map(expand,expr,x+1);
                                  3               2
                           (1 + x)  (1 + 4 x + 4 x )

If you have other quite different sorts of examples then please post them.

acer

What happens if 0<x<1 and a is nonreal?

For example, when x=0.1 and a=I ?

acer

There are a variety of ways to try to accomodate the premature evaluation of operators when calling plot(), fsolve(), etc.

The error that you see occurs when fmax is evaluated at some non-numeric name such as t, or r, etc. Ie,

> fmax := proc(t)
> local solution;
>   solution := Optimization:-Maximize(f(x,y,t),{y>=x},x=t..1,
>   y=t..1, output=solutionmodule);
>   (solution:-Results)(objectivevalue);
> end proc:

> fmax(t);
Error, (in Optimization:-NLPSolve) could not store t in a floating-point rtable

One attempt, which you've shown, is to use unevaluation quotes, so as to delay the evaluation. I am not a fan of that, in general. It doesn't help in situations like yours. It delays the evaluation of fmax when entering fsolve, but not of the final unevaluated result when subsequently calling type.

Another attempt is to use operator form. For example fsolve(fmax,0..1). But for your example that doesn't work either, due to an unfortunate behaviour where fsolve immediately tries to instantiate the operator at a dummy variable. It then returns that unevaluated call (containing the dummy) in the case that no result was obtained. But then that unevaluated result, looking like fsolve(fmax(r)=0,r,0..1), cannot in turn be passed to type() since it'd cause fmax(r) to be evaluated.

Another way, which I prefer, is to write the procedure fmax so that it returns unevaluated on being supplied with nonnumeric input. Eg,

> fmax := proc(t)
> local solution;
>   if not type(t,numeric) then
>     return 'procname'(args);
>   end if;
>   solution := Optimization:-Maximize(f(x,y,t),{y>=x},x=t..1,
>                        y=t..1, output=solutionmodule);
>   (solution:-Results)(objectivevalue);
> end proc:

> fmax(t);
                                    fmax(t)

> a:=fsolve('fmax(t)'=0,t=0..1);
                      a := fsolve(fmax(t) = 0, t, 0 .. 1)

> type(a,numeric);
                                     false

Note that, with fmax defined as immediately above, it should then be possible to pass it to fsolve without the unevaluation quotes, ie.

fsolve(fmax(t)=0,t=0..1);

acer

Could you use the query type(a, numeric)?

acer