> a1_Func := (t)-> t^2 + t + 1;
                                           2
                          a1_Func := t -> t  + t + 1
 
> a2_Func := D(a1_Func);
                            a2_Func := t -> 2 t + 1
 
> a1_Func(4);
                                      21
 
> a2_Func(4);
                                       9

acer

The Units Calculator (Assistant) is (in Maple 12 and 13) just a worksheet with some embedded components and some hidden code (collapsed/hidden document blocks, and bits of various component-property code). You can edit that code, and it shouldn't be very hard to add more conversions to it.

You could actually save the worksheet that shows the Calculator, when finished. Then you could launch it when you wanted (either using File->Open, or using an `INTERFACE_WORKSHEET` call, or replacing the renamed installed original if you felt brave).

But is that what would really help you? The results of that Assistant cannot be returned directly to your original worksheet, can they? So you'd have to cut and paste them, in order to make further use of the results.

Perhaps you'd find it just as useful to call convert/units?

> 1 / convert(17., 'units', miles/gal, 100*km/L );
                                  13.83615196

> 1 / convert(35., 'units', miles/gal, 100*km/L );
                                  6.720416667

You could write short procedures to convert, say, back and forth between miles/gallon and litres/100km. You could save those procedures in a .mla Library archive, for quick re-use in any worksheet. You could then call them straight, or you could insert a pair of input/output components in any new worksheet that needed them dynamically. Then the values could be assigned (to globals in the component property code, say) and programmatically re-used outside of the components. Or you could write (and save-to-archive) a re-usable Maplet that could also return the results directly.

acer

This is just string manipulation. If it doesn't quite do what you're after then it should be easy to adjust. I wasn't sure to which length you wanted to pad with zeros in the hex representation. (I chose 4, but changing that is simple.)

> p := proc(x::string)
> local xlength, n, paddedx, i, r;
> n:=iquo(length(x),4,'r');
> if r<>0 then n:=n+1; paddedx:=cat(seq("0",i=1..(4-r)),x);
> else paddedx:=x; end if;
> cat(seq([StringTools:-LengthSplit(paddedx,2)][n*2-i+1],
>         i=1..n*2));
> end proc:

> X:="18DBD3547552C73BE4DE87731C500":
> p(X);
                      "00C53177E84DBE732C554735BD8D0100"

> p("DCBA9876");
                                  "7698BADC"
 
> p("DCBA987654");
                                "547698BADC00"

If you wanted to take your original base-10 number X (as a numeric rather than as a string) and convert to hexadecimal using Maple's convert(X,base,16), then the procedure could act similarly but do equivalent list manipulation instead.

acer

See here.

acer

I suspect that the problem relates to lack of special evaluation rules some place under Units:-Standard:-add, so that it tries to evaluate x[k] an rtable reference for unspecified k. Maybe that gets caught, and a bad arguments error re-thrown. Just a guess.

The quantities being added have just simple units attached to them all (meters). So It's not necessary to get the smarts of Units:-Standard:-add in order to add them up while resolving different mixed units. So :-add should suffice.

In short, it may be that replace those sum calls with :-add calls could work, while keeping the subpackage loading by with(Units:-Standard).

There's a later error for assign(%), but perhaps that is an oversight by the author.

BTW, the line with Units[UseSystem](SI) appears to be plain text and not a command. But that's the default anyway, so it'd make no difference.

Oops I submitted this as reply to the main thread, while it relates to Doug's subthread. Sorry.

acer

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