And someone has incorporated those into Sage.  ;)

acer

For large numbers, better still might be to first split the number into an even number of equal-length "pieces" where each piece is an immediate integer. For example, one could compare the 1st and the 4th, and the 2nd and 3rd, if there were four pieces. That might reduce slowdown due to creation and memory management of big (gmp) integers.

Such slowdown for big integers makes `f` slow. Consider,

> f:=proc(n)
>     local a, k, len, m;
>     a:=n;
>     for len from length(a)-2 by -2 to 0 do
>         a:=iquo(a,10,'k');
>         a:=irem(a,10^len,'m');
>         if not k=m then return false fi
>         od;
>     true
> end:

> N := (10^10000+1)^2:
> f(N);
memory used=291.4MB, alloc=10.9MB, time=11.12
memory used=299.0MB, alloc=10.9MB, time=11.23
memory used=306.7MB, alloc=10.9MB, time=11.33
memory used=314.3MB, alloc=10.9MB, time=11.43
memory used=321.9MB, alloc=10.9MB, time=11.53
memory used=329.6MB, alloc=10.9MB, time=11.62
memory used=337.2MB, alloc=10.9MB, time=11.71
memory used=344.8MB, alloc=10.9MB, time=11.79
                                     true

> N := (10^100000+1)^2:
> f(N);
memory used=7.6MB, alloc=6.8MB, time=0.21
memory used=15.3MB, alloc=10.7MB, time=0.51
memory used=23.0MB, alloc=10.7MB, time=0.81
memory used=30.6MB, alloc=10.7MB, time=1.11
memory used=38.3MB, alloc=10.7MB, time=1.42
memory used=45.9MB, alloc=10.7MB, time=1.72
memory used=53.6MB, alloc=10.7MB, time=2.02
memory used=61.3MB, alloc=10.8MB, time=2.32
memory used=69.0MB, alloc=10.8MB, time=2.62
memory used=76.7MB, alloc=10.8MB, time=2.92
memory used=84.4MB, alloc=10.8MB, time=3.22
memory used=92.0MB, alloc=10.8MB, time=3.53
memory used=99.7MB, alloc=10.8MB, time=3.82
memory used=107.4MB, alloc=10.8MB, time=4.12
memory used=115.0MB, alloc=10.8MB, time=4.42
memory used=122.7MB, alloc=10.8MB, time=4.72
memory used=130.4MB, alloc=10.8MB, time=5.02
memory used=138.0MB, alloc=10.8MB, time=5.32
memory used=145.6MB, alloc=10.8MB, time=5.62
memory used=153.3MB, alloc=10.8MB, time=5.92
memory used=160.9MB, alloc=10.8MB, time=6.22
memory used=168.6MB, alloc=10.8MB, time=6.51
memory used=176.3MB, alloc=10.8MB, time=6.81
memory used=183.9MB, alloc=10.8MB, time=7.11
memory used=191.6MB, alloc=10.8MB, time=7.41
memory used=199.3MB, alloc=10.8MB, time=7.71
memory used=207.0MB, alloc=10.8MB, time=8.01
memory used=214.6MB, alloc=10.8MB, time=8.31
memory used=222.3MB, alloc=10.8MB, time=8.61
memory used=230.0MB, alloc=10.9MB, time=8.91
memory used=237.7MB, alloc=10.9MB, time=9.21
memory used=245.4MB, alloc=10.9MB, time=9.51
memory used=253.1MB, alloc=10.9MB, time=9.81
memory used=260.7MB, alloc=10.9MB, time=10.11
memory used=268.4MB, alloc=10.9MB, time=10.41
memory used=276.1MB, alloc=10.9MB, time=10.71
memory used=283.8MB, alloc=10.9MB, time=11.01
Interrupted

> g := proc(n)
>     local s;
>     s := ""||n;
>     evalb(s = StringTools:-Reverse(s));
> end:

> N := (10^100000+1)^2:
> g(N);
                                     true

> time( g(N) );
                                     0.055

> F(N); # Using `F` posted above.
                                     true
 
> time( F(N) );
                                     0.071

acer

For large numbers, better still might be to first split the number into an even number of equal-length "pieces" where each piece is an immediate integer. For example, one could compare the 1st and the 4th, and the 2nd and 3rd, if there were four pieces. That might reduce slowdown due to creation and memory management of big (gmp) integers.

Such slowdown for big integers makes `f` slow. Consider,

> f:=proc(n)
>     local a, k, len, m;
>     a:=n;
>     for len from length(a)-2 by -2 to 0 do
>         a:=iquo(a,10,'k');
>         a:=irem(a,10^len,'m');
>         if not k=m then return false fi
>         od;
>     true
> end:

> N := (10^10000+1)^2:
> f(N);
memory used=291.4MB, alloc=10.9MB, time=11.12
memory used=299.0MB, alloc=10.9MB, time=11.23
memory used=306.7MB, alloc=10.9MB, time=11.33
memory used=314.3MB, alloc=10.9MB, time=11.43
memory used=321.9MB, alloc=10.9MB, time=11.53
memory used=329.6MB, alloc=10.9MB, time=11.62
memory used=337.2MB, alloc=10.9MB, time=11.71
memory used=344.8MB, alloc=10.9MB, time=11.79
                                     true

> N := (10^100000+1)^2:
> f(N);
memory used=7.6MB, alloc=6.8MB, time=0.21
memory used=15.3MB, alloc=10.7MB, time=0.51
memory used=23.0MB, alloc=10.7MB, time=0.81
memory used=30.6MB, alloc=10.7MB, time=1.11
memory used=38.3MB, alloc=10.7MB, time=1.42
memory used=45.9MB, alloc=10.7MB, time=1.72
memory used=53.6MB, alloc=10.7MB, time=2.02
memory used=61.3MB, alloc=10.8MB, time=2.32
memory used=69.0MB, alloc=10.8MB, time=2.62
memory used=76.7MB, alloc=10.8MB, time=2.92
memory used=84.4MB, alloc=10.8MB, time=3.22
memory used=92.0MB, alloc=10.8MB, time=3.53
memory used=99.7MB, alloc=10.8MB, time=3.82
memory used=107.4MB, alloc=10.8MB, time=4.12
memory used=115.0MB, alloc=10.8MB, time=4.42
memory used=122.7MB, alloc=10.8MB, time=4.72
memory used=130.4MB, alloc=10.8MB, time=5.02
memory used=138.0MB, alloc=10.8MB, time=5.32
memory used=145.6MB, alloc=10.8MB, time=5.62
memory used=153.3MB, alloc=10.8MB, time=5.92
memory used=160.9MB, alloc=10.8MB, time=6.22
memory used=168.6MB, alloc=10.8MB, time=6.51
memory used=176.3MB, alloc=10.8MB, time=6.81
memory used=183.9MB, alloc=10.8MB, time=7.11
memory used=191.6MB, alloc=10.8MB, time=7.41
memory used=199.3MB, alloc=10.8MB, time=7.71
memory used=207.0MB, alloc=10.8MB, time=8.01
memory used=214.6MB, alloc=10.8MB, time=8.31
memory used=222.3MB, alloc=10.8MB, time=8.61
memory used=230.0MB, alloc=10.9MB, time=8.91
memory used=237.7MB, alloc=10.9MB, time=9.21
memory used=245.4MB, alloc=10.9MB, time=9.51
memory used=253.1MB, alloc=10.9MB, time=9.81
memory used=260.7MB, alloc=10.9MB, time=10.11
memory used=268.4MB, alloc=10.9MB, time=10.41
memory used=276.1MB, alloc=10.9MB, time=10.71
memory used=283.8MB, alloc=10.9MB, time=11.01
Interrupted

> g := proc(n)
>     local s;
>     s := ""||n;
>     evalb(s = StringTools:-Reverse(s));
> end:

> N := (10^100000+1)^2:
> g(N);
                                     true

> time( g(N) );
                                     0.055

> F(N); # Using `F` posted above.
                                     true
 
> time( F(N) );
                                     0.071

acer

Perhaps you could upload a short but representative example of your input to this site. (Use the green up-arrow in the bottom row of the editing toolbar, visible when one adds a comment.)

acer

Have a look at the help-pages for the Worksheet and XMLTools packages.

acer

The evalhf (fast, hardware floating-point) interpreter understands how to run procedures with calls to the `Array` constructor. It understands Matrix and rtable objects, but it doesn't understand  `Matrix` or `rtable` constructors calls.

> p := proc(x)
>   Array([[x^2, x], [1, x]]);
> end proc:

> evalhf( p(0.1) );
                [0.0100000000000000002    0.100000000000000006]
                [                                             ]
                [         1.              0.100000000000000006]
 
> rtable_options(%);
datatype = float[8], subtype = Array, storage = rectangular, order = Fortran_order

You can also use the eval command to escape back to regular Maple from within evalhf and so create Matrices (or other rtables, or other objects).

> p := proc(x)
>   Matrix([[x^2, x], [1, x]],datatype=float[8]);
> end proc:

> evalhf( p(0.1) );
Error, unable to evaluate expression to hardware floats: [[.1000000000e-1,
.100000000000000006], [1, .100000000000000006]]

> p := proc(x)
>   eval( Matrix([[x^2, x], [1, x]],datatype=float[8]) );
> end proc:

> evalhf( p(0.1) );
                [0.0100000000000000002    0.100000000000000006]
                [                                             ]
                [         1.              0.100000000000000006]
 
> rtable_options(%);
datatype = float[8], subtype = Matrix, storage = rectangular, order = Fortran_order

The performance penalty for the eval escape doesn't appear to be so bad.

acer

The evalhf (fast, hardware floating-point) interpreter understands how to run procedures with calls to the `Array` constructor. It understands Matrix and rtable objects, but it doesn't understand  `Matrix` or `rtable` constructors calls.

> p := proc(x)
>   Array([[x^2, x], [1, x]]);
> end proc:

> evalhf( p(0.1) );
                [0.0100000000000000002    0.100000000000000006]
                [                                             ]
                [         1.              0.100000000000000006]
 
> rtable_options(%);
datatype = float[8], subtype = Array, storage = rectangular, order = Fortran_order

You can also use the eval command to escape back to regular Maple from within evalhf and so create Matrices (or other rtables, or other objects).

> p := proc(x)
>   Matrix([[x^2, x], [1, x]],datatype=float[8]);
> end proc:

> evalhf( p(0.1) );
Error, unable to evaluate expression to hardware floats: [[.1000000000e-1,
.100000000000000006], [1, .100000000000000006]]

> p := proc(x)
>   eval( Matrix([[x^2, x], [1, x]],datatype=float[8]) );
> end proc:

> evalhf( p(0.1) );
                [0.0100000000000000002    0.100000000000000006]
                [                                             ]
                [         1.              0.100000000000000006]
 
> rtable_options(%);
datatype = float[8], subtype = Matrix, storage = rectangular, order = Fortran_order

The performance penalty for the eval escape doesn't appear to be so bad.

acer

I believe that you are right on track.

You might alternatively have the givens be entered in a TextArea. And the Equations appear in Math containers. There are all sorts of possible combinations as to layout. You could hide some of the flow control code, or make it visible (your choice). You could put some of the components inside worksheet tables (and keep the borders invisible, your choice).

acer

I believe that you are right on track.

You might alternatively have the givens be entered in a TextArea. And the Equations appear in Math containers. There are all sorts of possible combinations as to layout. You could hide some of the flow control code, or make it visible (your choice). You could put some of the components inside worksheet tables (and keep the borders invisible, your choice).

acer

It is usually not necessary to convert an expression to a procedure (or the other way around) in order to use the Optimization package to find a minimum numerically. That package accepts both expression form and procedure form for both objective and constraints of optimization problems.

Also, if you are simply trying to evaluate an expression at various values of the parameter then you might well not have to use unapply in order first to convert the expression to a procedure. The two-parameter form of the eval command can evaluate expressions at values of the variables. That should be efficient, while repeatedly using unapply for the same task would generally be less efficient.

There are some instances when unapply is unavoidably the easiest thing, but from what you've written so far I don't see that as the case. I could be wrong. Your comment below about a recursion limit while presumably using unapply within loop looks like suspicious usage. Seeing the full code might help.

acer

It is usually not necessary to convert an expression to a procedure (or the other way around) in order to use the Optimization package to find a minimum numerically. That package accepts both expression form and procedure form for both objective and constraints of optimization problems.

Also, if you are simply trying to evaluate an expression at various values of the parameter then you might well not have to use unapply in order first to convert the expression to a procedure. The two-parameter form of the eval command can evaluate expressions at values of the variables. That should be efficient, while repeatedly using unapply for the same task would generally be less efficient.

There are some instances when unapply is unavoidably the easiest thing, but from what you've written so far I don't see that as the case. I could be wrong. Your comment below about a recursion limit while presumably using unapply within loop looks like suspicious usage. Seeing the full code might help.

acer

Maybe there's a problem displaying the output. I haven't looked hard at it. This "3rd party" package seems to have problems. Maybe you could contact the author.

acer

Maybe there's a problem displaying the output. I haven't looked hard at it. This "3rd party" package seems to have problems. Maybe you could contact the author.

acer

Are you sure that you regenerated the package, and also that there is no original problematic version in some .mla archive in your libname? You may be picking up an original saved version.

ps. It now appears that with(plots) might do better than with(plots,display). Before the module definition. After the restart. Or rewrite the whole package with uses.

acer

Are you sure that you regenerated the package, and also that there is no original problematic version in some .mla archive in your libname? You may be picking up an original saved version.

ps. It now appears that with(plots) might do better than with(plots,display). Before the module definition. After the restart. Or rewrite the whole package with uses.

acer