Ok, so the inner addition can benefit from being done inside a procedure with `option remember`.

And I was mistaken about a recursive outer addition (with option remember) since the `x` value changes each time.

And there's another, relatively smaller, benefit from using `trunc` instead of `floor`.

restart:

S := x->1+add(trunc((x/(add(trunc(cos(Pi*(factorial(n-1)+1)/n)^2),
              n = 1 .. r)))^(1/x)), r = 1 .. 2^x):

CodeTools:-Usage( seq(S(x), x = 1 .. 7) );
memory used=1.10GiB, alloc change=63.99MiB, cpu time=15.13s, real time=15.13s
                     2, 3, 5, 7, 11, 13, 17

restart:

K := proc(r)
     option remember;
       add(trunc(cos(Pi*(factorial(n-1)+1)/n)^2),n=1..r);
     end proc:

S := x->1+add(trunc((x/K(r))^(1/x)),r=1..2^x):

CodeTools:-Usage( seq(S(x),x=1..7) );
memory used=0.87GiB, alloc change=63.99MiB, cpu time=12.08s, real time=12.08s
                     2, 3, 5, 7, 11, 13, 17

Of course, it still becomes slow quickly.

acer

@serena88 Sure, although my spare time is limited this month.

You could post it here, in this thread

..or you could email it to me (I'll contact you, so you have my address)

..or you could upload it to the Maple Cloud (see my profile page, for a cloud group where it would be private)

@serena88 Sure, although my spare time is limited this month.

You could post it here, in this thread

..or you could email it to me (I'll contact you, so you have my address)

..or you could upload it to the Maple Cloud (see my profile page, for a cloud group where it would be private)

The Matrix() constructor can build that full Matrix directly, as it is pretty smart about flattening the various blocks that you've defined.

O31 := Matrix(3,1):

Matrix([[     Id,       Y,    -X,  a*X ],
        [    b*Y,       Z,   O31,  O31 ],
        [   X^%T,  O31^%T,     0,    0 ],
        [ O31^%T,  O31^%T,     0,    q ]]);

                        [ 1   0   0  4  9  9  -4  8]
                        [                          ]
                        [ 0   1   0  7  6  2  -4  8]
                        [                          ]
                        [ 0   0   1  4  9  7  -3  6]
                        [                          ]
                        [12  27  27  2  3  9   0  0]
                        [                          ]
                        [21  18   6  5  5  4   0  0]
                        [                          ]
                        [12  27  21  3  9  7   0  0]
                        [                          ]
                        [ 4   4   3  0  0  0   0  0]
                        [                          ]
                        [ 0   0   0  0  0  0   0  5]

But I fear that was the questioner really wants is not so much a fully explicit entry-by-entry representation of the inverse of this explicit Matrix. I suspect that what he may be asking for is a block-Matrix representation of the inverse of his block-Matrix. And Maple does not have tools in LinearAlgebra to do that. One of the practical difficulties with attempting it (using the current toolset) is that at some point some compound products of the block's names (scalar names) will be computed wrongly, as if the blocks (Matrix blocks) commuted under Matrix-multiplication.

For example, consider the determinant which would get computed if all these block names had not yet been assigned,

restart:
with(LinearAlgebra):

M := Matrix([[     Id,       Y,    -X,  a*X ],
             [    b*Y,       Z,   O31,  O31 ],
             [   X^%T,  O31^%T,     0,    0 ],
             [ O31^%T,  O31^%T,     0,    q ]]):

Determinant(M);

       2         2                      2  2        3      3                
 -q O31  Id + q X  Z - q O31 b Y X - O31  X  + X O31  + O31  a X + q X Y O31

         2  2  
    - O31  X  a

That q*X^2*Z term, for example, looks like it has violated noncommativity of the blocks under Matrix-multiplication. Many years ago, I might have tried to work aorund this, by using non-commuting `&*` as possible overload. But nowaways I'd prefer to submit yet another SCR for such this block Matrix support (a weaker kind of abstract linear algbera).

acer

The Matrix() constructor can build that full Matrix directly, as it is pretty smart about flattening the various blocks that you've defined.

O31 := Matrix(3,1):

Matrix([[     Id,       Y,    -X,  a*X ],
        [    b*Y,       Z,   O31,  O31 ],
        [   X^%T,  O31^%T,     0,    0 ],
        [ O31^%T,  O31^%T,     0,    q ]]);

                        [ 1   0   0  4  9  9  -4  8]
                        [                          ]
                        [ 0   1   0  7  6  2  -4  8]
                        [                          ]
                        [ 0   0   1  4  9  7  -3  6]
                        [                          ]
                        [12  27  27  2  3  9   0  0]
                        [                          ]
                        [21  18   6  5  5  4   0  0]
                        [                          ]
                        [12  27  21  3  9  7   0  0]
                        [                          ]
                        [ 4   4   3  0  0  0   0  0]
                        [                          ]
                        [ 0   0   0  0  0  0   0  5]

But I fear that was the questioner really wants is not so much a fully explicit entry-by-entry representation of the inverse of this explicit Matrix. I suspect that what he may be asking for is a block-Matrix representation of the inverse of his block-Matrix. And Maple does not have tools in LinearAlgebra to do that. One of the practical difficulties with attempting it (using the current toolset) is that at some point some compound products of the block's names (scalar names) will be computed wrongly, as if the blocks (Matrix blocks) commuted under Matrix-multiplication.

For example, consider the determinant which would get computed if all these block names had not yet been assigned,

restart:
with(LinearAlgebra):

M := Matrix([[     Id,       Y,    -X,  a*X ],
             [    b*Y,       Z,   O31,  O31 ],
             [   X^%T,  O31^%T,     0,    0 ],
             [ O31^%T,  O31^%T,     0,    q ]]):

Determinant(M);

       2         2                      2  2        3      3                
 -q O31  Id + q X  Z - q O31 b Y X - O31  X  + X O31  + O31  a X + q X Y O31

         2  2  
    - O31  X  a

That q*X^2*Z term, for example, looks like it has violated noncommativity of the blocks under Matrix-multiplication. Many years ago, I might have tried to work aorund this, by using non-commuting `&*` as possible overload. But nowaways I'd prefer to submit yet another SCR for such this block Matrix support (a weaker kind of abstract linear algbera).

acer

@Danik Change all instances of `pi` to `Pi`.

In Maple, `Pi` is a name which evaluates in floating-point approximation to 3.14...

But `pi` is just another name, with no such meaning or behaviour by default.

@Danik Change all instances of `pi` to `Pi`.

In Maple, `Pi` is a name which evaluates in floating-point approximation to 3.14...

But `pi` is just another name, with no such meaning or behaviour by default.

@toandhsp 

ksols :=  isolve({(1/9)*Pi+2*k*Pi*(1/3) >= 1, (1/9)*Pi+2*k*Pi*(1/3)<= 2^Pi}) ;

               {k = 1}, {k = 2}, {k = 3}, {k = 4}

op( map2( eval, Pi/9+2*k*Pi/3, {ksols} ) );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

seq( eval( Pi/9+2*k*Pi/3, K), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

f := k -> Pi/9+2*k*Pi/3:

seq( f(rhs(op(K))), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

@toandhsp 

ksols :=  isolve({(1/9)*Pi+2*k*Pi*(1/3) >= 1, (1/9)*Pi+2*k*Pi*(1/3)<= 2^Pi}) ;

               {k = 1}, {k = 2}, {k = 3}, {k = 4}

op( map2( eval, Pi/9+2*k*Pi/3, {ksols} ) );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

seq( eval( Pi/9+2*k*Pi/3, K), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

f := k -> Pi/9+2*k*Pi/3:

seq( f(rhs(op(K))), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

@Lautrup I have a copy of what appears to be the Dcoument, repaired. It is 8.5Mb. Uploading it to Mapleprimes, even zipped, fails.

I will contact you. If you respond to the email then I will have your address and can send you the zipped file.

acer

@Lautrup I have a copy of what appears to be the Dcoument, repaired. It is 8.5Mb. Uploading it to Mapleprimes, even zipped, fails.

I will contact you. If you respond to the email then I will have your address and can send you the zipped file.

acer

@KCM 

p:=expand( (x+x^2)*(x+2) );

                           2          3
                        3 x  + 2 x + x 

sort(p,x);

                         3      2      
                        x  + 3 x  + 2 x

sort(p,x,ascending);

                                 2    3
                        2 x + 3 x  + x 

You can read about `sort` on its help-page.

@KCM 

p:=expand( (x+x^2)*(x+2) );

                           2          3
                        3 x  + 2 x + x 

sort(p,x);

                         3      2      
                        x  + 3 x  + 2 x

sort(p,x,ascending);

                                 2    3
                        2 x + 3 x  + x 

You can read about `sort` on its help-page.

@Christopher2222 There aren't much better ways that I can think of, other than using anames() of some kind before and after. There are variations on what you've described. Eg. you could print instead of showstat, after raising the verboseproc setting.

You might need to watch out for remember tables and/or Cache on the procs.

This shows why a .m file isn't nearly as good a way to store procedures as keeping plaintext copies. Also, it shows why using libary .mla archives is easier to use than .m, since there are easier tools for listing archive contents. (...additonally, .m is no good for saving whole modules.) But even .mla presents a (often surmountable) challenge for extracting module locals separately.

It has even happened (very rarely) in the distant past that .m formats have changed in incompatible ways between releases. Always keep precious source as plaintext, I'd advise (and not even as .mw/.mws), if you want to re-use it in the very long term.

I suppose that the .m file is not of your own creation, is that right?

Some people use .m in weird ways. I've seen people use it to store huge numeric Matrices, which would be more compactly stored using ExportMatrix (and as of recently, in binary format) and likely more efficiently re-read with ImportMatrix. Using .m is pretty old school. cf. comments above on modules.

(Are you looking at that HYPERG question? It has .txt source, not .m, so maybe you're doing something else. That source has handful of its procedures need edtiting to not use `args` as parameters, and it should be changed to save all contents to .mla instead. Changing it from table-based package to module would be icing on the cake, replacing its `init` function with ModuleLoad, perhaps. A OS tool like grep could be used to extract all the names that need to be savelib'd. The old-style help source could be split off separately as source too, I suspect.)

acer

@jimmyinhmb Here's an example, for multiplying the transpose of 50x50 Matrix A with 50x50 Matrix B one hundred thousand times.

On a fast i7 running Win 7 Pro (64bit Maple 15.01) it takes about 4 sec using the ideas laid out above, and it takes about 26 sec to do it repeatedly as C := A^%T . B

dgemm_module.mw

The benefit in speed gets less as the Matrix size goes up. But there is also the question of total memory allocation.