@Østerbro Thanks, I'll need to make that combination easier/automatic, provided I'm understanding properly.

Is this the kind of effect you want (forcibly converting the complex valued unit thing to angle format)?

Newmodif.mw

@rdpdo Why not upload a worksheet that demonstrates your ongoing difficulty, in a followup Comment to this thread, so that we can see what is actually going on?

I believe that the anonymous procedure (inside procedure `Iterate`) is obtaining HFoats when it extracts values of entries from the hfarray.

I see the mentioned effect in trace, with the large integer instead of an HFloat, when using 64bit Maple 16.02a on Windows 7 or Linux if I run it in the Standard GUI. For example, transcribing from the Linux GUI by copy and paste, with prettyprint=1,

restart;
f:= x-> exp(x^2*(3-x)):
trace(f):
f( HFloat(1.0) );
{--> enter f, args = 4607182418800017408
                              7.38905609893065

<-- exit f (now at top level) = 4620005356000828846}
                              7.38905609893065

But if I run it in the CLI using that version for Linux then the trace printout is as expected.

The computed value seems to be as expected, however, so it seems as if the trace effect might be just an artefect of printing.

I have not been able to get the nonreal results that Carl describes.

@Carl Love I believe that it's something like that (in the limit as the total number of iterations gets high, so that the attracting values dominate, but there may some additonal scaling). That coloring routine ought to be documented. Below this uses the default number of iterations, which is 10000.

restart;
with(IterativeMaps): with(ImageTools): with(plots):
B:=Bifurcation( [x], [exp(x^2*(r-x))], [1.0], 1.4, 1.7,
                xmin=0.2, xmax=2.1, width=300,height=300 ):
surfdata(5000-(B[..,..,1]),2.1..0.2,1.4..1.7,
         style=surface,orientation=[-165,-80,-180],shading=zhue,
         view=0..5000-5);

@Carl Love Here are some colored images for those, made with Maple 2016.0 on 64bit Windows 7.

restart;
with(IterativeMaps): with(ImageTools):

BL:=Bifurcation( [x], [exp(x^2*(r-x))], [1.0], -3, 3, xmin=0.0, xmax=7.5 ):
ColouringProcedures:-HueToRGB( BL ):
Embed( BL );

B:=Bifurcation( [x], [exp(x^2*(r-x))], [1.0], 1.4, 1.7, xmin=0.2, xmax=2.1 ):
ColouringProcedures:-HueToRGB( B ):
Embed( B );

@Preben Alsholm I think that it is a (regression) bug. The whole expression does not match the given type(s), and so the transformer should not be applied to it.

Compare also with indets.

These three operators might not be especially interesting, but,

evalb( 4::integer );
                              true

evalb( `::`(4,integer) );  # see `type`
                              true

3 ** 4;
                               81

`**`(3,4);  # see `^`
                               81

a || b;
                               ab

`||`(a,b); # may evaluate like `cat`, but expects exactly 2 arguments
                               ab

While discussing prefix operators `if` might also deserve mention since, while it's a keyword rather than an infix operator, it's pretty useful. See the ?if help page. (BTW, does anyone write `ifelse` in code, in practice...?)

@Mac Dude Here's a screenshot. An important point is not that a nicer rendering can come from implicitplot or some other plotting command but rather that increasing the numpoints in the very common `plot` command ought not degrade quality so easily.

This is 64bit Maple 2016 on Windows 7 Pro.

@Axel Vogt Yes, you could convert from RealRange to relation, solve, and then (optionally) convert back.

This should probably be more robust about failing cases, multiple solutions, etc. I didn't write this carefully. It's just to convey the idea.

U:=proc(A::RealRange,B::RealRange,x::numeric) local r,t;
  r:=solve({convert(t::A,:-relation),convert(t::map(y->x+y,B),:-relation)},{t});
  `if`(r=NULL,NULL,op(2,convert(And(op(r)),RealRange)));
end proc:

U( RealRange(0, 2), RealRange(-3, -1), 1.001 );
                                               RealRange(0., 0.001000000000)

U( RealRange(0, 2), RealRange(-3, -1), 0.999 );

This can also be easily turned into something that accepts multiple RealRange arguments (one of which could be shifted by that `x` argument instead, etc). The only real point is that `solve` can do it.

@nrebman1 Please post your worksheets here if you have ongoing problems with your (essentially same) example.

@Østerbro If you use the "Contect" link on my member page here then I'll get an email and be able to respond to you via email.

I cannot use the Contect mechanism from this site to contact you because I'm unable to view your member page here (possibly due to special characters in your member handle for this site.)

@John Fredsted I believe that deletion as spam is yet another ability which is key on reputation. (...a higher cutoff, I suspect, since if the spammer's reputation/activity is low enough then deletion as spam may disable the spamming account.)

@rostam Your response to me, about using even 10^7 points, indicates that you've misunderstood me.

What I mean is that there may be a cutoff in the number of data points below which antialiasing is enabled in the Java renderer. Not above. Compare,

plot(10*sqrt(3)/sqrt(120*Pi^2+19*x), x=0..10, view=0..1,
     adaptive=false, numpoints=2000, thickness=0);

plot(10*sqrt(3)/sqrt(120*Pi^2+19*x), x=0..10, view=0..1,
     adaptive=false, numpoints=200, thickness=0);

So the key thing may be that, at present, better quality comes from not using a very high number of points for such curves.

I have a suspicion that potentially "expensive" smoothing techniques for line smoothing in java/jogl/jwhatever may not being done when there are too many points. If that surmise is correct then the global cutoff has clearly been set too low, or is being misapplied. (It's possible that some distinction is made to handle simultaneous rendering of multiple curves, and that in the interest of not exceeding a reasonable global total an over-strict cutoff is applied to single curves. I'm guessing about how it could be mis-coded.) OTOH, if this is any kind of java/jogl renderer limitation (which I doubt) the GUI could still resample downwards before passing to the renderer. Another possibility is that antialiasing is not being done following downsamplling.

The behavior is wrong, and the lower point-number case demonstrates that better rendering is possible: that's the important thing. I thought that most of the 2D plot rendering smoothness issues were resolved a few releases ago. It's a shame. 2D plot rendering of single curves should use the highest quality that the renderer provides, with speed being no problem, up to a really high point-number (above which the GUI could downwards resample very quickly). And it should be less easy for the user to try something reasonable (like ramping the number of points way up) and end up with low quality rendering.

Like several other editing aspects, being able to edit other's posts is keyed on the level of the member's reputation, I believe.

acer

Do you see an abrupt change in quality when numpoints becomes smaller or greater than 1999 (or some value around that)?

acer