Using this in recent versions of VS came up again in a different context, so I thought I would try this again with VS 2019 and Maple 2021, and report how it went:

For simplicity I copied %MAPLE%/extern/include/maple.cs and %MAPLE%/samples/OpenMaple/c#/om.cs into a "work" directory.   Then I opened up a "Developer Command Prompt for VS 2019" and changed into that directory.

On the command line I compiled via the command:

csc om.cs maple.cs

This built an executable, "om.exe".  I can run this directly:

E:\dev\dotnet>om.exe
    |\^/|     OpenMaple (Example Program)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
 \OPENMAPLE/  All rights reserved. Maple and OpenMaple are trademarks of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
> 1+1;
2
> int(x,x);
1/2*x^2
> done
cputime=0.109; memory used=178kB alloc=1072kB

Note:  there was an error with xIsMapleStop, in both .cs files, so I removed the "x" version in maple.cs:
    [DllImport(@"maplec.dll", CallingConvention=CallingConvention.StdCall)]
    public static extern IntPtr IsMapleStop(IntPtr kv, IntPtr obj );
And changed the call in om.cs:
          if( MapleEngine.IsMapleStop(kv,val) != (IntPtr)0 )
              break;
 

Note also that maplec.dll is installed by Maple into your %WINDOWS%/system32 directory, so it should already be in the path, and finable by the new executable when you run it.   It has to be run on a machine with Maple installed of course.

A "stack limit reached" error usually occurs because of one of the following:

- a program actually uses a lot of stack due to deep recursion, and runs out of memory

- a program makes a recursive assignment (similar to  A := 'A'[1]) 

In this case, the fact that the program works with numnodes = 23, indicates that neither of the above should be a factor.  

To check whether Grid nodes don't get the same amount of stack, I tried the following:
 

stack_depth := proc(n) 
   global N := n;
   stack_depth(n+1);
end proc:
Grid:-Setup(numnodes=23);
Grid:-Set(stack_depth);
Grid:-Map[tasksize=1](stack_depth,[seq(i,i=1..Grid:-NumNodes())]);
Grid:-Seq(N,i=1..Grid:-NumNodes());

On my machine I get roughly the same number for N on each of the 23 nodes.  This also matches running stack_depth(0) directly on the head node.  All of the Maple processes have the same amount of stack available to them.

When I try the same code with Grid:-Setup(numnodes=24), the process terminates.  This example will help us track down the problem.

We have isolated the problem and have a fix pending.  We will make the fix available as a special 2015.3 update as soon as possible.

The problem is reproducible under the following conditions:

- the input involves a SUM with more than 24 terms
- the input has one or more common/repeated terms that, when combined add up to zero
- the expression is constructed as input, rather than something that is computed as the result of a mathematical operation

@Joe Riel The Jays lineup changes every day -- both the ordering and the players involved.  Some players are doing better than last year, some are doing worse.  Last year's stats will be a reasonable guide, but they won't be perfect predictors.  There are also many variables that are not built into this model.  For example, a fast runner on first might raise the probability of a single (ie. lower the probability of a double-play or fielder's choice).  

I don't have the standard deviations.  This site: http://www.baseball-reference.com/teams/TOR/2013.shtml, has a great graphic at the top of the page showing a column graph of the scores so far this year. 

@Joe Riel In the first 53 games, the Jays have scored 238 runs, giving them an average of 4.49 runs per game.  This is a bit more than the model's in-order predicted output of 4.33 runs/game.  

@Mac Dude Thanks for spotting the exponent typo -- now corrected.

Your observations about efficiency and not measuring the energy required for stopping (as fuel consumption) are spot on; I mention that in the article too.  I would say it is safe to ignore the GCE equivalent numbers.  I left them in because that's the method used by the top google hit when you search for a calculation for this (and it also shows off Maple's unit knowledge very nicely).

@Subhra 

procread works with .mpl files -- plain text files of Maple commands.  The .mw file in your example is not a plain text file.   To turn it into one, load it up in Maple's gui, and select File->Export.  Choose "Maple Input (.mpl)" as the export format in the file type drop down and click Save.  Inspect the saved file in a plain text editor like notepad.  You will see the same commands listed as in your worksheet, but output regions will be put into comments.  This file can be run in Maple using the "read" command.  It is also now suitable for use with "procread" in Matlab.

@Subhra 

procread works with .mpl files -- plain text files of Maple commands.  The .mw file in your example is not a plain text file.   To turn it into one, load it up in Maple's gui, and select File->Export.  Choose "Maple Input (.mpl)" as the export format in the file type drop down and click Save.  Inspect the saved file in a plain text editor like notepad.  You will see the same commands listed as in your worksheet, but output regions will be put into comments.  This file can be run in Maple using the "read" command.  It is also now suitable for use with "procread" in Matlab.

@PatrickT 

Slices of a DEPlot3d may not work.  Given that the DE solution curves can appear on top of each other, it would be hard to get a cut-out model that matched the shape of the "curve".  When the 2D projection to the x-y plane has two different y-values for the same x, there is no good way to uniquely cut out the shape. 

Thanks for all these details.  We can reproduce these issues and are now working on a fix.

@J F Ogilvie The dot multiplication operator applies multiplication elementwise when dealing with Arrays.  It applies in the standard mathematical way when dealing with Matrix objects.  This has been the case since dot was introduced.  Maybe your code that generates SI is now producing an Array?   It would help to see an example.

Plots are generated using all the precision available by setting Digits.  They are then rendered using hardware floating point numbers.  If the generated points underflow or overflow in the conversion from software to hardware, then you may get an empty plot.  This is a known limitation, and has been as such since the beginning.  It is not something that has been broken between releases.

@brianking The "symbolic matrix" functionality via the sym() command is new.  I have filed a report that this is missing functionality.  We'll fix that.  In general, the API's should be fairly consistent.  I'd like to hear about any commands that are not supported.   And, a plug: obviously the breadth and power of the solvers, and the generic maple() command won't be reproduced in both systems.  :)

@brianking The "A = sym('A',[1,5])" syntax is not supported in the 15.01 update.   As a workaround, this functionality can be achieved with the following command:

maple('Array(1..1,1..5,(i,j)->cat(''A'',i,_,j))') 

With respect to the Grid package, the 15.01 update fixes the following:

  - a possible deadlock when relaunching commands on a different number of nodes each time

  - some issues with Grid:-Seq, including automatic export of protected names, and partitioning of certain sequences

  - several issues with launching distributed processes in "mpi" mode (which requires the toolbox)

I'm not sure what happened; I re-uploaded the file, so the source code link has been restored.  This file is also available in the Maple 13 samples/OpenMaple/c# directory as "om.cs"