Perhaps I might offer some advice. Sorry that I currently don't have time to offer code.

Don't have the objective function `Diffproc` itself create a new procedure for (local) f on the fly, with each and every call. Create an objective procedure just once (inside GlobalFit, say). Either subs the parameters right in (before calling GlobalSolve) to get the objective, or declare the parameters in it as globals. But don't use an objective that itself internally creates an entirely new procedure with every single invocation. The NbrP, the spline stuff, the creation of f, the subs of R,A,K... roll it all up so that when GlobalSolve is called the objective is a proc that either already contains the right parameters or accesses them as globals. Have the objective function do math, and not dynamic procedure creation. Who knows, the 13 instances of the objectives could get called tens or hundreds of thousands of times.

Did you want to use evalf(int(...) or evalf(Int(...))?

There are other style and coding issues such as other undeclared globals, using protected name `Diff` as a local, appending to lists/sets in a loop, etc. But they may be relatively minor.

You might also consider running Maple's code profiling mechanisms against it, to see where the time and memory goes.

acer

Since the Sockets:-Serve call will not return (and since that doesn't appear to function from within a Thread), maybe the script could also send a string to automatically open a blank worksheet (after starting up of the GUI to initialize the Serve call).

I'm not sure that it's that big a deal. It's only one instance of having to do File->Open manually per session, compared to the many instances that may be avoided (for some people). And without a switch/option it would always be only either a Worksheet or a Document. And there might be a need (?) for the script to pause, until the socket is ready. And the blank .mw template file would need to read-only, unless someone figures out some other INTERFACE_WORKSHEET call which opens a new empty worksheet.

acer

Does all of commandline Maple's useful printout go to stdout rather than stderr? If so then maybe you could just wrap x/maple in another script which directs stderr to /dev/null.

Eg,

#!/bin/bash
maple12 $* 2> /dev/null

acer

Could you not open a .mw with the automw batch file, utilizing the "Open with" facility? That was my hope. Of course, the first time it's tried the batch file would have to be located with a "browse". (I thought that Windows could use .exe, .com, and .bat to "open" files.)

I was hoping that, used once, the batch file would stay in the short list of suggested applications for the given .mw filename extension.

The intention is also that the (maple) script fire up a new GUI instance as a fallback (on socket communication failure).

acer

In Worksheet (not Document) mode the input as "Maple Notation" should be 1D, appearing as red input text. But, also in Worksheet mode, input can be in "2D Math" notation which appears in black and is mathematically typeset.

Could it be that you were trying it in a Document instead of a Worksheet.

acer

In Worksheet (not Document) mode the input as "Maple Notation" should be 1D, appearing as red input text. But, also in Worksheet mode, input can be in "2D Math" notation which appears in black and is mathematically typeset.

Could it be that you were trying it in a Document instead of a Worksheet.

acer

Thanks for this.

In MS-Windows one can use its "Open with" after right-clicking on a file icon. That mechanism even has a memory of recent actions for suggestions, if I recall. So one needn't alter the default handling of the ".mw" filename extension in order to try these techniques.

acer

That agrees with my experiences and what I'd written. But one can open fresh (blank, new kernel) Worksheets in the GUI even when the Serve call is made in an already open tab.

acer

It is not a difference between the Standard and Classic GUIs.

It is a difference between 2D and 1D Maple input notation.

If you start a new Worksheet (not Document) in the Standard GUI, and use (1D) "Maple Input" instead of "2D Input" then these commands will work fine even with the blank spaces.

To change between 2D and 1D input inside a Worksheet, use the Text/Math toggles in the menubar, or the dropdown input mode menu in the menubar, or hit F5, or switch your default entry mode.

To change your default entry mode, select Tools->Options from the menubar, then select the Display tab in the pop-up that appears, and then use the "Input display" dropdown menu in that tab to choose "Maple Notation".

To change your default from Documents to Worksheets in the Standard GUI, select Tools->Options in the menubar, select the Interface tab in the pop-up, and utilize the "Default format for new worksheets" dropdown menu.

acer

It is not a difference between the Standard and Classic GUIs.

It is a difference between 2D and 1D Maple input notation.

If you start a new Worksheet (not Document) in the Standard GUI, and use (1D) "Maple Input" instead of "2D Input" then these commands will work fine even with the blank spaces.

To change between 2D and 1D input inside a Worksheet, use the Text/Math toggles in the menubar, or the dropdown input mode menu in the menubar, or hit F5, or switch your default entry mode.

To change your default entry mode, select Tools->Options from the menubar, then select the Display tab in the pop-up that appears, and then use the "Input display" dropdown menu in that tab to choose "Maple Notation".

To change your default from Documents to Worksheets in the Standard GUI, select Tools->Options in the menubar, select the Interface tab in the pop-up, and utilize the "Default format for new worksheets" dropdown menu.

acer

You might check that localhost.localdomain is OK for you (it appears in the code). There is a short and simple example in the help-page for Sockets:-Serve. You could see whether you can get that example to work for you. The posted code really doesn't do much more than that simple example in setting up the pair, except that the message gets sent to the "server" rather than from it.

You've probably already checked and changed any path and name for your `maple12`, etc.

acer

Not only does Maple's internal list of mersenne prime exponents need updating, but the routine itself might (possibly) do with an overhaul.

There are ranges for which it is now known that no more Mersenne primes exist. But there are also ranges for which conclusive searching is not yet finished. The 'false' and 'FAIL' returns from numtheory:-mersenne do not reflect all that.

The numtheory package was updated as a module, and the list now appears to be stored in a name (w) accessed by numtheory:-mersenne via lexical scoping. In case anyone's interested in seeing Maple's internal list, here's how to show it in Maple 12.

eval([op(7,eval(numtheory:-mersenne))][2]);

acer

What can determine a line?

A (starting) point and a direction in which to move can together determine a line. If you have those, then the parameter can denote how far in that direction you move from the point (and thus move along the line).

Here's how that might look, with point P1, direction d, and parameter t.

  eqn := P1 + d*t;

Now, let's set up P1 and then find d. To find d we need another point, which we'll call P2. The direction d is found by simply subtracting (coordinatewise) the two points.

I will use 3D Vectors for everything here. (The VectorCalculus  package makes a distinction between points  and  directions, etc. But we can get by here without all that.)

P1:=<x1,y1,z1>;
P2:=<x2,y2,z2>;

d := P2-P1;

# Now look at eqn
eqn := P1 + d*t;

So, if you have a particular pair of points, with values for their coordinates, then simply plug those in for x1, y1, z1, x2, y2, and z2.

acer

What can determine a line?

A (starting) point and a direction in which to move can together determine a line. If you have those, then the parameter can denote how far in that direction you move from the point (and thus move along the line).

Here's how that might look, with point P1, direction d, and parameter t.

  eqn := P1 + d*t;

Now, let's set up P1 and then find d. To find d we need another point, which we'll call P2. The direction d is found by simply subtracting (coordinatewise) the two points.

I will use 3D Vectors for everything here. (The VectorCalculus  package makes a distinction between points  and  directions, etc. But we can get by here without all that.)

P1:=<x1,y1,z1>;
P2:=<x2,y2,z2>;

d := P2-P1;

# Now look at eqn
eqn := P1 + d*t;

So, if you have a particular pair of points, with values for their coordinates, then simply plug those in for x1, y1, z1, x2, y2, and z2.

acer

The objective may not actually be the sum of the distances, but the command as written does provide a result which attains the minimum of that sum, no? That was my intended point, by saying that the code "minimized" that sum.

I would also suggest that its objective is less complicated than that alternative add() call, by virtue of not containing a call to sqrt.

acer