@serena88 

ans:=seq(x*B, x in A);

ans[3];

@serena88 

ans:=seq(x*B, x in A);

ans[3];

@mrask The `simplify` command should get rid of terms identically like 0.*I (while the `fnormal` command can turn "negligible" float values to 0.0 or 0.0*I).

The 0.*I terms look like so-called numeric artefacts (due to round-off error during float computation).

@mrask The `simplify` command should get rid of terms identically like 0.*I (while the `fnormal` command can turn "negligible" float values to 0.0 or 0.0*I).

The 0.*I terms look like so-called numeric artefacts (due to round-off error during float computation).

@mrask Ok, my example will be much shorter, because I'm not going to type in numbers from an embedded image.

It matches pretty well on r=-1..1.

Exx:=((9.134566608e19*cos(arctan(0.36397023*r)+0.087266462)^2
     +1.73113669e21*cos(arctan(0.36397023*r)+0.087266462)^6))/
     (8.65439107e19*cos(arctan(0.36397023*r)+0.087266462)^2):

sol:=numapprox[minimax](Exx,r=-1..1,[3,3]);

  (19.00213865

     + (-12.01638803 + (0.01176765813 + 0.5417654592 r) r) r)/

    (0.9155088810

     + (-0.4682135154 + (0.1689822380 - 0.09816443908 r) r) r)

plot([Exx,sol],r=-4.8..1.85,legend=["Exx","sol"]);

But when I look at Exx a few things come to mind. The presence of so many common subterms, and those rather large exponents which all just happen to cancel out nicely, makes me wonder whether your call to `simplify` had not perhaps done more damage than good. Maybe you could upload your full worksheet, or something with the unsimplified expression.

@mrask Ok, my example will be much shorter, because I'm not going to type in numbers from an embedded image.

It matches pretty well on r=-1..1.

Exx:=((9.134566608e19*cos(arctan(0.36397023*r)+0.087266462)^2
     +1.73113669e21*cos(arctan(0.36397023*r)+0.087266462)^6))/
     (8.65439107e19*cos(arctan(0.36397023*r)+0.087266462)^2):

sol:=numapprox[minimax](Exx,r=-1..1,[3,3]);

  (19.00213865

     + (-12.01638803 + (0.01176765813 + 0.5417654592 r) r) r)/

    (0.9155088810

     + (-0.4682135154 + (0.1689822380 - 0.09816443908 r) r) r)

plot([Exx,sol],r=-4.8..1.85,legend=["Exx","sol"]);

But when I look at Exx a few things come to mind. The presence of so many common subterms, and those rather large exponents which all just happen to cancel out nicely, makes me wonder whether your call to `simplify` had not perhaps done more damage than good. Maybe you could upload your full worksheet, or something with the unsimplified expression.

@Jarekkk Interesting. It also seemed to work ok for me using 32bit Maple 15.01 on Windows XP, in the Classic GUI (both with and without the x=8 constraint). Perhaps support@maplesoft.com could reproduce the problem on 32bit Vista Home Premium.

The example, Optimization:-LPSolve(7*x+3*y, {6*x+2*y >= 49},assume=nonnegint) works fine for me in both the Classic and Standard GUIS of 32bit Maple 14.01 and 15.01 for MS-Windows.

What platform are you running it on? Is there anything in your initialization file?

acer

This can be considered as a feasibility question: given some linear constraints and the requirement of an integer-value solution then find a feasible point.

If one adds in a linear objective function then it can be seen as the familiar (I)LP. The Optimization package can handle this particular example, if we supply an (here inconsequential) objective.

Optimization:-Minimize(1,
                       {6*x+2*y>=49, 7*x+3*y=0, y>=0},
                       assume=integer)[2];

                         [x = 8, y = 1]

acer

This can be considered as a feasibility question: given some linear constraints and the requirement of an integer-value solution then find a feasible point.

If one adds in a linear objective function then it can be seen as the familiar (I)LP. The Optimization package can handle this particular example, if we supply an (here inconsequential) objective.

Optimization:-Minimize(1,
                       {6*x+2*y>=49, 7*x+3*y=0, y>=0},
                       assume=integer)[2];

                         [x = 8, y = 1]

acer

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

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