@Feryal In Maple 14.01, on Windows, it worked for me (after adding missing semicolons to ends of lines) if the result from the final call to animate got another evaluation.

Ie, using,

eval(animate(display, [g(p)], r=-1..1));

How come you use your own transformer, instead of using plottools:-rotate?

By some weird coincidence, I was just working on an efficiency improvement to how plottools:-rotate does this task, but for 3D. It makes a nice improvement, since plottools:-rotate always converts a float[8] rtable inside a GRID or MESH into a list of lists. It's more efficient to produce another float[8] rtable instead. And it's even more efficient, if rotation is all that happening for the animation, to do it in-place on the original rtable. (I'll edit this later, hopefully with some useful code, and also properly cite Joe Riel who first posted that superb inplace trick, by having the plot structure merely reference a 2D PLOT rtable by name. But I have to do something else for a few hours.) Anyway, stay tuned if you're interested in squeezing this to be as fast as possible.

acer

@PatrickT Just an idea, for a stripper of trailing zeroes,

restart:

P:=piecewise(t < 10., (.50*(1-.100*t))*exp(-0.500e-1*t)
                       +.50*exp(-.10*t), .50*exp(-.10*t)):

strip:=Z->subsindets(Z,{float},z->parse(sprintf("%g",z))):

plot(P,legend=[D(t)=strip(P)]);

plot(P,legend=[D(t)=evalf[3](strip(P))]);

Another possible advantage of the first of those pair above, over simply hitting the whole expression with `evalf[d]`, is that constants like Pi can be preserved.

You may have to slightly resize or stretch the inlined plot, if you want the legend items to be typeset all on a single line. This is a more general issue, and not related to methods suggested here, I think.

Another variant is,

strip:=(Z,d)->subsindets(Z,{float},z->evalf[d](parse(sprintf("%g",z)))):

bug?: when using so-called array-plots (like plots:-display(Array([plot(..),..plot(..)]))) the piecewise structure is not nicely typeset as 2D in the legend.

As for the subject of legend placement, it maybe that for many plots a very nice location would be in the blank, white area that can fall inside the axes area itself. For this plot, a slightly smaller sized legend in the top-right corner of the axes-boxed region could be a very economical and appealing use of the space. And Maple is powerful enough to code such a determination (including whether its even feasible, for any given plot). It's just more involved.

@PatrickT Just an idea, for a stripper of trailing zeroes,

restart:

P:=piecewise(t < 10., (.50*(1-.100*t))*exp(-0.500e-1*t)
                       +.50*exp(-.10*t), .50*exp(-.10*t)):

strip:=Z->subsindets(Z,{float},z->parse(sprintf("%g",z))):

plot(P,legend=[D(t)=strip(P)]);

plot(P,legend=[D(t)=evalf[3](strip(P))]);

Another possible advantage of the first of those pair above, over simply hitting the whole expression with `evalf[d]`, is that constants like Pi can be preserved.

You may have to slightly resize or stretch the inlined plot, if you want the legend items to be typeset all on a single line. This is a more general issue, and not related to methods suggested here, I think.

Another variant is,

strip:=(Z,d)->subsindets(Z,{float},z->evalf[d](parse(sprintf("%g",z)))):

bug?: when using so-called array-plots (like plots:-display(Array([plot(..),..plot(..)]))) the piecewise structure is not nicely typeset as 2D in the legend.

As for the subject of legend placement, it maybe that for many plots a very nice location would be in the blank, white area that can fall inside the axes area itself. For this plot, a slightly smaller sized legend in the top-right corner of the axes-boxed region could be a very economical and appealing use of the space. And Maple is powerful enough to code such a determination (including whether its even feasible, for any given plot). It's just more involved.

This was a good idea 4 years ago, and seems just as good today(!).

Do you imagine that in practice one might actually need an explicit formula (eg. symbolic expression, or piecewise of same)?

Or would it suffice to have returned some black-box procedure which could be efficiently polled for values. Ie. you supply a single numeric point and it returns a scalar numeric result. Such a procedure could (if you deem it wise) be numerically integrated, or searched for extrema, etc, as well as used to get the pointwise squared residuals.

Having both 2D and 3D versions could also be nice.

Implementing this might be fun, especially for 3D. Inherently expensive... so lots of motive for parsimony. A crude first attempt might just leverage Statistics:-Fit, with repeated calls according to the window-width. (Oh, for a 48hr day...)

acer

@Markiyan Hirnyk The tougher challenge is to have a root-finder get a real root for this problem when not supplied with a narrow search range.

@Markiyan Hirnyk The tougher challenge is to have a root-finder get a real root for this problem when not supplied with a narrow search range.

The example you show is not at all in the same class as the example submitted in the Question. The example you give is zero only at a jump discontinuity (from both real directions). The problem posted involves an expresion which is continuous (with value existing and equal to the limit from both sides) at the root.

It's not reasonable to expect a numerical solver to find the root of your contrived example. But it is reasonable to ask whether any numeric solver could find the root of the posted problem. It's a moderately tough problem if the narrow range is "allowed", based the precision/accuracy question, and it's a still harder problem if the solver is expect to find it given a wider, looser supplied range.

acer

The example you show is not at all in the same class as the example submitted in the Question. The example you give is zero only at a jump discontinuity (from both real directions). The problem posted involves an expresion which is continuous (with value existing and equal to the limit from both sides) at the root.

It's not reasonable to expect a numerical solver to find the root of your contrived example. But it is reasonable to ask whether any numeric solver could find the root of the posted problem. It's a moderately tough problem if the narrow range is "allowed", based the precision/accuracy question, and it's a still harder problem if the solver is expect to find it given a wider, looser supplied range.

acer

@Markiyan Hirnyk It's quite a hard root to find, when searching purely over the reals.

I don't know much about how DirectSearch works internally so I can't say much else on why it fails to find that negative real root of this example, except that it's a hard problem.

Is there also a positive root?

One thing I found interesting is that for this example fsolve found a purely real root "more easily" when being allowed to compute over the complex numbers, ie. with comparitively low Digits=20 and a much looser range (box). Partly that was luck, as I didn't specify an initial point and there are other, nonreal roots about. But it makes it an even more interesting example.

acer

   "Man is the measure of all things: of those which are, that they are;
         of those which are not, that they are not."
                                                       - Protagoras

@Markiyan Hirnyk It's quite a hard root to find, when searching purely over the reals.

I don't know much about how DirectSearch works internally so I can't say much else on why it fails to find that negative real root of this example, except that it's a hard problem.

Is there also a positive root?

One thing I found interesting is that for this example fsolve found a purely real root "more easily" when being allowed to compute over the complex numbers, ie. with comparitively low Digits=20 and a much looser range (box). Partly that was luck, as I didn't specify an initial point and there are other, nonreal roots about. But it makes it an even more interesting example.

acer

   "Man is the measure of all things: of those which are, that they are;
         of those which are not, that they are not."
                                                       - Protagoras

@steweb You could name your assisting procedures, as I did in the example with `thatproc`. That seems to allow the results from `simplify` to also use that same name where appropriate in the output.

If you only ever need to apply the resulting procedure, then you might even be ok leaving it as is. By which I mean that since the escaped local `f` seems to evaluate to the right procedural body, then applying it to some arguments might work ok. It's just the display of the simplified operators that looks goofy.

I noticed that in one earlier Post by you, there was also heavy manipulation of operators or procedures. I might be mistaken, and I don't know your motivating task, but it did make me wonder whether you really needed procedures. Are expressions inadequate for the programming aspects of your task?

You see (and if I am off the mark wholly here then I apologize), sometimes people new to Maple inadvertantly latch on to an approach not best for their goal. Sometimes this is repetition: what worked for an earlier job should work here too, and sometimes it's mimicry: it was advice given to others, etc. And so we sometimes see these worksheets with a ton of nested, lexically scoping operators, all defined in mixed order, when at the end of the day it's all just passed to `int` as some function call like P(foo,Q(bar..)..) which will evaluate up front to an expression anyway. Experts can have a rough time debugging such monsters, and the less experience user can flounder. It can sometimes be much more straightforward, when feasible, using expressions from the get go. Just a thought.

acer

@steweb You could name your assisting procedures, as I did in the example with `thatproc`. That seems to allow the results from `simplify` to also use that same name where appropriate in the output.

If you only ever need to apply the resulting procedure, then you might even be ok leaving it as is. By which I mean that since the escaped local `f` seems to evaluate to the right procedural body, then applying it to some arguments might work ok. It's just the display of the simplified operators that looks goofy.

I noticed that in one earlier Post by you, there was also heavy manipulation of operators or procedures. I might be mistaken, and I don't know your motivating task, but it did make me wonder whether you really needed procedures. Are expressions inadequate for the programming aspects of your task?

You see (and if I am off the mark wholly here then I apologize), sometimes people new to Maple inadvertantly latch on to an approach not best for their goal. Sometimes this is repetition: what worked for an earlier job should work here too, and sometimes it's mimicry: it was advice given to others, etc. And so we sometimes see these worksheets with a ton of nested, lexically scoping operators, all defined in mixed order, when at the end of the day it's all just passed to `int` as some function call like P(foo,Q(bar..)..) which will evaluate up front to an expression anyway. Experts can have a rough time debugging such monsters, and the less experience user can flounder. It can sometimes be much more straightforward, when feasible, using expressions from the get go. Just a thought.

acer

@kh2n In general, only when the imaginary component of the complex root is zero (or relatively very small in magnitude, say, with respect to the working precision) can that complex root be taken as a real root.

@kh2n In general, only when the imaginary component of the complex root is zero (or relatively very small in magnitude, say, with respect to the working precision) can that complex root be taken as a real root.