You can end the line with a colon (not the usual semicolon) and it will suppress printing all those pages of output.

evals := LinearAlgebra:-Eigenvalues(M):

If your resulting Vector has been assigned to a variable (above, evals) then you can access its elements as evals[1], evals[2], etc. Or, you can assign those to new variables.

a := evals[1]:

If you got the Vector of eigenvalues by using the context-menus (ie. by right-clicking on a Matrix and using the popup menus) then you can immediately refer to that Vector by using the % symbol. In Maple, % means the "last thing evaluated". See the help-page on topic ditto. For example, you could do as follows.

evals := %:
evals[1];

Your question is not a bad one. It's quite normal to want to simply enter a command like Eigenvalues(M) without assigning it to anything. And then, when it's finished, you want to assign it to some variable without having to wait while recomputing the whole thing. The %, %%, and %%% constructs let you do just that.

The help-page is named "ditto", because many releases ago the symbols for this were double-quotes (") rather than percent (%).

acer

You can end the line with a colon (not the usual semicolon) and it will suppress printing all those pages of output.

evals := LinearAlgebra:-Eigenvalues(M):

If your resulting Vector has been assigned to a variable (above, evals) then you can access its elements as evals[1], evals[2], etc. Or, you can assign those to new variables.

a := evals[1]:

If you got the Vector of eigenvalues by using the context-menus (ie. by right-clicking on a Matrix and using the popup menus) then you can immediately refer to that Vector by using the % symbol. In Maple, % means the "last thing evaluated". See the help-page on topic ditto. For example, you could do as follows.

evals := %:
evals[1];

Your question is not a bad one. It's quite normal to want to simply enter a command like Eigenvalues(M) without assigning it to anything. And then, when it's finished, you want to assign it to some variable without having to wait while recomputing the whole thing. The %, %%, and %%% constructs let you do just that.

The help-page is named "ditto", because many releases ago the symbols for this were double-quotes (") rather than percent (%).

acer

Have you looked at the DynamicSystems:-BodePlot routine, in Maple 12? It has an option linearmag to control whether the vertical axis has logarithmic scale. Its frequency scale is logarithmic by default (and controllable with its linearfreq option.)

acer

Have you looked at the DynamicSystems:-BodePlot routine, in Maple 12? It has an option linearmag to control whether the vertical axis has logarithmic scale. Its frequency scale is logarithmic by default (and controllable with its linearfreq option.)

acer

I'm not sure whether Joe meant "going that route, with eventual use of unapply" as opposed to "use of unapply". I suspect that he meant the former, because he knows Maple very well. But it can be made explicitly clear, for the benefit of other readers.

It is not the application of unapply, in itself, which causes the conversion of sqrt to an exponent of 1/2. Running these examples above, in the Standard GUI, with 2D output makes output containing either sqrt or ^(1/2) appear with the mathematical surd symbol. But underneath, they are different.

For symbolic `a` the input sqrt(a^2) will result in output of the form a^(1/2). This symbolic evaluation is the point at which conversion from sqrt to power 1/2 takes place. Subsequent unapply w.r.t. symbol `a` isn't where that conversion happens. Although, clearly, going the route of symbolic-evaluation followed by unapply together entail the conversion.

> restart:
>
> z := sqrt(a^2); # the "loss" is here
                                        2 1/2
                                 z := (a )

> lprint(%);
(a^2)^(1/2)
>
> f := unapply(z,a);
                                           2 1/2
                               f := a -> (a )

> lprint(%);
a -> (a^2)^(1/2)
>
> f(4);
                                       1/2
                                     16

The above may be contrasted with what happens when the sqrt() is embedded within a procedure. In that case, sqrt() is not preempted by the evaluation at nonnumeric symbol `a`.

> g := a -> sqrt(a);
                               g := a -> sqrt(a)

> lprint(%);
a -> sqrt(a)
>
> g(4);
                                       2

None of this is anything new, of course. It's old news. And it's what underlies the problem of the original example. (I recall trying to explain once before, on here.)

Now, what could be done about this state of affairs? Could `^` expressions be simplified at uniquification time? Could the eval() routine substitute calls of the form `^`(...,1/integer) with calls to sqrt() or root(), in the case that the evaluation point is numeric?

acer

Thanks Joe, but I was not surprised that it worked OK for `&*`.

I'm wondering why it doesn't work for `^`, `*`, and `+`. As I believe that I showed, op(0,..) of such things can be accessed.

acer

The return directive isn't required, for the last statement in the procedure.

acer

The return directive isn't required, for the last statement in the procedure.

acer

The implied multiplication (without a space) makes many of the Definitions look poor.

So does use of "pi" and "i" in help Definitions, in a product like Maple which otherwise uses Pi and I.

The overall effect, producing output like "piit" in the commandline and Classic interfaces, is very poor. It's only slightly mitigated by the 2D typesetting of pi with its greek symbol, in such Definitions viewed in the Standard GUI.

acer

You created your procedure f36() outside of the use of RealDomain. So the `^` bound within f36 is the usual global :-`^` and not the RealDomain:-`^` export. The procedure f36 is getting its binding of `^` when it is created, not when it is used (plotted).

Compare,

restart:
use RealDomain in
  f36 := x -> x^(2/5);
  plot(f36(x), x = -1..1,y = -1..1);
end use;
plot(f36(x), x = -1..1,y = -1..1);
lprint(eval(f36));

restart:
f36 := x -> x^(2/5);
use RealDomain in
  plot(f36(x), x = -1..1,y = -1..1);
end use;
lprint(eval(f36));

restart:
use RealDomain in
  plot(:-`^`(x,2/5), x = -1..1,y = -1..1);
end use;

acer

Ok, but without any detail on how the output is being produced (and then, somehow, converted to strings) then how can one be sure that it is Maple itself that is producing the unwanted scientific notation? I can think of ways in which it would be, and ways in which it would not be.

Can you look at the raw output from Maple, before any Perl processing? Are you lprinting the Maple output, or using printf, or redirecting it at the shell level?

Consider, using commandline Maple 12,

> Z := 0.00056:
> Z;
                                    0.00056
 
> printf("%a\n",Z);
.56e-3
> printf("%f\n",Z);
0.000560
> printf("%g\n",Z);
0.00056
> lprint(Z);
.56e-3
> interface(prettyprint=0):
> Z;
.56e-3

acer

Ok, but without any detail on how the output is being produced (and then, somehow, converted to strings) then how can one be sure that it is Maple itself that is producing the unwanted scientific notation? I can think of ways in which it would be, and ways in which it would not be.

Can you look at the raw output from Maple, before any Perl processing? Are you lprinting the Maple output, or using printf, or redirecting it at the shell level?

Consider, using commandline Maple 12,

> Z := 0.00056:
> Z;
                                    0.00056
 
> printf("%a\n",Z);
.56e-3
> printf("%f\n",Z);
0.000560
> printf("%g\n",Z);
0.00056
> lprint(Z);
.56e-3
> interface(prettyprint=0):
> Z;
.56e-3

acer

This is not a bug in PolynomialInterpolation. The problem is that you have set up getArrays() to return a list whose elements are self-referencing. Subsequent access of its elements results in an infinite recursion.

> getArrays := proc (left, right)
> local x, u;
>   x := [seq(h*i, i = left .. right)];
>   u := [seq(u[i], i = left .. right)]; # the problem
>   return x, u
> end proc:

> x, u := getArrays(-2, 2);
        x, u := [-2 h, -h, 0, h, 2 h], [u[-2], u[-1], u[0], u[1], u[2]]

> u[1]; # bye bye
Execution stopped: Stack limit reached.

It's the local variable name 'u', inside getArrays(), for which it's not programmed well. The same thing would happen if you did the top-level assignment x,t := getArrays(-2, 2); and then accessed t[1].

Maple can catch and prevent some similar sorts of recusive assignment when done at the top-level. But within a procedure definition, you're much more on your own. Here's the behaviour, if you try it at the top-level,

> u := [seq(u[i], i = -2 .. 2)];
Error, recursive assignment
> u := [u[1], u[2]];
Error, recursive assignment

Compare that with,

> u := [9,17]:
> u := [u[1], u[2]];
                                 u := [9, 17]

Note that the assignment u:=[u[1],u[2]] is not necessarily recursive. It depends on the value of u coming in. If u equals [9,17] then it's fine. If u is unassigned then it's recursive. Maple can tell, at the top-level, how things stand. But when you are defining a procedure Maple cannot tell. It's when the procedure runs that it will be OK or not. So Maple let's you define the procedure as you wish.

So, you'll probably want to change how getArrays works. I can't make a good suggestion without knowing whether you truly want the second output of getArrays to contain escaped local names. Do you want the 'u' inside the second output of getArrays to be the global name u or the name of the (escaped) local of getArrays? Do you truly want getArrays to return lists, or would Arrays be OK?

acer

Yes, numappox[remez] needs to be updated to accept both array or Array, for its 'crit' parameter.

I wouldn't be suprised if its access of array elements is straightforward enough that it's just a question of argument checking adjustment.

For now, if one has an Array, then passing it as convert(...,'array') should suffice.

I believe that you are right, that it was implmented in Maple by K.Geddes and/or his grad student(s). As you probably know, Remez was Russian.

acer

Yes, numappox[remez] needs to be updated to accept both array or Array, for its 'crit' parameter.

I wouldn't be suprised if its access of array elements is straightforward enough that it's just a question of argument checking adjustment.

For now, if one has an Array, then passing it as convert(...,'array') should suffice.

I believe that you are right, that it was implmented in Maple by K.Geddes and/or his grad student(s). As you probably know, Remez was Russian.

acer