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

That does not make much sense for scalars, which were being discussed here, I think.

What might be useful is having map[evalhf] utilize the Vector Math (VML) subset of MKL.

One can observe that LinearAlgebra's hardware floating-point routines are linked to MKL on MS-Windows (32bit). On Linux, ATLAS is used for this. That and other packages get to MKL/ATLAS via Maple's external calling.

I would like to see external calling work directly under evalhf (without recourse to the new `eval` capability under evalhf, which seems to add a costly transition between hardware and scalar floats). The advent of option hfloat indicates movement in the other direction, toward faster float operations outside of evalhf. How that will pan out will be interesting.

Note that scalar hardware floats are now "first class citizens" in Maple, but not yet widely used. They might be used as the type for returns from external calling within evalhf, were it enabled. Or they might be used for such returns outside of evalhf (this is not yet so, I believe).

ps. Is it just me, or does this seem odd. Note the accuracy. Why isn't Digits=trunc(evalhf(Digits)) used within the HFloat constructor?

> HFloat(1./3);
                                 0.3333333333
 
> lprint(%);
HFloat(.333333333299999979)

acer

That does not make much sense for scalars, which were being discussed here, I think.

What might be useful is having map[evalhf] utilize the Vector Math (VML) subset of MKL.

One can observe that LinearAlgebra's hardware floating-point routines are linked to MKL on MS-Windows (32bit). On Linux, ATLAS is used for this. That and other packages get to MKL/ATLAS via Maple's external calling.

I would like to see external calling work directly under evalhf (without recourse to the new `eval` capability under evalhf, which seems to add a costly transition between hardware and scalar floats). The advent of option hfloat indicates movement in the other direction, toward faster float operations outside of evalhf. How that will pan out will be interesting.

Note that scalar hardware floats are now "first class citizens" in Maple, but not yet widely used. They might be used as the type for returns from external calling within evalhf, were it enabled. Or they might be used for such returns outside of evalhf (this is not yet so, I believe).

ps. Is it just me, or does this seem odd. Note the accuracy. Why isn't Digits=trunc(evalhf(Digits)) used within the HFloat constructor?

> HFloat(1./3);
                                 0.3333333333
 
> lprint(%);
HFloat(.333333333299999979)

acer

In the Standard GUI, can you not access the same Postscript exporter as in Classic, by using the plotsetup routine?

Joe mentioned this above.

acer

Yes, the comments might well help the expert. And the revision history might too.

acer

Yes, the comments might well help the expert. And the revision history might too.

acer