Is this your code?

acer

@Kitonum That is interesting. Does the Compiler work at all for you?

On my Windows 7 Pro machine it works using 32bit Maple 2016.1.

`Maple 2016.1, IBM INTEL NT, Apr 22 2016, Build ID 1133417`

@ghoust Note that your difficulty arose from mistakenly using D[2](g) , which means  the (first) derivative with respect to the second independent variable, instead of (D@@2)(g) which means the second derivative of g (implied to have just a single independent variable).

A valid alternative here for (D@@2)(g)(0) is D[1,1](g)(0) , where both of those involve differentiating twice with respect to the single variable.  But your D[2](g)(0) is not appropriate as it is the attempt to express the (first) derivative of g with respect to the (nonexistent) second variable, then evaluated using just one parameter's value.

@vv Yes, thank you. I had already read your previous comment about it, and knew its import.

For this example it is possible to obtain symbolic representation of the results `cp` and `p`.

These results may contain RoofOfs with float-descriptors, and these are (supposed to be) useful in a certain symbolic sense. For example one may evaluate them individualy or together, after the fact, with arbitrary working precision.

I used the commandline interface, hence the %1 label in the output below.

My use of type,realcons could very likely be improved upon and made more robust (through use of `is`, or simplify@fnormal, or what have you).

restart;

cp := extrema(x^3-x-exp(x), {}, x, 'p'):

(min,max)(select(type, [allvalues(cp)], set(realcons)));

                       3
RootOf(%1, 1.200030135)  - RootOf(%1, 1.200030135) - exp(RootOf(%1, 1.200030135)),

                           3
    RootOf(%1, 3.678906196)  - RootOf(%1, 3.678906196) - exp(RootOf(%1, 3.678906196))

                     2
%1 := -exp(_Z) + 3 _Z  - 1

evalf[30](%);

           -2.79211692449830566602615239626, 6.5096484210367822906797444494

`union`(select(type, [allvalues(p)], set(set(name=realcons)))[]);

                            2                                                  2
{{x = RootOf(-exp(_Z) + 3 _Z  - 1, -0.7056419073)}, {x = RootOf(-exp(_Z) + 3 _Z  - 1, 1.200030135)},

                               2
    {x = RootOf(-exp(_Z) + 3 _Z  - 1, 3.678906196)}}

evalf[30](%);                                                    

  {{x = -0.705641907324767081365196618987}, {x = 1.20003013532041638015477811010},
   {x = 3.67890619604451930671011391783}}

The user of the extrema command should not have to go to all this trouble. The same should apply if the results were (ordinally) indexed RootOfs from, say, a 6th degree univariate polynomial.

@cskoog One of the things Marvin refers to is the ongoing support for Maple in Windows 7.

A central aspect to this line of questioning is whether Maple 2017 will support Windows 7.

Updating the roadmap with details about Windows 7 and Maple 2017 would be useful. The sooner the better.

@Ø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.