More useful (in my experience. on Unix/Linux/OSX), is something like this,

nohup maple < input-file > output-file &

The amperand should give you back the prompt in the shell. The nohup should allow you to logout without the process terminating. (It lets it keep running...)

acer

The OP had already mentioned that he could use `fsolve` as a workaround. He had asked why he got various errors, or ran out of memory, when passing his proc (when that called `solve`) to `plot`.

Robert's explanation of `solve`'s treatment of exponent 1.333333333 sounds very plausible and likely. Given how seldom (relatively speaking) such an approach is likely to succeed with reasonable resources, perhaps it is a misguided treatment. I would say so, especially since a new Maple user might easily pump some such (rather innocuous) looking input to `solve`. I note that the runaway behaviour appears not to exist in Maple 9.5.1, but does in 10.02.

Why should the system behave so badly simply because one inputs this,

solve(3+y^(4./3));

This particular example might be better handled with the following. (I'm not saying that this is an approach that would cure all ills. But there are quite a few known problems and inconsistencies with how `solve`, `int`, `dsolve` handle floating-point input.)

> convert(1.333333333,rational,exact);
                                  1333333333
                                  ----------
                                  1000000000
 
> convert(1.333333333,rational);
                                      4/3
 
> identify(1.333333333);
                                      4/3

> evalf( solve( convert(-3.75+y^(1.333333333),rational), y) );
                                  2.694780840

ps. The (runaway) behaviour may differ between 32bit and 64bit Maple implementations, possibly due to different handling of very large exponents during the computation. In 13.01, I have seen it "go away" on 64bit Linux while quickly returning "solutions may be lost" on 32bit Linux. I will submit an SCR.

acer

> ee := Int((2.50*10^6+27.*f^2)*f^(57/50)*(21.
>   +221.*M^(2/3)*f^(2/3))/(2.27*10^18+2.45*10^13*f^2
>   -1.16*10^14*f^(107/50)+5.43*10^10*f^(207/50)
>   -1.20*10^6*f^(307/50)+13.*f^(407/50)), f = 10. .. 2670.):

> evalf(IntegrationTools:-Expand(ee));
                                 -6                     (2/3)
                  0.2305099822 10   + 0.00005166625109 M

> # Since you changed the range to floats, value() also works
> value(IntegrationTools:-Expand(ee));
                                 -6                     (2/3)
                  0.2305099822 10   + 0.00005166625109 M

acer

> ee := Int((2.50*10^6+27.*f^2)*f^(57/50)*(21.
>   +221.*M^(2/3)*f^(2/3))/(2.27*10^18+2.45*10^13*f^2
>   -1.16*10^14*f^(107/50)+5.43*10^10*f^(207/50)
>   -1.20*10^6*f^(307/50)+13.*f^(407/50)), f = 10. .. 2670.):

> evalf(IntegrationTools:-Expand(ee));
                                 -6                     (2/3)
                  0.2305099822 10   + 0.00005166625109 M

> # Since you changed the range to floats, value() also works
> value(IntegrationTools:-Expand(ee));
                                 -6                     (2/3)
                  0.2305099822 10   + 0.00005166625109 M

acer

It can be edited to work in such cases (although sometimes it's tricky).

> gdiff:=(f,x)->thaw(value(subs([x=freeze(x),x^(-1)=1/freeze(x)],Diff(f,x)))):

> gdiff( 5*x^2+5/x^2+y, x^2 );
                                        5
                                   5 - ----
                                         4
                                        x

I'll leave differentiating 5/x^4+y w.r.t x^2 to your imagination. It wouldn't be very neat if using that mentioned technique of converting to atomic identifiers with the mouse.

acer

It can be edited to work in such cases (although sometimes it's tricky).

> gdiff:=(f,x)->thaw(value(subs([x=freeze(x),x^(-1)=1/freeze(x)],Diff(f,x)))):

> gdiff( 5*x^2+5/x^2+y, x^2 );
                                        5
                                   5 - ----
                                         4
                                        x

I'll leave differentiating 5/x^4+y w.r.t x^2 to your imagination. It wouldn't be very neat if using that mentioned technique of converting to atomic identifiers with the mouse.

acer

I've enjoyed the posts too.

I suspect that multithreading could become one of the Great Ways to improve Maple performance, both for "users' code" and for Maple's own Library.

Even with speedup that is linear (as a function of cores) it is appropriate to start now on what is clearly very difficult underpinning development, even if the average number of cores does not reach the hundreds for some years.

nb. Other Great Ways include use of the Compiler (another technology that deserves enhancement), producing less garbage, and reducing computational complexity.

acer

Underscores also have a problem at present. ?spec_eval_rules does not get here.

acer

It likely would not come up, but in general one would need to be more careful if p could be a hardware scalar float.

> f := proc() option hfloat;
> local p;
>   p:=evalf((1+sqrt(5))/2-1,20);
>   p := 2.0 * p;
>   print(p);
>   op(1,p), # oops
>   cat(op(StringTools:-Split(convert(p,string),".")));
> end proc:
>
> f();
                               1.23606797749979

                     123606797749978981, "123606797749979"

> op(1, HFloat(1.23606797749979) );
                              123606797749979003

acer

It likely would not come up, but in general one would need to be more careful if p could be a hardware scalar float.

> f := proc() option hfloat;
> local p;
>   p:=evalf((1+sqrt(5))/2-1,20);
>   p := 2.0 * p;
>   print(p);
>   op(1,p), # oops
>   cat(op(StringTools:-Split(convert(p,string),".")));
> end proc:
>
> f();
                               1.23606797749979

                     123606797749978981, "123606797749979"

> op(1, HFloat(1.23606797749979) );
                              123606797749979003

acer

Rather than call a Maple operator on every character (using Remove), it might be better to simply Split the string at the character to be removed, and then concatenate afterwards.

(**) cat(op(StringTools:-Split("1.6180339887498948482",".")));
                            "16180339887498948482"

acer

Rather than call a Maple operator on every character (using Remove), it might be better to simply Split the string at the character to be removed, and then concatenate afterwards.

(**) cat(op(StringTools:-Split("1.6180339887498948482",".")));
                            "16180339887498948482"

acer

I think that it would be useful to delineate the current status and restrictions of Theads in Maple.

For example,

• What makes a Maple code routine Thread-unsafe? (There are lots of ways to cause global effects, so a clear list would help. This earlier post doesn't make it clear, sorry.)
• What low-level Library routines are Thread-unsafe (eg. limit, is, signum, etc). These routines might not be usable inside one's own Threaded code.
• What blocks all Threads? (eg. garbage collection? object uniquification in the kernel? Other?) These would affect performance, and create bottlenecks possibly unavoidable at present.
• What actions can occur in only one Thread at a time? (eg. external calling to Maple's own auxiliary external compiled libraries? external calling to a Compiler:-Compile'd routine?) I mean what actions block other Threads from doing the same thing, not what is Thread-safe.
• Can two Threads write to two different embedded components, with interleaved timing? Is Typesetting Thread-safe, for that?
• The debugger status was mentioned in another post.

The question of Thread-safety of the Maple Library is very tricky. There may be a characterization of what is currently, typically Thread-safe, for example along the lines of a symbolic vs numeric distinction. People are going to want to write Threaded code which is not simply plain arithmetic and use of kernel built-ins. But a lot of symbolic Library code is not Thread-safe, and a lot of numeric Library code might call externally (and block duplicated external lib access). Characterizing what sort of code be successfully Threaded would be very useful. Revising such a description with each released improvement would also help.

acer

I was thinking of trying that, but haven't found the spare time yet.

I also haven't read through that linked .pdf yet. But (after helping out the Optimization call to handle the proc a little) I saw that the supplied data was generating some complex (nonreal) values (in the `ln` call`). That made Optimization balk. So I haven't figured out whether the implemenatation of the algorithm is faulty, or how to handle such occasional complex returns. I notice that the proc does produce a plot. It's inconvenient to fiddle with it while it is so slow -- another reason I wanted to optimize/Compile the implementation.

It came up in another thread a while back that Compiling/evalhf'ing a proc that used Statistics (Mean, Variance, or samples) didn't work. A workaround was to replace such Statistics calls with explicit (finite) formulae or even with `add` calls.

acer

I was thinking of trying that, but haven't found the spare time yet.

I also haven't read through that linked .pdf yet. But (after helping out the Optimization call to handle the proc a little) I saw that the supplied data was generating some complex (nonreal) values (in the `ln` call`). That made Optimization balk. So I haven't figured out whether the implemenatation of the algorithm is faulty, or how to handle such occasional complex returns. I notice that the proc does produce a plot. It's inconvenient to fiddle with it while it is so slow -- another reason I wanted to optimize/Compile the implementation.

It came up in another thread a while back that Compiling/evalhf'ing a proc that used Statistics (Mean, Variance, or samples) didn't work. A workaround was to replace such Statistics calls with explicit (finite) formulae or even with `add` calls.

acer