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

Are you going to be looking for floating-point or exact final results? If floating-point, then do you suspect that there might be any numerical difficulties encountered when using 'solve' as an intermediate exact solver here? Do you know anything about X, such as whether it might be symmetric?

I ask all this only because there is a LAPACK routine dtgsyl which might be of interest, depending on the answers to my questions above. There might already be a somewhat nicer interface to using it in Maple 12 (ie. nicer than setting up one's own external call to it, and already handling transformation to Schur form as an initial step).

> restart:
> kernelopts(opaquemodules=false):
>
> eval(DynamicSystems:-SylvesterSolve);
proc(A, trana, schura, B, tranb, schurb, C, isgn, $)
description "solve the Sylvester equation A . X + X . B = C"
     ...
end proc
 
> eval(DynamicSystems:-`SylvesterSolve/HardwareTable`);
table([(complex[8], rectangular) = [ztrsyl_],
       (float[8], rectangular) = [dtrsyl_]
    ])

acer

You might try simplifying the expression under certain assumptions on the variables.

For example,

> expr := sqrt(a^2*p*(1-p)*(N-n)/(n^2*(N-1))):

> simplify(expr) assuming n::real, a::real, p>0, p<1, N>1;
                       1/2        1/2        1/2
                      p    (1 - p)    (N - n)    | a/n |
                      ----------------------------------
                                         1/2
                                  (N - 1)

You might also wish to consider the explanation of the 'symbolic' option of the simplify() routine, as it appears in the help-page ?simplify,details.

acer

Have a look at the help-page ?Optimization,Options and search for the feasibilitytolerance option. It can be used to pass a specific value of the allowed violation in the constraints.

> restart:

> with(Optimization):

> cnsts := {x1+x2+x3+x4+x5 >= 1,
>  x1+x2+x3+x11+x6 >= 1, x7+x9+x10+x4+x5>=1,
>  x7+x9+x10+x4+x5 >= 1, x7+x9+x10+x11+x6 >=1,
>  x8+x9+x10+x4+x5 >=1, x8+x9+x10+x11+x6 >=1}:

> obj := x1+x2+x3+x4+x5+x6+x7+x8+x9+x10+x11:

> sol := LPSolve(obj,cnsts,assume={nonnegative}):

> eval(convert(cnsts,list),sol[2]);
[1 <= 1.000000000, 1 <= 0.9999999990, 1 <= 1.000000000, 1 <= 0.9999999990,
 
    1 <= 1.000000000, 1 <= 0.9999999990]
 
> sol2 := LPSolve(obj,cnsts,assume={nonnegative},
>                 feasibilitytolerance=0.1e-13):

> eval(convert(cnsts,list),sol2[2]);
[1 <= 1.000000000, 1 <= 1.000000000, 1 <= 1.000000000, 1 <= 1.000000000,
 
    1 <= 1.000000000, 1 <= 1.000000000]

I suppose that it might not always make sense to set that tolerance very small without also increasing the working precision.

You can also set infolevel[Optimization]:=3 and see which value gets used for that tolerance, even when you don't specify it yourself as an optional argument.

acer