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

Maybe the students could appreciate the exp() example from the ?numapprox[remez] help-page?

I notice, in passing, that it's not obvious how to get the help-page ?array in the commandline and Classic interfaces. Issuing ?array gets to the ?Array help-page. It turns out that it can be obtained by instead querying for the help-topic,

array(deprecated)

There doesn't appear to be a link to ?array(deprecated) from ?Array. The only mention of the deprecated array in ?Array is not an active help-link.

But numapprox[remez] still needs an array, and doesn't accept an Array, for the critical points argument. There's no link from ?numapprox[remez] to ?array(deprecated) either.

acer

Maybe the students could appreciate the exp() example from the ?numapprox[remez] help-page?

I notice, in passing, that it's not obvious how to get the help-page ?array in the commandline and Classic interfaces. Issuing ?array gets to the ?Array help-page. It turns out that it can be obtained by instead querying for the help-topic,

array(deprecated)

There doesn't appear to be a link to ?array(deprecated) from ?Array. The only mention of the deprecated array in ?Array is not an active help-link.

But numapprox[remez] still needs an array, and doesn't accept an Array, for the critical points argument. There's no link from ?numapprox[remez] to ?array(deprecated) either.

acer

What is your platform (operating system), and exact Maple version (11.00, 11.01, 11.02)?

acer

Using either the 32 or 64 bit Linux versions of either Maple 11.02 or 10.06 it worked OK for me.

I also saw this,

> Digits:=17:
> with(Optimization):
> Maximize(40*a+60*b, {40*a+60*b <= 150},
>          assume = nonnegint, depthlimit = 10);
maple: fatal error, lost connection to kernel

The same thing happened with Digits set to 14 and UseHardwareFloats set to false.

acer

Not much would alter, in the short term, because current versions of those 3rd party software could be re-used. Now, when a new architecture comes along that is so radically different that it absolutely requires (for competitiveness) the latest and greatest, well that would be another story.

GMP is moving towards GPL with some new modularized version, I think. (One plugs in the module, for a new architecture, or something.) So that could be interesting. Never totally catastrophic though, as Maple had its own proprietary scheme (in use until Maple 8, though not as good a performer in the limit). But if machines started to have 100s of cores, and GMP had great multicore support... then who knows? Maplesoft had the skill to implement a proprietary scheme once (relatively good, when it first arrived), and maybe they could do so again, but threaded.

For fast vendor BLAS, there seems to always be someone selling one. If you check out the MKL cost, it's not prohibitive if I recall correctly. Maple already uses MKL on Windows, and I've heard (or read) that that platform is by far the biggest part of the Maple customer base.

I'm not sure that it's accurate to say that most of Maple's performance relies on such things. But the portion that does is becoming more important, from a pure number crunching point of view.

The MKL part on Windows, already in use, is not free software. And ATLAS is not under LGPL, is it?

acer

Not much would alter, in the short term, because current versions of those 3rd party software could be re-used. Now, when a new architecture comes along that is so radically different that it absolutely requires (for competitiveness) the latest and greatest, well that would be another story.

GMP is moving towards GPL with some new modularized version, I think. (One plugs in the module, for a new architecture, or something.) So that could be interesting. Never totally catastrophic though, as Maple had its own proprietary scheme (in use until Maple 8, though not as good a performer in the limit). But if machines started to have 100s of cores, and GMP had great multicore support... then who knows? Maplesoft had the skill to implement a proprietary scheme once (relatively good, when it first arrived), and maybe they could do so again, but threaded.

For fast vendor BLAS, there seems to always be someone selling one. If you check out the MKL cost, it's not prohibitive if I recall correctly. Maple already uses MKL on Windows, and I've heard (or read) that that platform is by far the biggest part of the Maple customer base.

I'm not sure that it's accurate to say that most of Maple's performance relies on such things. But the portion that does is becoming more important, from a pure number crunching point of view.

The MKL part on Windows, already in use, is not free software. And ATLAS is not under LGPL, is it?

acer