1) That should also be OK.

nohup nice -19 maple < infile > outfile &

2) Yes, all the output (stdout) goes to the output file, obeying Maple's usual statement terminator rules (semicolon vs colon).

I will sometimes issue such a command, then "watch" the intermediate results using `tail` in my Linux shell. Eg,

tail outfile

or,

tail -f outfile

I can use Ctl-C to break out of that last one. And I can log out (or be timed-out), then log back in and `tail` it again if not yet finished.

acer

1) That should also be OK.

nohup nice -19 maple < infile > outfile &

2) Yes, all the output (stdout) goes to the output file, obeying Maple's usual statement terminator rules (semicolon vs colon).

I will sometimes issue such a command, then "watch" the intermediate results using `tail` in my Linux shell. Eg,

tail outfile

or,

tail -f outfile

I can use Ctl-C to break out of that last one. And I can log out (or be timed-out), then log back in and `tail` it again if not yet finished.

acer

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

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