A graph was not needed for this one,

Student:-Calculus1:-Roots(df,x=-1..3,numeric);

acer

I don't quite understand what your meaning.

On second glance, it appears as if you might have 2D Math input there. (That lprint and prettyprint stuff was all about what one can do with prior results and output, rather than input.) Now, that should still be handled properly and converted to lineprinted 1D input if you Export as "Maple Input (.mpl)". Make sure to choose that export file type, not any of the others.

Also, are you in a Document or a Worksheet? Is your default 2D Math or 1D Maple notation input? Note that you can easily change both of those, via the Tools -> Options choices on the top menubar. I mean, why enter equations as 2D if you just end up wanting 1D in the end...?

Sorry, if I still haven't understood you.

acer

I don't quite understand what your meaning.

On second glance, it appears as if you might have 2D Math input there. (That lprint and prettyprint stuff was all about what one can do with prior results and output, rather than input.) Now, that should still be handled properly and converted to lineprinted 1D input if you Export as "Maple Input (.mpl)". Make sure to choose that export file type, not any of the others.

Also, are you in a Document or a Worksheet? Is your default 2D Math or 1D Maple notation input? Note that you can easily change both of those, via the Tools -> Options choices on the top menubar. I mean, why enter equations as 2D if you just end up wanting 1D in the end...?

Sorry, if I still haven't understood you.

acer

With the MSVC++ compiler, I believe that creating a shared .dll from a single .c file could be done something like this,

cl foo.c -Gz -LD -link -export:foo

You might throw in -out:foo.dll as another option there, to force the .dll file name.

Maybe see here for more detail. I don't know what the equivalent would be using the Watcom compiler that comes bumdled with Maple for 32bit Windows. (I bet Axel knows...) There is also an example worksheet ( see ?examples,ExternalCalling ) with more details.

acer

> restart:

> (1.3*10^(-5)*Enn+0.4*10^(-2))/z;
                     0.00001300000000 Enn + 0.004000000000
                     -------------------------------------
                                       z

> lprint(%);
(.1300000000e-4*Enn+.4000000000e-2)/z

> interface(prettyprint);
                                       1

> interface(prettyprint=0):

> (1.3*10^(-5)*Enn+0.4*10^(-2))/z;
(.1300000000e-4*Enn+.4000000000e-2)/z

See the ?interface help-page.

acer

> restart:

> (1.3*10^(-5)*Enn+0.4*10^(-2))/z;
                     0.00001300000000 Enn + 0.004000000000
                     -------------------------------------
                                       z

> lprint(%);
(.1300000000e-4*Enn+.4000000000e-2)/z

> interface(prettyprint);
                                       1

> interface(prettyprint=0):

> (1.3*10^(-5)*Enn+0.4*10^(-2))/z;
(.1300000000e-4*Enn+.4000000000e-2)/z

See the ?interface help-page.

acer

An example of a poor man's Compiler follows. This is on Linux, but hopefully you will be familiar enough with your Windows compiler to adjust it accordingly.

Of course, one idea is to automate the process inside a procedure or package, so that it is easily re-usable for other procedures. (There may be some trickiness to be handled with rtable dimensions, since CodeGeneration[C] didn't seem to like a proc having a Matrix parameter defined with symbolic size. You can see how I got around that below, but only as a one-off experience.)

You can see where I am calling define_external below. If you were confidant that the routine were thread-safe then you could add 'THREAD_SAFE' as an option. That should allow Maple to let multiple Threads access the compiled routine concurrently (but I haven't tested that distinction with timing benchmarks). Since the compiled C function doesn't call back into Maple, and effects no global change of state, I'd believe that it is thread-safe.

ps. Rather than subsequently calling Matrix(...,(i,j)->foo(...),...) I would consider passing M as a new empty Matrix argument to foo, removing the arguments i and j, and populating all of M inside foo. That would avoid many function calls, which do cost something even when foo is a call_external.

    |\^/|     Maple 13 (X86 64 LINUX)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
>
> M,N := 15000,3000:
>
> foo:=proc(
>   i::integer,j::integer,
>   X::Matrix(_M,_N,order=C_order,datatype=float[8]),
>   sig::float,ncols::integer)
> local k::integer, temp::float;
>   # The add result incorrectly gets cast to an int.
>   # I've Trackered that.
>   #temp:=add((X[i,k]-X[j,j])^2,k=1..ncols);
>   temp:=0.0;
>   for k from 1 to ncols do
>     temp:=temp+(X[i,k]-X[j,j])^2;
>   end do;
>   temp:=exp(-temp/2)/sig;
> return temp;
> end proc:
>
> foo := subs({_M=M,_N=N},eval(foo));
foo := proc(i::integer, j::integer,
X::Matrix(15000, 3000, order = C_order, datatype = float[8]), sig::float,
ncols::integer)
local k::integer, temp::float;
    temp := 0.;
    for k to ncols do temp := temp + (X[i, k] - X[j, j])^2 end do;
    temp := exp(-1/2*temp)/sig;
    return temp
end proc
 
>
> try FileTools:-Remove("foo.c"): catch: end try:
> try FileTools:-Remove("foo.o"): catch: end try:
> try FileTools:-Remove("libfoo.so"): catch: end try:
> CodeGeneration[C](foo,'output'="foo.c"):
>
> ssystem("gcc -fPIC -c -o foo.o foo.c");
                                    [0, ""]
 
> ssystem("gcc -shared -o libfoo.so foo.o");
                                    [0, ""]
 
>
> compiled_foo := define_external('foo',
>      _i::integer[4],
>      _j::integer[4],
>      _X::ARRAY(order=C_order,datatype=float[8]),
>      _sig::float[8],
>      _ncols::integer[4],
>      RETURN::float[8],
>      LIB="libfoo.so"):
>
> ii,jj := 3,4:
> XX := LinearAlgebra:-RandomMatrix(M,N,'generator'=-0.1..0.1,
>          'outputoptions'=['order'='C_order','datatype'=float[8]]):
memory used=346.2MB, alloc=346.3MB, time=2.12
> ssig,nncols := 1.3,N:
>
> st:=time():
> foo(ii,jj,XX,ssig,nncols);
                                              -6
                               0.5769499335 10
 
> time()-st;
                                     0.042
 
>
> st:=time():
> evalhf(foo(ii,jj,XX,ssig,nncols));
                                                  -6
                           0.576949922471079567 10
 
> time()-st;
                                     0.002
 
>
> st:=time():
> compiled_foo(ii,jj,XX,ssig,nncols);
                                                  -6
                           0.576949922471079567 10
 
> time()-st;
                                     0.001
 
>
> quit
memory used=348.9MB, alloc=347.6MB, time=2.16

acer

That's interesting. Maybe I'm having a senior moment but for some reason I can't think offhand of a way to pull an unknown constant symbolic factor out of a piecewise.

However, if you know in advance what that symbolic factor is, then there are ways to force it. (Let's recall, that the purpose of pulling out all symbolic factors is so that evalf will induce fast numeric quadrature on the remaining Int calls.)

In your last post above, assign that returned mess to the variable ee.

> evalf(IntegrationTools:-Expand(
           subsindets(ee,specfunc(anything,piecewise),
                      z->Enn*PiecewiseTools:-Simplify(z/Enn))));
                                                                         46
                                                          0.1112096938 10   Enn

acer

That's interesting. Maybe I'm having a senior moment but for some reason I can't think offhand of a way to pull an unknown constant symbolic factor out of a piecewise.

However, if you know in advance what that symbolic factor is, then there are ways to force it. (Let's recall, that the purpose of pulling out all symbolic factors is so that evalf will induce fast numeric quadrature on the remaining Int calls.)

In your last post above, assign that returned mess to the variable ee.

> evalf(IntegrationTools:-Expand(
           subsindets(ee,specfunc(anything,piecewise),
                      z->Enn*PiecewiseTools:-Simplify(z/Enn))));
                                                                         46
                                                          0.1112096938 10   Enn

acer

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