Before the Compiler came along, there was a earlier idea. I considered it, and I know at of at least three other guys who appeared to have thought of it independently. (I bet I wasn't the first, or the second...)

Basically it is this: Call CodeGeneration[C], and output to a file. Issue system/ssystem calls to compile the file and link the object into a .dll/.so dynamic library. Issue a define_external call to create a new proc which connects with the relevent function in that dynamic library. Automate all this jazz in a package or procedure.

Of course, this poor man's Compiler would not have any runtime argument checking or abilities to call back to Maple for functions it doesn't recognize. (That runtime of the current Compiler is, apparently, not thread-safe. So there's not much hope for an immediate workaround for any call_external procs generated by the true Compiler in its present state, I suspect.)

I'll try and find time to post an example.

Now, in order to use the result inside Threads one would have to make the define_external calls with the 'THREAD_SAFE' option.

acer

The input file has to be a plaintext file containing only valid Maple commands (or comments). This is the commandline interface (`maple` script) we're talking about, and it doesn't accept .mw or .mws worksheet files as input.

If you have a .mw file, you can produce the plaintext file containing all the commands by using the Standard GUI menubar's File -> Export As, and then selecting "Maple Input (.mpl)" in the "Files of Type" dropdown box at the bottom of the File Manager pop-up window.

acer

The input file has to be a plaintext file containing only valid Maple commands (or comments). This is the commandline interface (`maple` script) we're talking about, and it doesn't accept .mw or .mws worksheet files as input.

If you have a .mw file, you can produce the plaintext file containing all the commands by using the Standard GUI menubar's File -> Export As, and then selecting "Maple Input (.mpl)" in the "Files of Type" dropdown box at the bottom of the File Manager pop-up window.

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

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