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

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