Maple stores a Matrix entirely in (only some) contiguous memory block only in the cases of hardware datatypes (float[8], complex[8], integer[4], etc) and perhaps immediate integers. For Matrices with symbolic expressions as the entries, the stored entries will point to locations for those objects. Those individual symbolic expressions represented in the Matrix entries may well be scattered throughout Maple's allocated memory.

acer

Nice, since op() is good interpretation of the poster's phrase, "part of an expression"

acer

Nice, since op() is good interpretation of the poster's phrase, "part of an expression"

acer

A nice clear analysis, thank you. I kept it short just to illustrate that the expected simplification originally posted need not always hold. (Ie, evaluate both, at the named point.) But giving a result like -Pi/(2*ln(x)) > Im(a) >= Pi/(2*ln(x)) is better.

acer

A nice clear analysis, thank you. I kept it short just to illustrate that the expected simplification originally posted need not always hold. (Ie, evaluate both, at the named point.) But giving a result like -Pi/(2*ln(x)) > Im(a) >= Pi/(2*ln(x)) is better.

acer

Am I missing something, or is there a problem for [a=infinity,b=infinity]?

> piecewise(abs(a)<infinity,1,0); #??
                                       1

%maple10.02 -c "print(piecewise(abs(a)<infinity,1,0))" -c "quit" -s -q
                          { 1        | a | < infinity
                          {
                          { 0           otherwise


%maple10.03 -c "print(piecewise(abs(a)<infinity,1,0))" -c "quit" -s -q
                                       1

acer

Am I missing something, or is there a problem for [a=infinity,b=infinity]?

> piecewise(abs(a)<infinity,1,0); #??
                                       1

%maple10.02 -c "print(piecewise(abs(a)<infinity,1,0))" -c "quit" -s -q
                          { 1        | a | < infinity
                          {
                          { 0           otherwise


%maple10.03 -c "print(piecewise(abs(a)<infinity,1,0))" -c "quit" -s -q
                                       1

acer

You could try using fsolve's 'avoid' option. See the last example in the help-page ?fsolve,details for an illustration. You could have it loop until it either failed to find more solutions or obtained the finite number of solutions that you expect. (Unlike that example in that help-page, you could start with an empty set of solutions S:={} and then augment S with each new found solution.)

Alternatively, you might try using RootFinding:-NextZero instead of fsolve, for a univariate expression or procedure like in your example. Start it searching from the left endpoint of your range, and then repeat with it searching from the previous root (or a small amount more than that) until you obtain as many as you expect or it fails to find any more.

acer

You could try using fsolve's 'avoid' option. See the last example in the help-page ?fsolve,details for an illustration. You could have it loop until it either failed to find more solutions or obtained the finite number of solutions that you expect. (Unlike that example in that help-page, you could start with an empty set of solutions S:={} and then augment S with each new found solution.)

Alternatively, you might try using RootFinding:-NextZero instead of fsolve, for a univariate expression or procedure like in your example. Start it searching from the left endpoint of your range, and then repeat with it searching from the previous root (or a small amount more than that) until you obtain as many as you expect or it fails to find any more.

acer

I didn't see it mentioned in the original post that A was invertible. If A is symmetric but not invertible, then symmetric solution X need not be unique.

acer

I didn't see it mentioned in the original post that A was invertible. If A is symmetric but not invertible, then symmetric solution X need not be unique.

acer

The plot of 'f' shows a flat region, or problems except for the restricted domain from about 0.7 to 0.9 or so. It looks as if fsolve may be having difficulty "finding" that section, if the supplied domain is not tight enough.

> f := proc(t)
>    local x, y;
>          maximize((1.3-x)*x+0.3*(1-y)*(y-x), x=t..0.9, y=t..0.9);
> end proc:

> fsolve('f(t)-0.4', t=0.5..0.9);
                                 0.8088533865
 
> fsolve(t->f(t)-0.4, 0.5..0.9);

                                 0.8088533865

acer

The plot of 'f' shows a flat region, or problems except for the restricted domain from about 0.7 to 0.9 or so. It looks as if fsolve may be having difficulty "finding" that section, if the supplied domain is not tight enough.

> f := proc(t)
>    local x, y;
>          maximize((1.3-x)*x+0.3*(1-y)*(y-x), x=t..0.9, y=t..0.9);
> end proc:

> fsolve('f(t)-0.4', t=0.5..0.9);
                                 0.8088533865
 
> fsolve(t->f(t)-0.4, 0.5..0.9);

                                 0.8088533865

acer

Rerunning the whole sheet, which begins with a "restart", might not illustrate the problem. I suspect that in order to see the problem one would have to execute the whole sheet, and then repeat only the command that appears (3 times) right at the bottom. I interpreted it as that repeated execution of that particular command leads to the memory usage increase.

acer

Rerunning the whole sheet, which begins with a "restart", might not illustrate the problem. I suspect that in order to see the problem one would have to execute the whole sheet, and then repeat only the command that appears (3 times) right at the bottom. I interpreted it as that repeated execution of that particular command leads to the memory usage increase.

acer