As I see it, there is a concern that you are writing to the very important "lib" subfolder of your Maple installation. Personally, I would never want to write out files there (not even accidental .m rubbish), and I would worry about affecting the .mla's there.

And it could get tricky to clean up and remove private material from there, if you didn't recall exactly what was and what was not your own contribution. And so it would be harder to disable such private .mla contributions (you couldn't just rename the folder or edit maple.ini to turn them off/on.)

My own preference would be to use a personal folder located under, say, "C:\\Documents and Settings\\<myname>" or similar.  A customized initialization file could set libname to include that location automatically.

See the ?worksheet,reference,initialization help-page, I think, for notes on customizing an initialization file for use with Standard on MS-Windows.

Perhaps you could try an experiment for me. In Maple 12, see what these give,

S := kernelopts(dirsep):
cat(kernelopts(homedir),S,"maple",S,"toolbox",S,"12",S,"misc",S,"lib");
cat(kernelopts(homedir),S,"maple",S,"toolbox",S,"misc",S,"lib");

Then create one or both such folders. Then move your private .mla to them. The quit maple (entirely) and restart. Are those locations automatically in your libname and your package available for use?

acer

As I see it, there is a concern that you are writing to the very important "lib" subfolder of your Maple installation. Personally, I would never want to write out files there (not even accidental .m rubbish), and I would worry about affecting the .mla's there.

And it could get tricky to clean up and remove private material from there, if you didn't recall exactly what was and what was not your own contribution. And so it would be harder to disable such private .mla contributions (you couldn't just rename the folder or edit maple.ini to turn them off/on.)

My own preference would be to use a personal folder located under, say, "C:\\Documents and Settings\\<myname>" or similar.  A customized initialization file could set libname to include that location automatically.

See the ?worksheet,reference,initialization help-page, I think, for notes on customizing an initialization file for use with Standard on MS-Windows.

Perhaps you could try an experiment for me. In Maple 12, see what these give,

S := kernelopts(dirsep):
cat(kernelopts(homedir),S,"maple",S,"toolbox",S,"12",S,"misc",S,"lib");
cat(kernelopts(homedir),S,"maple",S,"toolbox",S,"misc",S,"lib");

Then create one or both such folders. Then move your private .mla to them. The quit maple (entirely) and restart. Are those locations automatically in your libname and your package available for use?

acer

You are very welcome.

If display has been bound to plots:-display, then print(display(...)) should also work.

Outside of a procedure you can accomplish that rebinding using with, while inside a procedure use or uses are appropriate.

As far as plots:-display versus plots[display] goes, that is an issue with a complicated history. I have been meaning to blog on it for some time. I suggest reading the ?colondash help-page. That pages indicates that plots[':-display'] is a safe form of plots[display], but who would want to type that in? And plots:-display is far simpler, completely 100% safe, and equally adequate for almost everyone all the time.

acer

You are very welcome.

If display has been bound to plots:-display, then print(display(...)) should also work.

Outside of a procedure you can accomplish that rebinding using with, while inside a procedure use or uses are appropriate.

As far as plots:-display versus plots[display] goes, that is an issue with a complicated history. I have been meaning to blog on it for some time. I suggest reading the ?colondash help-page. That pages indicates that plots[':-display'] is a safe form of plots[display], but who would want to type that in? And plots:-display is far simpler, completely 100% safe, and equally adequate for almost everyone all the time.

acer

> L := [[1,2,3,4],[2,3,5,5],[3,4,4,6],[4,5,5,3]]:

> sort(L, (a,b)->`if`(a[3]<b[3],true,
>                     `if`(a[3]=b[3] and a[4]<b[4],true,false)));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

> sort(L, (a,b)->`if`(a[3]<b[3] or
>                     (a[3]=b[3] and a[4]<b[4]),true,false));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

> sort(L, (a,b)->(a[3]<b[3] or (a[3]=b[3] and a[4]<b[4])));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

acer

> L := [[1,2,3,4],[2,3,5,5],[3,4,4,6],[4,5,5,3]]:

> sort(L, (a,b)->`if`(a[3]<b[3],true,
>                     `if`(a[3]=b[3] and a[4]<b[4],true,false)));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

> sort(L, (a,b)->`if`(a[3]<b[3] or
>                     (a[3]=b[3] and a[4]<b[4]),true,false));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

> sort(L, (a,b)->(a[3]<b[3] or (a[3]=b[3] and a[4]<b[4])));
           [[1, 2, 3, 4], [3, 4, 4, 6], [4, 5, 5, 3], [2, 3, 5, 5]]

acer

In Maple 12.01 and 10.02,

> D_n := n_max+1-n_0:

> N2:=Sum((2*u2-D_n)!/(u2!*(u2-D_n)!),u2=D_n..min(u,n_max-1)):

> N:=Sum((n_0-2+u)!/(u!*(n_0-2)!)-piecewise(u<D_n,0,N2),u=0..n_P-2):

> eval(N,{n_0=3,n_P=4,n_max=4}):

> value(%): lprint(%);
6+4/3*I*3^(1/2)/(1+I*3^(1/2))^2+4*hypergeom([1, 5/2, 3],[2, 4],4)

> evalc(simplify(%)); # or radnormal(simplify(%))
                                       5

> kernelopts(version);
             Maple 10.02, X86 64 LINUX, Nov 8 2005 Build ID 208934
 
> version();
User Interface: 190196
Kernel:         208934
Library:        222373
                                    222373

If you are only going to evaluate this using specific values for n_0, n_P, and n_max then perhaps you could rewrite it as a procedure which uses add instead of sum/Sum. That could let the simple result compute easily, and avoid the hypergeom. Or, are you hoping to manipulate the symbolic sums?

acer

In Maple 12.01 and 10.02,

> D_n := n_max+1-n_0:

> N2:=Sum((2*u2-D_n)!/(u2!*(u2-D_n)!),u2=D_n..min(u,n_max-1)):

> N:=Sum((n_0-2+u)!/(u!*(n_0-2)!)-piecewise(u<D_n,0,N2),u=0..n_P-2):

> eval(N,{n_0=3,n_P=4,n_max=4}):

> value(%): lprint(%);
6+4/3*I*3^(1/2)/(1+I*3^(1/2))^2+4*hypergeom([1, 5/2, 3],[2, 4],4)

> evalc(simplify(%)); # or radnormal(simplify(%))
                                       5

> kernelopts(version);
             Maple 10.02, X86 64 LINUX, Nov 8 2005 Build ID 208934
 
> version();
User Interface: 190196
Kernel:         208934
Library:        222373
                                    222373

If you are only going to evaluate this using specific values for n_0, n_P, and n_max then perhaps you could rewrite it as a procedure which uses add instead of sum/Sum. That could let the simple result compute easily, and avoid the hypergeom. Or, are you hoping to manipulate the symbolic sums?

acer

Aside from what Joe has stated, it's not correct to try to save a module to a .m file. The (non-exported) local members of a module get "anonymized" and saved as separate .m images inside a .mla archive.

It is generally not a good idea to try to savelib some things to just a .m file in modern Maple. You may be able to save data and (simple) state to .m files, but that would be by using save which is a different command.

If there is no writable .mla archive in the libname path, then a savelib command can end up writing out separate .m files to the directory or folder. The fact that it does so doesn't imply that savelib'ing directly to .m is the right thing to do. This entire topic has always been a little unnecessarily complicated, on account of this behaviour.

Here is an example,

> restart:

> libname := kernelopts(homedir),libname:

> test := module () export f; option package; local g;
>   g:=proc(x) sin(x) end proc:
>   f:=proc(x) g(x); end proc:
> end module:

> LibraryTools:-Create(cat(kernelopts(homedir),
>                           kernelopts(dirsep),
>                          "test.mla")):
> savelib(test):

> restart:

> libname := kernelopts(homedir),libname:
> test:-f(17);
                                    sin(17)

> march('list',cat(kernelopts(homedir),
>                  kernelopts(dirsep),"test.mla"));
[["test.m", [2009, 4, 27, 11, 12, 56], 41984, 96],

    [":-1.m", [2009, 4, 27, 11, 12, 56], 42145, 84],

    [":-2.m", [2009, 4, 27, 11, 12, 56], 42080, 65]]

If you had savelib'ed test to test.m instead of to test.mla then (after restart and resetting libname)  the local  test:-g would not be available. The syntax for doing that (which I don't advise) would be more like savelib(test,`test.m`).

Getting back to your suggestion, it might be a better idea to always prepend rather than to append to libname. And make your Maple installation folder read-only (if your OS supports that) so that you cannot accidentally clobber its contents.

It bothers me slightly that the ?savelib help-page suggests an Example using kernelopts(mapledir) instead of kernelopts(homedir). Apart from the fact that it might not even work for a networked Maple installation, it's not a great idea.

acer

Aside from what Joe has stated, it's not correct to try to save a module to a .m file. The (non-exported) local members of a module get "anonymized" and saved as separate .m images inside a .mla archive.

It is generally not a good idea to try to savelib some things to just a .m file in modern Maple. You may be able to save data and (simple) state to .m files, but that would be by using save which is a different command.

If there is no writable .mla archive in the libname path, then a savelib command can end up writing out separate .m files to the directory or folder. The fact that it does so doesn't imply that savelib'ing directly to .m is the right thing to do. This entire topic has always been a little unnecessarily complicated, on account of this behaviour.

Here is an example,

> restart:

> libname := kernelopts(homedir),libname:

> test := module () export f; option package; local g;
>   g:=proc(x) sin(x) end proc:
>   f:=proc(x) g(x); end proc:
> end module:

> LibraryTools:-Create(cat(kernelopts(homedir),
>                           kernelopts(dirsep),
>                          "test.mla")):
> savelib(test):

> restart:

> libname := kernelopts(homedir),libname:
> test:-f(17);
                                    sin(17)

> march('list',cat(kernelopts(homedir),
>                  kernelopts(dirsep),"test.mla"));
[["test.m", [2009, 4, 27, 11, 12, 56], 41984, 96],

    [":-1.m", [2009, 4, 27, 11, 12, 56], 42145, 84],

    [":-2.m", [2009, 4, 27, 11, 12, 56], 42080, 65]]

If you had savelib'ed test to test.m instead of to test.mla then (after restart and resetting libname)  the local  test:-g would not be available. The syntax for doing that (which I don't advise) would be more like savelib(test,`test.m`).

Getting back to your suggestion, it might be a better idea to always prepend rather than to append to libname. And make your Maple installation folder read-only (if your OS supports that) so that you cannot accidentally clobber its contents.

It bothers me slightly that the ?savelib help-page suggests an Example using kernelopts(mapledir) instead of kernelopts(homedir). Apart from the fact that it might not even work for a networked Maple installation, it's not a great idea.

acer

Too many new users go wrong with this. The goal might have been that implicit multiplication in 2D Math entry followed some "natural" mode, but the clash between brackets as delimiters and for function application is a real issue.

There's a need for an explanation of the 2D Math implicit multiplication rules, on a help-page that is really easy to find (ie. lots of useful aliased help-queries would get one there). The explanation should be as thorough as Doug's analysis. At present, the ?worksheet,documenting,2DMathDetails help-page is too hard to get to, and is too thin with explanations of implicit multiplication in the presence of round-brackets.

Maybe the system could detect some problematic instances, and query the user as to the intention. Consider the separate case of function assignment. If one enters f(x):=x^2 in 2D Math mode then a dialogue pops up, to allow the user to specify whether a function definition or a remember table assignment is intended. Either a similar approach could be implemented for problematic implicit multiplication situations, or the system might be made more robust,... or the entire implicit multiplication scheme could be reconsidered altogether.

The mechanism offered by Typesetting:-Settings(numberfunctions = false) is too obscure. Also, it has an effect on 5.01(c) but not on (5.01)(c). It could also be more clearly documented that changing that setting doesn't affect copy-n-pasted expressions, which may not be re-parsed(?).

acer

Too many new users go wrong with this. The goal might have been that implicit multiplication in 2D Math entry followed some "natural" mode, but the clash between brackets as delimiters and for function application is a real issue.

There's a need for an explanation of the 2D Math implicit multiplication rules, on a help-page that is really easy to find (ie. lots of useful aliased help-queries would get one there). The explanation should be as thorough as Doug's analysis. At present, the ?worksheet,documenting,2DMathDetails help-page is too hard to get to, and is too thin with explanations of implicit multiplication in the presence of round-brackets.

Maybe the system could detect some problematic instances, and query the user as to the intention. Consider the separate case of function assignment. If one enters f(x):=x^2 in 2D Math mode then a dialogue pops up, to allow the user to specify whether a function definition or a remember table assignment is intended. Either a similar approach could be implemented for problematic implicit multiplication situations, or the system might be made more robust,... or the entire implicit multiplication scheme could be reconsidered altogether.

The mechanism offered by Typesetting:-Settings(numberfunctions = false) is too obscure. Also, it has an effect on 5.01(c) but not on (5.01)(c). It could also be more clearly documented that changing that setting doesn't affect copy-n-pasted expressions, which may not be re-parsed(?).

acer

From the ?proc help-page,

Implicit Local Variables
- For any variable used within a procedure without being explicitly mentioned
  in a local localSequence; or global globalSequence; the following rules are
  used to determine whether it is local or global:

  The variable is searched for amongst the locals and globals (explicit or
  implicit) in surrounding procedures, starting with the innermost. If the
  name is encountered as a parameter, local variable, or global variable of
  such a surrounding procedure, that is what it refers to.

  Otherwise, any variable to which an assignment is made, or which appears as
  the controlling variable in a for loop, is automatically made local.

  Any remaining variables are considered to be global.

> x := 3:

> f:= proc() local g, x;
>   x := 17;
>   g := proc() x; end proc;
>   :-x, x, g();
> end proc:

> f();
                                   3, 17, 17

acer

From the ?proc help-page,

Implicit Local Variables
- For any variable used within a procedure without being explicitly mentioned
  in a local localSequence; or global globalSequence; the following rules are
  used to determine whether it is local or global:

  The variable is searched for amongst the locals and globals (explicit or
  implicit) in surrounding procedures, starting with the innermost. If the
  name is encountered as a parameter, local variable, or global variable of
  such a surrounding procedure, that is what it refers to.

  Otherwise, any variable to which an assignment is made, or which appears as
  the controlling variable in a for loop, is automatically made local.

  Any remaining variables are considered to be global.

> x := 3:

> f:= proc() local g, x;
>   x := 17;
>   g := proc() x; end proc;
>   :-x, x, g();
> end proc:

> f();
                                   3, 17, 17

acer

It is interesting that verify gets this but is does not. It seems that verify gets it because signum gets it.

> signum( (X+w)^2 + Y^2)
>   assuming X::real, w>0, Y::real;
                                       1

I notice that both verify and signum do not handle the expanded expression, likely due to the resulting X+w term. It's possible that is is doing such an expansion.

> signum(expand((X+w)^2 + Y^2))
>   assuming X::real, w>0, Y::real;
                                 2            2    2
                         signum(X  + 2 X w + w  + Y )

> verify(expand((X+w)^2 + Y^2),0,'greater_equal')
>   assuming X::real, w>0, Y::real;
                                     FAIL

acer