Hi Jacques,

You wrote that it had changed "recently", which initially had me slightly confused. The Math Library section of context-sensitive menus was all rewritten between Maple 9 and 9.5. That's when this change to the order came about, I believe. That development was done in late 2003, so about 4.5 years ago.

The rewrite work was done by a former student of yours, if I recall. Not that you had anything to do with it, of course. But you could ask the author, if you need more details about either the decision to change the item order or about other changes in it.

We know that it also slowed down, both with the rewrite and with the advent of Java in the GUI. Some performance improvements have been made in Maple 12, especially with regard to the speed of generating the context-menus for large Matrices, but also in some other ways. Naturally, we would like to find the resources for making it faster still.

I'm writing here about the performance of the Library-side code that generates the menus on the fly for a given object. The speed of Java for doing its part (especially for the very first menu's initialization) is a whole other GUI aspect from my perspective.

If you see context-menu items that you think are wrong, please do submit them. Thanks.

Dave Linder
Mathematical Software, Maplesoft

Hi Jacques,

Yes, there is a group of Maplesoft developers who read almost every post here.

I will ask; maybe we might be allowed to dump some of our expository "beta" forum posts, or some of the What's New help page content, into a Collaborative Books section here.

Dave Linder
Mathematical Software, Maplesoft

For 2D Math input in Maple 12, <Ctrl>-underscore should result in an atomic identifier, without having to use palettes or context-menus. 

Dave Linder
Mathematical Software, Maplesoft

For 2D Math input in Maple 12, <Ctrl>-underscore should result in an atomic identifier, without having to use palettes or context-menus. 

Dave Linder
Mathematical Software, Maplesoft

During the development cycle of Maple 9.5 (Jan, 2004) I removed these lines from the very top of `fsolve/EvalAtx` (which dates back to 1996),

   1   if 10000 < max(op(map(abs,map2(op,2,indets([v, f],float))))) then
   2     return exponent_overflow
       end if;

The start of my comment in the source revision begins, "Removal of a highly dubious mechanism for guessing whether the expression will under/overflow." and goes on with a bit of a rant about it. I can hardly imagine why I didn't notice the similar lines at the end of that short routine. I think that I was really focused on this next example, which did not work in Maple 9 and earlier.

fsolve((10.51627310^n-1/2*22.09916394^n-1/2*0.^n)/(1/2*17.95621497^n+1/2*7.261843774^n-10.51627310^n)-1, n=0.5..2);

Jacques, I know that you will be aware of it but others might not realize that from-the-hip editing of Library routines can be a risky thing. That can be so even when one has strong grounds to deem a fix as "good". Maple's so complicated that any adjustment really needs a full test run to ensure that no regressions are caused. I'd be remiss if I didn't mention that, given your code surgery example.

Dave Linder
Mathematical Software, Maplesoft

Duly noted, thanks.

Dave Linder
Mathematical Software, Maplesoft

Currently,

> assume(n>0):
> is(2^n>n);
                                    true

> assume(r,RealRange(Open(-1),Open(1)));
> limit(r^n,n = infinity);
                                            n
                                lim       r~
                           n -> infinity

And, after the simple flip of how `is/RealRange` calls `property/PropInclusion` in its last line,

> assume(n>0):
> is(2^n>n);
                                     false

> assume(r,RealRange(Open(-1),Open(1)));
> limit(r^n,n = infinity);
                                       0

There's always work to be done.

Dave Linder
Mathematical Software, Maplesoft

Currently,

> assume(n>0):
> is(2^n>n);
                                    true

> assume(r,RealRange(Open(-1),Open(1)));
> limit(r^n,n = infinity);
                                            n
                                lim       r~
                           n -> infinity

And, after the simple flip of how `is/RealRange` calls `property/PropInclusion` in its last line,

> assume(n>0):
> is(2^n>n);
                                     false

> assume(r,RealRange(Open(-1),Open(1)));
> limit(r^n,n = infinity);
                                       0

There's always work to be done.

Dave Linder
Mathematical Software, Maplesoft

We can look into this. Thanks, Jacques.

Dave Linder
Mathematical Software, Maplesoft

We can look into this. Thanks, Jacques.

Dave Linder
Mathematical Software, Maplesoft

It took me 4-5 guesses, though.

Dave Linder Mathematical Software, Maplesoft

Was the corporate name Maplesoft coined by a woman?

Dave Linder
Mathematical Software, Maplesoft

I agree with what you write, Jacques, about the importance of good documention of the system (and its changes... and its updates...).

I was considering that (at least) for float[8] datatype Matrices and Vectors LinearAlgebra:-Map could reasonably call map[evalhf,inplace].

Dave Linder Mathematical Software, Maplesoft

In that note I was considering replacing the ATLAS BLAS that are already bundled with Maple. That might be relevant if one had an 8-core machine and was running Linux.

There is no dynamic mechanism in the shipped ATLAS binaries to handle varying the number of cores/cpus that get used: it's set and compiled in as a fixed parameter. Maple doesn't ship with an 8-core/cpu optimized ATLAS on Linux, so if one had such a machine then dropping in a replacement might be desirable. But on Windows with MKL it might be dynamically set, using that OMP_NUM_THREADS environment variable.

One cannot simply drop into Maple an updated set of .dll's to MKL. The bits that use it must be linked against it specifically. But there's less reason to want to do so, because of the above.

Dave Linder Mathematical Software, Maplesoft

I just tried it and yes, you're right. It's 10sec with 64bit Maple (Linux) and 42sec with 32bit Maple (Linux), run on the same machine and OS.

Sorry, I missed that. So only about 100 times faster than 4800 sec, then.

By the way, I have read here that you are interested in solving problems with high performance. Have you see this note about OMP_NUM_THREADS? If you set that to the value 2 as a WinXP environment variable on your Core2 Duo (and reboot to get it to take effect) then you may see improvement in the hardware floating-point linear algebra examples. It could allow the MKL used by Maple to run two threads. But you'd have to measure wall clock time, since Maple's time() command will add the times take by both threads make it appear like there's no difference.

Dave Linder Mathematical Software, Maplesoft