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

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

The commands that I wrote had to all be done in exacty the order that I gave them. I suspect that you repeated the intersection() command.

Many of the geom3d commands work by assigning to a name (parameter) as a "side effect". If you do try to repeat the same command then that name gets evaluated to its previously assigned value when passed again as an argument to the procedure. Ie, the routine sees the previously assigned value coming in as the argument, and not an actual name as expected. Maple complains about this with the error message that you mentioned. You can work around this by simply quoting the relevant arguments. I give an example below.

> with(geom3d):
> point(a,-3,-10,2),point(b,5,14,8):
> line(L,[a,b]):
> _EnvXName := x: _EnvYName := y: _EnvZName := z:
> sphere(s,x^2+y^2+z^2 = 36,[x,y,z]):

> intersection(P,s,L): # this assigns to P
areinterls:   "two points of intersection"

> intersection(P,s,L): # it sees the value of P, not the name P
areinterls:   "two points of intersection"
Error, (in geom3d:-intersection) illegal use of a formal parameter

> intersection('P',s,L): # so pass in the name P
areinterls:   "two points of intersection"

You also can quote the relevant names the first (and every) time the command gets called, so that the code for it always looks similar.

The `areinterls: "two points of intersection"' bit is just a printed informative message, not a returned result. It's letting you know that it found two distinct points of intersection, that's all.

In order to understand how I showed it being done with Maple, it would be best to understand mathematically and geometrically the explanation I gave first about how to do it by hand.

acer

The commands that I wrote had to all be done in exacty the order that I gave them. I suspect that you repeated the intersection() command.

Many of the geom3d commands work by assigning to a name (parameter) as a "side effect". If you do try to repeat the same command then that name gets evaluated to its previously assigned value when passed again as an argument to the procedure. Ie, the routine sees the previously assigned value coming in as the argument, and not an actual name as expected. Maple complains about this with the error message that you mentioned. You can work around this by simply quoting the relevant arguments. I give an example below.

> with(geom3d):
> point(a,-3,-10,2),point(b,5,14,8):
> line(L,[a,b]):
> _EnvXName := x: _EnvYName := y: _EnvZName := z:
> sphere(s,x^2+y^2+z^2 = 36,[x,y,z]):

> intersection(P,s,L): # this assigns to P
areinterls:   "two points of intersection"

> intersection(P,s,L): # it sees the value of P, not the name P
areinterls:   "two points of intersection"
Error, (in geom3d:-intersection) illegal use of a formal parameter

> intersection('P',s,L): # so pass in the name P
areinterls:   "two points of intersection"

You also can quote the relevant names the first (and every) time the command gets called, so that the code for it always looks similar.

The `areinterls: "two points of intersection"' bit is just a printed informative message, not a returned result. It's letting you know that it found two distinct points of intersection, that's all.

In order to understand how I showed it being done with Maple, it would be best to understand mathematically and geometrically the explanation I gave first about how to do it by hand.

acer

You might find this syntax to be straightforward,

[seq(x[1..3], x in L)];

acer

You might find this syntax to be straightforward,

[seq(x[1..3], x in L)];

acer

I've edited out this comment, which I realized wasn't right.

acer