It appears that the "Alternate text" in the Properties of the images of 2D Math Example in the Online Help now contain the equivalent 1D Maple notation input. That makes it possible to copy Example code using the mouse pointer. That's great.

It seems to work even for lines that refer to an equation label.

The copying process may require a little effort depending on the browser (for me, it is right click on a 2D Math image, choose Properties from the popup menu, then select and copy the Alternate text field in the Element Properties popup window). But it can now be done.

Hopefully there will eventually be a mechanism to view the Examples with all input code displayed in (directly selectable) plaintext 1D Maple notation.

Thanks, Will.

acer

It goes wrong not because it is called as Sum(rec(...)) but rather because it is called with symbolic argument.

> forget(evalf):
> evalf(rec(4, 0.2, 3-u, 4, 1)):
> subs(u=0,%):
> evalf(%);
                                      22.

> forget(evalf):
> evalf(rec(4, 0.2, 3-u, 4, 1)):
> eval(%,u=0):
> evalf(%);
                                      22.

When called with symbolic 3rd argument, the lack of protection against invalid cancellation of "k"'s gets a wrong result. One can see this by stopat(`evalf/Sum1`) and observing the args coming in, I think.

The call rec(4, 0.2, 3-u, 4, 1) evaluates because evalf/Sum has normal evaluation rules as mentioned earlier.

note: mint and maplemint print the message,

    These names were used as global names, but were not declared:
      k

acer

If the names inside an expression get assigned, then why do you need to call `subs`? Why isn't usual assignment of the names, by itself, enough? What's your example, for which subsequent evaluation of the expression wouldn't serve?

> expr := a+b+c;
                               expr := a + b + c
 
> (a,b,c):=17,Z,Pi:
> expr;
                                  17 + Z + Pi

acer

As was pointed out earlier, it is still wrong because there is multiplication by,

((D@@2)(f))

((D@@2)(f)(x))

x := evalf(x -(f(x)/D(f)(x)) + ((((D@@2)(f)(x))*((f(x))^2))/(2*(D(f)(x))^3)));

> NEWTON_RAPH(x->x^3-5,1,10);
                                  1.709975947
 
> %^3;
                                  5.000000003

acer

As was pointed out earlier, it is still wrong because there is multiplication by,

((D@@2)(f))

((D@@2)(f)(x))

x := evalf(x -(f(x)/D(f)(x)) + ((((D@@2)(f)(x))*((f(x))^2))/(2*(D(f)(x))^3)));

> NEWTON_RAPH(x->x^3-5,1,10);
                                  1.709975947
 
> %^3;
                                  5.000000003

acer

A graph was not needed for this one,

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

acer

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