For some (somewhat relevant) background, I found this interesting little excerpt from ?updates,v40:

New evaluation rules for Locals. The evaluation rules for local variables have changed to "one-level" evaluation instead of full evaluation. This means that evaluation of local variables is the same as evaluation of formal parameters, but different than that of global variables. For example, suppose the input to a Maple session is a := b; b := 1; a; Then what does last statement yield? In previous versions of Maple a; evaluated to 1 . In this version, if these statements are entered in an interactive session (a and b are global variables) then a; still evaluates to 1 . However, if a and b are local variables and these statements appear inside a Maple procedure, then a; evaluates to b . Users should not notice any differences in normal usage of Maple. If, however, it is desired to have full evaluation or one-level evaluation explicitly, the eval function (see below) provides this functionality.

The reason 1-level evaluation inside procedures works is that the initial call from the top level causes a full evaluation on the arguments. Subsequent inside-proc calls don't need to fully evaluate their parameters since that was already done once. Objects with last-name evaluation, like tables, don't get the full-eval going from the top level, so references into a table parameter get double-evaluation. Note that table locals get 1-level eval, so we easily can compare its effects: > a := array([x,y,z]): > x := 5: > proc(a) a[1]*a[2]; end(a); 5 y > proc(a) local b; b := a; b[1]*b[2]; end(a); x y When 'a' is a parameter, a[1] gets 2-level evaluation so you can see the value of x in the result. x is stored in the table as a symbol. 1-level eval, as in the second example, evaluates b[1] to x. The second level of eval is needed to go from x to 5. Changing 2-level eval of tables back to 1-level results in hundreds of test failures over a wide variety of functions, not just linalg, so this isn't something we can easily change. Note that the above trick of assigning the parameter to a local can be used as a workaround if you really don't want 2-level eval.

See http://www.maplesoft.com/products/Maple11/system_requirements.aspx for a list of Maple 11's supported platforms. A 64 bit version of Maple 11 will not immediately be available for Windows, but the 32-bit Maple 11 will work under WinXP 64. Maple 11 has a "SMP" mode that will let you run arbitrary Maple code in parallel via a new Threads package. In addition, some platforms (including Windows and Linux) have special parallel numeric libraries. Maple will detect machines with more than one processor allowing some built-in commands to execute in parallel. Maple 11 will be able to leverage all 4 "processors" on a quad core workstation.

Generally on non-Windows boxes the $MAPLE enviroment variable should be set to point to the root of your Maple installation before using OpenMaple applications. Once set, your OpenMaple app will be able to find the license file and other stuff. -PD

Generally on non-Windows boxes the $MAPLE enviroment variable should be set to point to the root of your Maple installation before using OpenMaple applications. Once set, your OpenMaple app will be able to find the license file and other stuff. -PD

> What is Way to improve matrix calculation speed in Maple session? This really depends on what you are trying to achieve. In general the best approach is to find the best command in Maple; being as specific as possible. If you are working with hardware floating point data, then try using the datatype=float[8] option when constructing your matrices. Changing the interface to commandline mode or OpenMaple will not buy you much speed, unless the calculation is taking up all your memory, but doesn't need more than all your memory. Not starting the gui will save you a little bit in these rare circumstances.

Maple has had a "Matlab" package for some time; allowing users who have MATLAB installed to execute MATLAB commands from within Maple. The newly announced "Maple Toolbox for MATLAB" is the reverse setup. With the new toolbox you can execute Maple commands from within MATLAB. The "Maple Toolbox for MATLAB" does not affect any of the commands loaded by with(Matlab).

"Error, (in OpenEngine) Maple/Matlab Link: Can't start Matlab engine" This error occurs when the MATLAB command, engOpen, fails. MATLAB needs to be in the PATH in order for this to work. In Maple, run the command getenv("PATH") and double check if the MATLAB bin directory is included. If it isn't, then you missed something when editing the bin/maple startup script.

According to ?Matlab,setup, "The Maple-MATLAB link works with MATLAB version 7 (R14)". The error message "The library matlink.dll/matlink.so cannot be found" is a bit cryptic and really means "The shared library matlink.so could not be loaded". This could happen for a number of reasons. The most common of which is that LD_LIBRARY_PATH is not properly set to find the Matlab engine libraries used by matlink.so. The ?Matlab,setup page contains instructions on how to edit the maple script. You need to uncomment some environment variable assignments in the script so that Maple knows where Matlab is installed.

There appears to be a memory leak computing exponential with the extended preceision nag libraries. The key is setting Digits := 30. It isn't anything your doing wrong. I'll make sure this gets recorded and looked at. -PD

Attached (sim.mpl) is a simple game simulation with data from last years World Series champion Red Sox. Bump up infolevel to see what's going on during a game (as shown below). Obviously, as Joe Riel mentioned, the rule of thumb, 3-hits = 1 run is poor at best. In the last post I just wanted to see if the number of runs our team was scoring was appropriate. What I really want to find out is if there is a way to improve our scoring chances. The standard baseball batting-order uses the following heuristic: - lead off with someone with a high on-base percentage (and who can maybe steal a base) - next 2 are good contact hitters - batter 4 is your "clean-up" hitter; someone with power - etc. In 1957 the Pirates' manager Bobby Bragan claimed that lineups were being ordered foolishly. Bragan endorsed batting his best hitter first, second-best second, and so on. This idea was dubbed as "Bragan's Brainstorm". Pitcher Dick Hall even attempted to prove mathematically how many runs this scheme could add to the offence. The Pirates went 16-24 during the experiment, which was slightly better than their 14-26 record in the forty games before. The idea was dropped because of the controversy it generated. The results of 10x162 games using the Red Sox standard batting order look like this: . The standard-deviation of this run was 3.725, mean = 5.93, mode = 6, total runs = 9608. Note that the Red Sox actually scored 949 runs in 162 games, so the simulation is actually pretty close. Repeating the experiment with a batting order based on best-average yielded these results: . The standard-deviation was 3.767, mean = 5.817, mode = 5, and total runs = 9423. These numbers are really close, so I am hesitant about drawing conclusions from them, even though, repeated experiments seem to give the edge to the traditional ordering. The next step is to find the optimal batting order for any given set of players?? score:   "------------ inning 1 (runs=0) -----------" score:   J Damon   "outs=0,runs=0,bases=[false, false, false]"   "walk"
score:   M Bellhorn   "outs=0,runs=0,bases=[true, false, false]"   "out"
score:   M Ramirez   "outs=2,runs=0,bases=[false, false, false]"   "strikeout"
score:   "------------ inning 2 (runs=0) -----------"
score:   D Ortiz   "outs=0,runs=0,bases=[false, false, false]"   "walk"
score:   J Varitek   "outs=0,runs=0,bases=[true, false, false]"   "out"
score:   T Nixon   "outs=1,runs=0,bases=[true, false, false]"   "strikeout"
score:   K Millar   "outs=2,runs=0,bases=[true, false, false]"   "double"
score:   B Mueller   "outs=2,runs=1,bases=[false, true, false]"   "out"
score:   "------------ inning 3 (runs=1) -----------"
score:   O Cabrera   "outs=0,runs=1,bases=[false, false, false]"   "double"
score:   J Damon   "outs=0,runs=1,bases=[false, true, false]"   "strikeout"
score:   M Bellhorn   "outs=1,runs=1,bases=[false, true, false]"   "walk"
score:   M Ramirez   "outs=1,runs=1,bases=[true, true, false]"   "double"
score:   D Ortiz   "outs=1,runs=3,bases=[false, true, false]"   "out"
score:   J Varitek   "outs=2,runs=3,bases=[false, true, false]"   "out"
score:   "------------ inning 4 (runs=3) -----------"
score:   T Nixon   "outs=0,runs=3,bases=[false, false, false]"   "single"
score:   K Millar   "outs=0,runs=3,bases=[true, false, false]"   "out"
score:   B Mueller   "outs=1,runs=3,bases=[true, false, false]"   "single"
score:   O Cabrera   "outs=1,runs=3,bases=[true, false, true]"   "out"
score:   J Damon   "outs=2,runs=3,bases=[true, false, true]"   "out"
score:   "------------ inning 5 (runs=3) -----------"
score:   M Bellhorn   "outs=0,runs=3,bases=[false, false, false]"   "strikeout"
score:   M Ramirez   "outs=1,runs=3,bases=[false, false, false]"   "strikeout"
score:   D Ortiz   "outs=2,runs=3,bases=[false, false, false]"   "double"
score:   J Varitek   "outs=2,runs=3,bases=[false, true, false]"   "single"
score:   T Nixon   "outs=2,runs=4,bases=[true, false, false]"   "out"
score:   "------------ inning 6 (runs=4) -----------"
score:   K Millar   "outs=0,runs=4,bases=[false, false, false]"   "out"
score:   B Mueller   "outs=1,runs=4,bases=[false, false, false]"   "out"
score:   O Cabrera   "outs=2,runs=4,bases=[false, false, false]"   "out"
score:   "------------ inning 7 (runs=4) -----------"
score:   J Damon   "outs=0,runs=4,bases=[false, false, false]"   "double"
score:   M Bellhorn   "outs=0,runs=4,bases=[false, true, false]"   "out"
score:   M Ramirez   "outs=1,runs=4,bases=[false, true, false]"   "walk"
score:   D Ortiz   "outs=1,runs=4,bases=[true, true, false]"   "strikeout"
score:   J Varitek   "outs=2,runs=4,bases=[true, true, false]"   "walk"
score:   T Nixon   "outs=2,runs=4,bases=[true, true, true]"   "out"
score:   "------------ inning 8 (runs=4) -----------"
score:   K Millar   "outs=0,runs=4,bases=[false, false, false]"   "walk"
score:   B Mueller   "outs=0,runs=4,bases=[true, false, false]"   "walk"
score:   O Cabrera   "outs=0,runs=4,bases=[true, true, false]"   "out"
score:   J Damon   "outs=1,runs=4,bases=[true, true, false]"   "out"
score:   M Bellhorn   "outs=2,runs=4,bases=[true, true, false]"   "out"
score:   "------------ inning 9 (runs=4) -----------"
score:   M Ramirez   "outs=0,runs=4,bases=[false, false, false]"   "homer"
score:   D Ortiz   "outs=0,runs=5,bases=[false, false, false]"   "strikeout"
score:   J Varitek   "outs=1,runs=5,bases=[false, false, false]"   "strikeout"
score:   T Nixon   "outs=2,runs=5,bases=[false, false, false]"   "out"

The kernel does track root nodes and block sizes, so it should be possible to detect when a block is entirely free. I have logged a feature request for this, and will experiment with it.