A few more ideas, for manipulating this result. (This is crude. You'd likely want it much more bulletproof and sophisticated. And it'd likely end up much different, if done carefully and properly.)

Continuing from the above...

> H:=Typesetting:-Parse(op(fromdotm)):

> HH:=remove(type,
>        StringTools:-Split(convert(op(-1,eval(H,1)),string),"1;"),
>        identical(" ",""));

                     ["A := 4", " B := 7"]

> seq(eval(parse(t)), t in HH):

> A, B;
                              4, 7

I'm not sure that I understand what part you plan for python in this. If you were to implement the entire scripting process using commandline Maple itself then you might more easily utilize (or get more ideas from) the exports of the `Worksheet`, `XMLTools`, and `Typesetting` packages.

[Also, some curiosities of scripting with commandline Maple.]

acer

A few more ideas, for manipulating this result. (This is crude. You'd likely want it much more bulletproof and sophisticated. And it'd likely end up much different, if done carefully and properly.)

Continuing from the above...

> H:=Typesetting:-Parse(op(fromdotm)):

> HH:=remove(type,
>        StringTools:-Split(convert(op(-1,eval(H,1)),string),"1;"),
>        identical(" ",""));

                     ["A := 4", " B := 7"]

> seq(eval(parse(t)), t in HH):

> A, B;
                              4, 7

I'm not sure that I understand what part you plan for python in this. If you were to implement the entire scripting process using commandline Maple itself then you might more easily utilize (or get more ideas from) the exports of the `Worksheet`, `XMLTools`, and `Typesetting` packages.

[Also, some curiosities of scripting with commandline Maple.]

acer

Right. Good job. For a few major releases now, non-evalhf'able commands can be executed within an evalhf'd procedure if they are wrapped in an `eval` call.

The (faster) evalhf callback from the openmaple API may be usable, then, with this trick. But the evaluation of the particular piece inside that extra `eval` is not actually interpreted under evalhf. The extra `eval` is behaving like a temporary escape from evalhf back to Maple's regular interpreter.

Exceptions to this behaviour include module member calls, like A:-B(blah), for which evalhf will still complain. One way to get around that is to instead call eval(H(blah)) where H is another procedure which itself calls A:-B.

acer

Right. Good job. For a few major releases now, non-evalhf'able commands can be executed within an evalhf'd procedure if they are wrapped in an `eval` call.

The (faster) evalhf callback from the openmaple API may be usable, then, with this trick. But the evaluation of the particular piece inside that extra `eval` is not actually interpreted under evalhf. The extra `eval` is behaving like a temporary escape from evalhf back to Maple's regular interpreter.

Exceptions to this behaviour include module member calls, like A:-B(blah), for which evalhf will still complain. One way to get around that is to instead call eval(H(blah)) where H is another procedure which itself calls A:-B.

acer

@icegood As far a I know, the `LerchPhi` command is not evalhf'able.

@icegood As far a I know, the `LerchPhi` command is not evalhf'able.

As an illustration of my points, here is a comparison of two ways to get a 4th derivative as a procedure or operator.

The first way, obtaining operator `Fxxxx`, is quite similar to what you do in your worksheet. The alternative way involves just using the `diff` command, with `unapply` used on the result just once.

The alternative way, obtaining operator `otherFxxxx`, takes about 1000 times less time to produce the derivative operator, and evaluates that numerically at a point about 100 times faster than does the original way's `Fxxxx` operator.

restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

F:=unapply(expr,x):

Fx:=CodeTools:-Usage( unapply(evalf(simplify(diff(F(x),x))),x) ):
memory used=13.92MiB, alloc change=11.37MiB, cpu time=249.00ms, real time=244.00ms

Fxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fx(x),x))),x) ):
memory used=62.31MiB, alloc change=29.74MiB, cpu time=780.00ms, real time=771.00ms

Fxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxx(x),x))),x) ):
memory used=0.75GiB, alloc change=47.87MiB, cpu time=11.08s, real time=11.09s

Fxxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxxx(x),x))),x) ):
memory used=7.03GiB, alloc change=363.68MiB, cpu time=4.75m, real time=4.76m

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=328.11KiB, alloc change=0 bytes, cpu time=0ns, real time=4.00ms

CodeTools:-Usage( Fxxxx(2.3) );
memory used=89.73MiB, alloc change=0 bytes, cpu time=1.37s, real time=1.38s

                         -0.8163268164

CodeTools:-Usage( otherFxxxx(2.3) );
memory used=1.55MiB, alloc change=0 bytes, cpu time=16.00ms, real time=19.00ms

                         -0.8163268116

The alternative way is so very fast that it could also be used to produce separate operators for each of the 1st, 2nd, 3rd, and 4th derivatives, assign each of those to operators as well. But each subsequent derivative would be produced using `diff` applied to the previous expression rather that function applications, and there would be no dubious `simplify` and `evalf` combined actions going on. Keeping each of the four derivatives, and producing four operators, should only be four times slower than the alternative shown above, not one thousand times slower.

You can mess around with option `numeric` on all your original `unapply` calls. But I believe that the approach is still fundamentally misguided.

Especially unfortunate is using `simplify` on a symbolic expression which contains floating-point coefficients, as this often tends to get the opposite effect and produce a much longer expression rather than a simpler one. But for your example, with all those LerchPhi calls, it might even be just `simplify` alone which is the biggest problem.

Here is generation of distinct operators for all the derivatives from 1st to 4th, but without the evalf@simplify,

restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=386.71KiB, alloc change=255.95KiB, cpu time=0ns, real time=8.00ms

st:=time():
F:=unapply(expr,x):
Fx_expr:=diff(F(x),x):
Fx:=unapply(Fx_expr,x): # don't create, if not to be used
Fxx_expr:=diff(Fx(x),x):
Fxx:=unapply(Fxx_expr,x): # don't create, if not to be used
Fxxx_expr:=diff(Fxx(x),x):
Fxxx:=unapply(Fxxx_expr,x): # don't create, if not to be used
Fxxxx_expr:=diff(Fxxx(x),x):
time()-st;
                             0.015

Fxxxx:=CodeTools:-Usage( unapply(Fxxxx_expr,x) ):
memory used=512 bytes, alloc change=0 bytes, cpu time=16.00ms, real time=3.00ms

CodeTools:-Usage( otherFxxxx(2.9) );
memory used=1.57MiB, alloc change=1.25MiB, cpu time=21.00ms, real time=22.00ms

                          -3.567059374

CodeTools:-Usage( Fxxxx(2.9) );
memory used=1.52MiB, alloc change=1.25MiB, cpu time=16.00ms, real time=17.00ms

                          -3.567059374

acer

As an illustration of my points, here is a comparison of two ways to get a 4th derivative as a procedure or operator.

The first way, obtaining operator `Fxxxx`, is quite similar to what you do in your worksheet. The alternative way involves just using the `diff` command, with `unapply` used on the result just once.

The alternative way, obtaining operator `otherFxxxx`, takes about 1000 times less time to produce the derivative operator, and evaluates that numerically at a point about 100 times faster than does the original way's `Fxxxx` operator.

restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

F:=unapply(expr,x):

Fx:=CodeTools:-Usage( unapply(evalf(simplify(diff(F(x),x))),x) ):
memory used=13.92MiB, alloc change=11.37MiB, cpu time=249.00ms, real time=244.00ms

Fxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fx(x),x))),x) ):
memory used=62.31MiB, alloc change=29.74MiB, cpu time=780.00ms, real time=771.00ms

Fxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxx(x),x))),x) ):
memory used=0.75GiB, alloc change=47.87MiB, cpu time=11.08s, real time=11.09s

Fxxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxxx(x),x))),x) ):
memory used=7.03GiB, alloc change=363.68MiB, cpu time=4.75m, real time=4.76m

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=328.11KiB, alloc change=0 bytes, cpu time=0ns, real time=4.00ms

CodeTools:-Usage( Fxxxx(2.3) );
memory used=89.73MiB, alloc change=0 bytes, cpu time=1.37s, real time=1.38s

                         -0.8163268164

CodeTools:-Usage( otherFxxxx(2.3) );
memory used=1.55MiB, alloc change=0 bytes, cpu time=16.00ms, real time=19.00ms

                         -0.8163268116

The alternative way is so very fast that it could also be used to produce separate operators for each of the 1st, 2nd, 3rd, and 4th derivatives, assign each of those to operators as well. But each subsequent derivative would be produced using `diff` applied to the previous expression rather that function applications, and there would be no dubious `simplify` and `evalf` combined actions going on. Keeping each of the four derivatives, and producing four operators, should only be four times slower than the alternative shown above, not one thousand times slower.

You can mess around with option `numeric` on all your original `unapply` calls. But I believe that the approach is still fundamentally misguided.

Especially unfortunate is using `simplify` on a symbolic expression which contains floating-point coefficients, as this often tends to get the opposite effect and produce a much longer expression rather than a simpler one. But for your example, with all those LerchPhi calls, it might even be just `simplify` alone which is the biggest problem.

Here is generation of distinct operators for all the derivatives from 1st to 4th, but without the evalf@simplify,

restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=386.71KiB, alloc change=255.95KiB, cpu time=0ns, real time=8.00ms

st:=time():
F:=unapply(expr,x):
Fx_expr:=diff(F(x),x):
Fx:=unapply(Fx_expr,x): # don't create, if not to be used
Fxx_expr:=diff(Fx(x),x):
Fxx:=unapply(Fxx_expr,x): # don't create, if not to be used
Fxxx_expr:=diff(Fxx(x),x):
Fxxx:=unapply(Fxxx_expr,x): # don't create, if not to be used
Fxxxx_expr:=diff(Fxxx(x),x):
time()-st;
                             0.015

Fxxxx:=CodeTools:-Usage( unapply(Fxxxx_expr,x) ):
memory used=512 bytes, alloc change=0 bytes, cpu time=16.00ms, real time=3.00ms

CodeTools:-Usage( otherFxxxx(2.9) );
memory used=1.57MiB, alloc change=1.25MiB, cpu time=21.00ms, real time=22.00ms

                          -3.567059374

CodeTools:-Usage( Fxxxx(2.9) );
memory used=1.52MiB, alloc change=1.25MiB, cpu time=16.00ms, real time=17.00ms

                          -3.567059374

acer

@Samir Khan Thanks!

(Grist for the efficiency mill.)

Please forgive me if I've missed it in some hidden code block or region in that uploaded worksheet, but I don't see any code to reproduce these images in Maple.

I don't see how anyone could properly assess whether Maple can produce such plots or images using a reasonable amount of time and memory resources, without source code or a worksheet which successfully reproduces the results.

acer

This is very good news for Maple.

The first few areas I would suggest are,

• Advanced plotting: The toolset is quite powerful, but since there will always be many custom needs there will never be a canned solution for every task and problem. Showing how the plotting facilities can do wonders, when combined with even a little programming (not a dirty word), would be a great addition.
  
  
• Applied DEs: Applied problems with symbolic DE solutions, or at least some measure of mathematically driven symbolic analysis. (One topic that comes to mind is Control. Another is Delay DEs.)

acer

@epostma Did you intend to include the option 'output'='residualsumofsquares' in the `Fit` call in procedure `minsumsq`?

Like this. say,

minsumsq := c -> Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c),
                                            [.74e-4, .1806e-3, .584e-4],
                                            output=residualsumofsquares):

plot(minsumsq,-10..3.04);

Just because a fitting problem does not have finite optimal parameter values does not mean that there is no limiting curve for the fit that it continuous between the original independent data points. For example, the constant function x -> 0.00009207055709 may approximately "fit the bill" in such a limiting sense.

All pretty moot, anyway, for 3 data points and only conjecture as to what the poster wanted.

ps. If the error weighting were not by exponential fitting then there may be finite optimal parameter values here.

@epostma Did you intend to include the option 'output'='residualsumofsquares' in the `Fit` call in procedure `minsumsq`?

Like this. say,

minsumsq := c -> Statistics:-ExponentialFit(ln~([3.05, 3.1, 3.75] -~ c),
                                            [.74e-4, .1806e-3, .584e-4],
                                            output=residualsumofsquares):

plot(minsumsq,-10..3.04);

Just because a fitting problem does not have finite optimal parameter values does not mean that there is no limiting curve for the fit that it continuous between the original independent data points. For example, the constant function x -> 0.00009207055709 may approximately "fit the bill" in such a limiting sense.

All pretty moot, anyway, for 3 data points and only conjecture as to what the poster wanted.

ps. If the error weighting were not by exponential fitting then there may be finite optimal parameter values here.

I suspect that what's Axel is driving at is,

expr:=R*D^2 / ( R*D^2 + s*L + s^2*R*L*C );

                                           2         
                                        R D          
                        expr := ---------------------
                                   2          2      
                                R D  + s L + s  R L C


1/expand(1/expr);

                                      1        
                              -----------------
                                          2    
                                  s L    s  L C
                              1 + ---- + ------
                                     2      2  
                                  R D      D   

acer

I suspect that what's Axel is driving at is,

expr:=R*D^2 / ( R*D^2 + s*L + s^2*R*L*C );

                                           2         
                                        R D          
                        expr := ---------------------
                                   2          2      
                                R D  + s L + s  R L C


1/expand(1/expr);

                                      1        
                              -----------------
                                          2    
                                  s L    s  L C
                              1 + ---- + ------
                                     2      2  
                                  R D      D   

acer