I had no problem plotting your problematic example, in Maple 14.

Please upload your worksheet, so that we might figure out what's going wrong for you. (Use the green up-arrow in the menubar of the editing window, on this site.)

ps. It's almost never helpful to post mere images of 2D Math input to this site, even if the site works and we can see them.

acer

@PatrickT I suggest keeping the source of your involved procedures and packages in plaintext .mpl files, for a number of reasons:

• It's extremely rare to lose source due to a corrupt plaintext file. In contrast, we've seen reports of members with unloadable .mw worksheets here, about 4 times in the past month.
• Revision control! Organize your revisions, and add protection against clobbering. See RCS (its predecessor CVS) or the many modern alternatives.
• Code edit regions and Start-up code sections are fine and dandy for one-off stuff, but they don't provide the kind of simple intersession & interworksheet re-use that's provided by savelib/libname and library archives. Those code regions are fine, as quiet places to invoke your savelib'd packages & procedures, of course.

You mentioned that you use Linux (at home?). Why not use cygwin on that Windows system (at work?) and take some of the DOS-pain out of the scripting? Just a thought.

@PatrickT I suggest keeping the source of your involved procedures and packages in plaintext .mpl files, for a number of reasons:

• It's extremely rare to lose source due to a corrupt plaintext file. In contrast, we've seen reports of members with unloadable .mw worksheets here, about 4 times in the past month.
• Revision control! Organize your revisions, and add protection against clobbering. See RCS (its predecessor CVS) or the many modern alternatives.
• Code edit regions and Start-up code sections are fine and dandy for one-off stuff, but they don't provide the kind of simple intersession & interworksheet re-use that's provided by savelib/libname and library archives. Those code regions are fine, as quiet places to invoke your savelib'd packages & procedures, of course.

You mentioned that you use Linux (at home?). Why not use cygwin on that Windows system (at work?) and take some of the DOS-pain out of the scripting? Just a thought.

@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));

@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