It is great to see Maple's help online.

The feedback mechanism on each page looks useful.

As first-versions go, it is very good. (It's very hard to make the first version of anything near perfect.) And since it is online it can be adjusted or improved independently of Maple patch releases.

I have a few suggestions for improvements:

• When a search would return only one item, then display it immediately (that is how Maple's own Help works). Right now it shows a page with just the link to the single result.
• Provide the alternate text in the properties on any 2D Math output. (Mapleprimes does this.)
• Have the subsections of a help-page be url targets, so that one can link to the offset Examples, See Also, Description, CallingSequence, etc.
• Provide a way to get all the Examples as 1D Maple Notation. Maple's own Help has a toggle for this, but the Online Help might provide 1D with its own mechanism.
• Have a better way to deal with hidden code in the Applications worksheets. I realize this could be difficult, but otherwise application pages like the one for Image Processing appear obscure.
• Make the site faster.
• The information for titles for individual pages is certainly availaible (it gets used nicely in the table-of-contents in the left-bar). But it doesn't get properly used in the summaries on the right. For example, going to this summary page shows titles like Student/plot_options while the table-of-contents shows the much nicer Plot Options. It could be set out more nicely on the right as Student / Plot Options. There are many more unreadable examples, such as on the Error Message Guide summary here. Again, the table-of-contents demonstrates that the nicer name is available.

acer

I was so focused on the kludge. EmpiricalDistribution is just what you want.

> with(Statistics):
> X:=RandomVariable(EmpiricalDistribution(<0,0,0,0,1,2,2,2>)):
> Sample(X,10);
                   [0., 1., 0., 0., 0., 1., 0., 2., 0., 2.]
 
> Mean(X), evalf(Mean(Sample(X,1000000)));
                      0.875000000000000000, 0.8757290000
 
> CDF(X,-1), CDF(X,0), CDF(X,1), CDF(X,2), CDF(X,3);
                               0, 1/2, 5/8, 1, 1

Now, how to create the Vector V so that EmpiricalDistribution does whatever customized discrete distribution you want. How about this,

> L := [0=1/2,1=1/8,2=3/8]:
> l := lcm(seq(denom(rhs(x)),x in L)):
> V := Vector[row](l, [seq(lhs(x)$l*rhs(x), x in L)] );
                         V := [0, 0, 0, 0, 1, 2, 2, 2]

So then you should be able to use EmpiricalDistribution(V).

acer

I was so focused on the kludge. EmpiricalDistribution is just what you want.

> with(Statistics):
> X:=RandomVariable(EmpiricalDistribution(<0,0,0,0,1,2,2,2>)):
> Sample(X,10);
                   [0., 1., 0., 0., 0., 1., 0., 2., 0., 2.]
 
> Mean(X), evalf(Mean(Sample(X,1000000)));
                      0.875000000000000000, 0.8757290000
 
> CDF(X,-1), CDF(X,0), CDF(X,1), CDF(X,2), CDF(X,3);
                               0, 1/2, 5/8, 1, 1

Now, how to create the Vector V so that EmpiricalDistribution does whatever customized discrete distribution you want. How about this,

> L := [0=1/2,1=1/8,2=3/8]:
> l := lcm(seq(denom(rhs(x)),x in L)):
> V := Vector[row](l, [seq(lhs(x)$l*rhs(x), x in L)] );
                         V := [0, 0, 0, 0, 1, 2, 2, 2]

So then you should be able to use EmpiricalDistribution(V).

acer

Yes, thanks. I was only speaking directly to plots:-display rather than in general. But you bring up a good point.

As ?colondash indicates, since DEplot is not a protected name and may be also used as a local in the current scope, the truly safe form is DEtools[':-DEplot']. And, as you mention, because DEtools is table-based rather than a module, there is no choice to use the much nicer and equally safe :- form.

And here is the rub. For table-based packages, there is no nice :- form. So the only truly safe form is like A[':-B'] which is a pain. The are even some examples of potential problems documented on ?colondash which are only problematic for table-based packages. But with module-based packages the issue is almost entirely avoidable, just by going with :- instead of [] all the time.

The great pity, then, is that Maple's documentation uses the [] form throughout. I am confident that the Maple community could easily adapt to the :- form, even if it is a different syntax than for the few remaining (shrinking) number of table-based packages. There are several usage and convenience safety benefits, and the downside of syntax incompatibility with the shrinking number of old table-based packages is limited.

The only time that [] syntax might be needed for module-based package A is when all the entry points A[B] had to be formed and dealt with programmatically (and where exports(A) was not enough). Very few users will ever need to do that (except Joe R, of course!).

acer

Yes, thanks. I was only speaking directly to plots:-display rather than in general. But you bring up a good point.

As ?colondash indicates, since DEplot is not a protected name and may be also used as a local in the current scope, the truly safe form is DEtools[':-DEplot']. And, as you mention, because DEtools is table-based rather than a module, there is no choice to use the much nicer and equally safe :- form.

And here is the rub. For table-based packages, there is no nice :- form. So the only truly safe form is like A[':-B'] which is a pain. The are even some examples of potential problems documented on ?colondash which are only problematic for table-based packages. But with module-based packages the issue is almost entirely avoidable, just by going with :- instead of [] all the time.

The great pity, then, is that Maple's documentation uses the [] form throughout. I am confident that the Maple community could easily adapt to the :- form, even if it is a different syntax than for the few remaining (shrinking) number of table-based packages. There are several usage and convenience safety benefits, and the downside of syntax incompatibility with the shrinking number of old table-based packages is limited.

The only time that [] syntax might be needed for module-based package A is when all the entry points A[B] had to be formed and dealt with programmatically (and where exports(A) was not enough). Very few users will ever need to do that (except Joe R, of course!).

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

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