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

Which operating system are you running?

When this problem occurs, is it always the case that there is a worksheet which has been already opened with Maple 15 and minimized to the tray? Is so, then can you maximize that? If you cannot maximize that with the mouse-pointer, and if you are on MS-Windows, then can you maximize if using the <Alt>-hold and <tab> key press?

acer

@PatrickT Please do follow the link in the Comment by pagan. It shares themes with that fast-complex-argument-images Post -- the fastest way to assemble high quality, high density images of mathematical functions in Maple is to act inplace upon hardware datatype rtable with the Compiler.

Other techniques for computing fractal images used in some Application Center uploads (`option hfloat`, or Threads or Grid -- often submitted to use some method that was in vogue) are alone not nearly as fast or efficient.

It may be possible to combine Threads/Task and compiled routines. But since it's not obvious that the Compiler's external-call runtime is thread-safe, it might be necessary to use a Poor Man's Compiler [here & here]. Different techniques are needed for two cases: when the user has already pre-Compiled the mathematical function which must then be used to populate the rtable (eg. for regular plot creation), and when the function and rtable-populating are combined into one single procedure (eg. fractal image creation).

I'd like to finish and submit a posting on the first of those two: fast generation of high density plots/images using a pre-Compiled procedure.

One day this may all be automatic... and people reading these esoteric methods may feel a strange sensation similar to what we can now get re-reading old books on specialized non-digital exposed-film-camera techiques.

None of this relates directly to your projection problem. I asked about curves-vs-surfaces because I was immediately worried about the overlay. I haven't thought of an effective solution to that issue.

acer

@PatrickT Please do follow the link in the Comment by pagan. It shares themes with that fast-complex-argument-images Post -- the fastest way to assemble high quality, high density images of mathematical functions in Maple is to act inplace upon hardware datatype rtable with the Compiler.

Other techniques for computing fractal images used in some Application Center uploads (`option hfloat`, or Threads or Grid -- often submitted to use some method that was in vogue) are alone not nearly as fast or efficient.

It may be possible to combine Threads/Task and compiled routines. But since it's not obvious that the Compiler's external-call runtime is thread-safe, it might be necessary to use a Poor Man's Compiler [here & here]. Different techniques are needed for two cases: when the user has already pre-Compiled the mathematical function which must then be used to populate the rtable (eg. for regular plot creation), and when the function and rtable-populating are combined into one single procedure (eg. fractal image creation).

I'd like to finish and submit a posting on the first of those two: fast generation of high density plots/images using a pre-Compiled procedure.

One day this may all be automatic... and people reading these esoteric methods may feel a strange sensation similar to what we can now get re-reading old books on specialized non-digital exposed-film-camera techiques.

None of this relates directly to your projection problem. I asked about curves-vs-surfaces because I was immediately worried about the overlay. I haven't thought of an effective solution to that issue.

acer

@PatrickT Are you asking why that `cast` doesn't work the same whether or not you put it into a call to typeset(), in a plot caption? I think it just needs some tweaking and correcting, to satisfy some pickier and less forgiving parser.

Consider, in a Worksheet in Maple 15 and outside of any typeset() environment for plot captions, etc. With the original `cast` above,

seq(cast(i*Pi/4),i=1..4);

Typesetting:-Typeset('%');

So now let's edit it a bit.

cast:=proc(r)
local n,d,t,top;
  n,d:=numer(r),denom(r);
  if type(n,`*`) then
    top:=cat(`mrow(`,cat(`mn("`,convert(op(1,n),string),`")`),
             seq(cat(`,mn(`,convert(op(t,n),string),`)`),t=2..nops(n)));
  else
    top:=cat(`mrow(`,cat(`mn("`,convert(n,string),`")`));
  end if;
  if d<>1 then
    cat(`#mfrac(`,top,`),`,cat(`mn("`,convert(d,string),`")`),`)`);
  else
    cat(`#`,top,`)`);
  end if;
end proc:

seq(cast(i*Pi/4),i=1..4);

Typesetting:-Typeset('%');

Anyway, you could give it a go.

@PatrickT The help-page for topic `value` appears to already have a help-alias for `ditto`.

In Maple 15 with the Standard GUI, if I enter ?% in a worksheet (or if I search for & in an open Help window) then the Help system opens to the `ditto` help-page, sure. But that Help browser's "search" tab on the left shows two matches. One match is for topic `ditto`, and the other match is for topic `value`. So this aspect is already working.

And only one topic can be the default, which actually gets opened automatically. It's understandable that it's the page of the more commonly used ditto functionality.

Maybe the GUI could learn from Wikipedia here: when an ambiguous query is submitted then a default page is shown, but at the top of that page there is a brief note and link to a disambiguation page for that query. The same could be done with Help aliases: if there is more than one match then a brief line and disambiguation link could be inserted on-the-fly into the displayed help content. Not everyone looks at the search/match results, when there is a page opened automatically in the larger right display pane.

@PatrickT The help-page for topic `value` appears to already have a help-alias for `ditto`.

In Maple 15 with the Standard GUI, if I enter ?% in a worksheet (or if I search for & in an open Help window) then the Help system opens to the `ditto` help-page, sure. But that Help browser's "search" tab on the left shows two matches. One match is for topic `ditto`, and the other match is for topic `value`. So this aspect is already working.

And only one topic can be the default, which actually gets opened automatically. It's understandable that it's the page of the more commonly used ditto functionality.

Maybe the GUI could learn from Wikipedia here: when an ambiguous query is submitted then a default page is shown, but at the top of that page there is a brief note and link to a disambiguation page for that query. The same could be done with Help aliases: if there is more than one match then a brief line and disambiguation link could be inserted on-the-fly into the displayed help content. Not everyone looks at the search/match results, when there is a page opened automatically in the larger right display pane.