I don't think that the mistake was entirely of your doing. It's understandable.

Suppose it were the case that, for actual Matrices, the implicit multiplication (using space) were to return an error message such as "implicit multiplication not allowed for Matrices and Vectors, use . (dot) instead". People would quickly learn to use `.` instead of trying to use space, for Matrix/Vector multiplication.

Now consider what would happen if the implicit multiplication were to get some delay, so that dispatch to `.` vs `*` is done at run time instead of code for either call being inserted by the 2D Math parser. That scheme might work. But it might lead to some new bugs, as is the way of things. And it would involve another function call, which would make running such 2D code slower than running the 1D equivalent. Sure, it's just one function call, but inside nested loops....  Overhead creeps up.

By the way, if I recall your worksheet does something like this,

N . MatrixInverse(M);

For floating-point data that is not always numerically best. You can also use LinearSolve, which may have some more robust numeric behaviour (in problematic cases).

Transpose(LinearSolve(Transpose(M),Transpose(N)));

In order to keep it efficient, either all those transpositions can be done in-place, or the code might be reworked so that the transposed data is both generated and subsequently expected (thus removing the need for Transpose calls).

acer

Inside that loop, put a . (dot, not *) between N2 and M2. Then it seems to work fine.

It was a mistake to make Maple's implicit multiplication try and work for Matrices. The problem here is this. When N2 and M2 are in fact actually Matrices, then the implicit multiplication (space) dispatches off to `.` OK. That's why it works down below at the other end of your Document. But inside the loop, before it actually runs, Maple's Typesetting parser decides that N2 and M2 are unknown scalars. So it inserts a `*` under the hood to represent the implicit multiplication. But N2*M2 gives the error you see, when N2 and M2 eventually become actual Matrices.

There are just too many ways for objects to quietly become Matrices, for this sort of implicit multiplication scheme to work. It won't ever work properly if Typsetting has to resolve the "space" to either `.` or `*` before the actual running of the code. Really, it would only work if it somehow delayed the resolving, and kept an inert implicit multiplication. (In your high printlevel output, it shows calls to Typesetting:-delayDotProduct, so maybe that is supposed to be deferring this dispatch.)

acer

You said that you "redefined everything", but it shows C*3[Sigma] right below that. That is the source of the error message.

> 3[Sigma];
syntax error, `[` unexpected:

Why not "redefine everything with" with C3[Sigma] instead? Or perhaps `C3`[Sigma] to try and force the 2D Math parser. I agree with Alec here; if you have these sorts of problems, and you cannot figure them out, then you should probably be using 1D Maple notation rather than 2D Math input.

acer

One counter-example to your claim about relative community support is this very site. What is there for Mathematica that compares with mapleprimes?

It would be interesting to see a detailed list of the mathematical features that you (or others) would most like to see implemented in Maple.

acer

Mario,

The term "decimal number" in that help-page is used to mean that the whole (integer) number is expressed in base 10, not that it is a number with a decimal point in it (as is a common meaning in lower school).

acer

Increase Digits for more accuracy.

> gen := proc(n)
> local N,W,P;
> N:=`evalf/int/AGQ/AGQ_wr`(n,'W','P');
> if type(n,odd) then
>   [seq(P[i],i=1..N),seq(1-P[N-i],i=1..N-1)],
>   [seq(W[i],i=1..N),seq(W[N-i],i=1..N-1)];
> else
>   [seq(P[i],i=1..N),seq(1-P[N-i+1],i=1..N)],
>   [seq(W[i],i=1..N),seq(W[N-i+1],i=1..N)];
> end if;
> end proc:

> gen(7);
[0.02544604383, 0.1292344072, 0.2970774243, 0.5, 0.7029225757, 0.8707655928,
 
    0.9745539562], [0.06474248308, 0.1398526957, 0.1909150253, 0.2089795918,
 
    0.1909150253, 0.1398526957, 0.06474248308]
 
> gen(8);
[0.01985507175, 0.1016667613, 0.2372337950, 0.4082826788, 0.5917173212,
 
    0.7627662050, 0.8983332387, 0.9801449282], [0.05061426815, 0.1111905172,
 
    0.1568533229, 0.1813418917, 0.1813418917, 0.1568533229, 0.1111905172,
 
    0.05061426815]

Alternatively,

> kernelopts(opaquemodules=false):

> P,W:=Student:-NumericalAnalysis:-gauleg(7):
> map(t->(t+1)/2,P);
[0.0254460438, 0.1292344072, 0.2970774243, 0.5000000000, 0.7029225757,
 
    0.8707655928, 0.9745539562]
 
> W/2;
[0.06474248310, 0.1398526958, 0.1909150252, 0.2089795918, 0.1909150252,
 
    0.1398526958, 0.06474248310]

> P,W:=Student:-NumericalAnalysis:-gauleg(8):
> map(t->(t+1)/2,P);
[0.0198550718, 0.1016667613, 0.2372337950, 0.4082826788, 0.5917173212,
 
    0.7627662050, 0.8983332387, 0.9801449282]
 
> W/2;
[0.05061426815, 0.1111905172, 0.1568533230, 0.1813418917, 0.1813418917,
 
    0.1568533230, 0.1111905172, 0.05061426815]

acer

The Translator produces equivalent commands by default, rather than both producing and then evaluating them.

One can see that MmaTranslator:-Mma:-Get would actually do something (but only if the resulting command is run or evaluated, naturally).

> interface(verboseproc=3):

> eval(MmaTranslator:-Mma:-Get);
proc()
local line, last;
    last := readline(args);
    line := last;
    while line <> 0 do last := line; line := readline(args) end do;
    last
end proc

If the MmaTranslator:-MmaToMaple assistant is run, then it produces just the equivalent. It has a checkbox, off by default, to toggle evaluating the equivalent command.

Both the MmaTranslator and the Matlab:-FromMatlab systems have some "Maple runtime" routines. Some Mathematica commands (such as your Get example) are translated to equivalents in the respective runtimes. The functionality which has to be produced might not already exist as some other Maple routine outside of those "runtimes". In some sense, these packages can be seen partly as emulators rather than wholly translators. That's my take, anyway.

acer

The expressions you've given for LF1 and LF2 appear to be the same. But I think that I understand what you're after -- a global maximum. And using Optimization:-NLPSolve for the bivariate expression you are getting only local maxima which differ according to the supplied ranges, etc.

The NLPSolve command is supposed to be able to do global optimization for univariate expressions, however. And your bivariate expression can be see as the product of two univariate expressions (one in terms of only p, and the other in terms of only lambda). At the global max of the bivariate expression, won't those two separated univariate expressions either attain their global positive max or global negative mins (together)?

# Exponents are high, so increase digits.
> restart:

> part1 := Optimization:-NLPSolve((1-p)^12 * p^6, p = 0.1..0.9,
>              method=branchandbound, nodelimit=100, maximize);
part1 := [0.000010572491946857255657431169057246221172365512139963253208324\
 
    76673684648619603595616751183234400388153, [p = 0.333333333333333333333\
    33333333333333333333333333333736020909385629132457466811964496740584798\
 
    92106085]]

> part2 := Optimization:-NLPSolve(lambda^20/((exp(lambda))^6*(1-1/exp(lambda))^6),
>              lambda=1..10, method=branchandbound, nodelimit=100, maximize);
part2 := [74.64332738477354229696423984447562230886661996047134706648672868\
 
    808536810802011914892463634162665307, [lambda = 3.197059146345953482481\
    14658306428866389061101553410448249261020291420127792868684784402879499\
 
    2627541]]

> 1/1658880 * part1[1] * part2[1];
0.4757221605312909515206819021881908456041938871196218125541162231701706979\
 
                                  -9
    031545368422338561424874866 10

> LF:=(1/1658880)*(1-p)^12*p^6*lambda^20\
> /((exp(lambda))^6*(1-1/exp(lambda))^6):

> eval(LF,[part1[2][1],part2[2][1]]);
0.4757221605312909515206819021881908456041938871196218125541162231701706979\
 
                                  -9
    031545368422338561424874865 10
 
> part1[2][1], part2[2][1];
p = 0.333333333333333333333333333333333333333333333333337360209093856291324\
 
    5746681196449674058479892106085, lambda = 3.197059146345953482481146583\
    06428866389061101553410448249261020291420127792868684784402879499262754\
    1

Checking with the (add-on) GlobalOptimization package,

> LF:=(1/1658880)*(1-p)^12*p^6*lambda^20\
> /((exp(lambda))^6*(1-1/exp(lambda))^6):
> GlobalOptimization:-GlobalSolve(LF,p=0\
> .1..0.9,lambda=1..10,maximize,method=multistart);
                        -9
[0.475490028627130724 10  ,
 
    [p = 0.331418551180686749, lambda = 3.17705810474458694]]

acer

A record of the commands issued during a session of the commandline (console, TTY) Maple interface can also be saved.

See the options --historyfile=histFile and --historysize=histSize in the ?maple help-page. The history file can be specified when the session is invoked, while the default is ~/.maple_history .

acer

See the help-pages for ssystem and system.

acer

I'm not sure if this is the same phenomenon as you are seeing, but the Maple 12.xx Standard GUI has problems with delayed rendering in some Linux distributions. AFAIK, it can occur in "older" distributions. It might be related to a clash between an "old" glibc and the "newer" JRE. The problem manifests itself as a 5-10 sec white pause over the whole GUI output canvas. It occurs especially after pasting.

It had nothing to do with plots. Since, small expressions would get it too. Oh, and on a machine that had it, it would occur at a slightly shorter delay for every output.

On an old Fedora box of mine the problem was very bad in 12.xx but has improved in 13. If you are stuck with Maple 12 for a while, then you might consider upgrading your distribution. I don't know of the problem occuring on any current Linux distro.

acer

Could you post the actual code, or upload a worksheet for that to this site?

acer

In Maple 9.5.1, for Matrix M,

rtable_scanblock( M, [rtable_dims(M)],'Maximum');

acer

I, for one, welcome the new Japanese overlords.

acer

You might fiddle with something like this, either to customize with your own time interval length, adjust the rounding/truncating, or even whether to print it or to refresh a Component.

The time interval used below, throughout, is 5 sec. Adjust to taste.

One can handle the case that Maple has a Thread-blocking operation (gc, simpl table write, etc) going on right at the 5sec rollover. Below, that case should be handled by printing at the next opportunity, while also resetting the tick-point.

You mentioned realtime. That is very difficult to do very well, with assurances.

p := proc() local X,oldX,f;
  f := proc() local i; for i from 1 to 100000 do i+i;
                       end do;
       end proc;
  oldX:=0;
  while true do
    X:=time[real]();
    if X-oldX<=5 then f();
    else
      if (X-oldX>=5 or `mod`(trunc(X),5)=0) then
        print(X); oldX:=X; f();
      else f();
      end if;
    end if;
  end do;
end proc:
                                                                                
Threads:-Create(p());
                                                                                
int(exp(x^101/(x^11102-3)),x);

I only tried on a single core machine, where it seemed to work ok. Experience on multi-core might be interesting.

acer