@Christopher2222 No, not unless you purchase the more expensive licensing (think of Maple's EMP, say). There were a few posts on the wolfram community site when this new productization model appeared with 10.x.x, in which a few people grumbled. For example some people complained that they were not properly informed in advance of the new licensing model, and in consequence paid more than they ought to. I see it as just another way in which WRI tries to nickel&dime its customers.

There are a few emergency-style rushed updates of the form 10.x.N where N>0, but they are few and don't seem to contain a great many fixes.

There is another problem with this new productization model of Mma, apart from the licensing fees. As far as I can see the 10.x.0 updates often have several serious regression bugs in them. So it is much harder, if not impossible, to get reasonable bug fixes for some parts of the product while at the same time avoiding new breakages that accompany the updates. This is a seriously scary pricing model, for a product that may always require regular and ongoing license updating (eg, annual cost).

The burden must be on you to first say how you will accept the distribution of the points. You have used the term "random point" and it is only sensible if you cast that in a mathematically precise way.

acer

@Carl Love For the OP to ask how to use method=lsode in the same message that asks what numerical algorithm it uses demonstrates that the OP should not be using this method. Better would be to try default nonstiff/stiff methods, or specify none until such time as there is a justification to change methods. With no rationale to specify lsode it makes little to no sense for the OP to be getting bogged down in its subtleties. (Your first reply had some of this gist, but I think the OP really needs to think harder about it, or to state the motivation.)

Are you sure that the whole "a+b = 4+5 = 9" business is not more you're own (possibly mistaken) interpretation of what might be a simpler demand? That interpretation of the demand to "display the results between calculations" is extremely difficult to get exactly right in all situations. I consider it quite unlikely that most instructors would even realize the full depth of the difficulties involved there.

I mean, perhaps the instructor would be satisfied if you simply terminated all assignments with semicolons, and made sure always to assign intermediary computations to (temp) names, prior to passing them into further commands?

acer

@Carl Love That won't work in a variety of different situations, not least of which being the case of a call to a command that expects a numeric argument rather than a uneval-quoted name.

For example,

Display:= proc(e::algebraic)
     local r:= eval(e);
     print(nprintf("%a = %Q", e, subsindets(e, name, n-> nprintf("%Q", eval(n)))) = r);
     r;
end proc:

n := 4:
Display( series(sin(x), x, 'n') ):
Error, invalid input: series expects its 3rd argument, n, to be of type {infinity, nonnegint}, but received n

However the above example would work if the entire argument passed to `Display` were uneval-quoted.

n := 4:
Display( 'series(sin(x), x, n)' ):

                                                 1  3    / 5\
   series(sin(x),x,n) = series(sin(x),x,4) = x - - x  + O\x /
                                                 6           

With that in mind, it seems simpler to define that `e` parameter of `Display` as being of type uneval. That way the extra quoting is left out of it. Eg,

restart;

Display:= proc(e::uneval)
     local pre := subsindets(e,uneval(name),eval,1);
     local r := eval(pre);
     if indets(pre,And(name,satisfies(u->u<>eval(u))))={} then
       print(r);
     else
       print(nprintf("%a = %Q", pre,
                     subsindets(pre, name, n-> nprintf("%Q", eval(n))))
             = r);
     end if;
     r;
end proc:

n := 4:
Display( series(sin(x), x, n) ):

                                                 1  3    / 5\
   series(sin(x),x,n) = series(sin(x),x,4) = x - - x  + O\x /
                                                 6           

(a,b) := (3,4):
c := Display( a + b ):

                         a+b = 3+4 = 7

Display( sin(3.4) * cos(3.4) ):

                          0.2470566755

Display( cos(3.4*n) ):

             cos(3.4*n) = cos(3.4*4) = 0.5117039925

f := tan(x):
s := t: t := u: u := v: v := w: w := x:
Display( series(f, s, n) ):

                                              1  3    / 5\
     series(f,s,n) = series(tan(x),x,4) = x + - x  + O\x /
                                              3   
        
count := 0:
g := proc(z) global count; count:=count+1; cos(z); end proc:
Display( g(3.4*n) ):

               g(3.4*n) = g(3.4*4) = 0.5117039925

count; # should return 1

                               1

Of course it's almost impossible to make this kind of thing perfect. And automatic simplification gets in the way too.

@jtorre Yes, because sin(i) returns sin(i) for unassigned `i`. Please read all the answers carefully.

Your original example was effectively computing this:

nops(L(i));
                                          1

sum(%, i=1..2 );
                                          2

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.