I did the above in the commandline (TTY) interface. Besides not having to do 2D Math typesetting of the results, that interface also has default support for common subexpression representation in the output.

Then I tried LinearAlgebra:-MatrixInverse(p(10,t)) in the Maple 12 Standard Java GUI. Maple can compute that result in a few seconds. But the Standard GUI is still chugging away on it after even a few minutes. And the GUI itself is using a lot of memory (500MB at this point).

Now, I don't know whether the huge amount of time and memory that the Standard GUI is using to display the result for size n=10 is due to lack of common subexpression labelling or to 2D Math output typesetting. But the TTY interface takes just a few pages to display it, with common subexpression labelling.

The Standard GUI also issued a slew of Java error messages to my console, starting with, `Exception in thread "Timer-1" java.lang.OutOfMemoryError: Java heap space'. As I type this, that example is still stalled on printing, and the Standard GUI is white (blank) and hence unresponsive. I shall have to kill the session (without being able to save the worksheet).

I tried it in Maple's Classic graphical interface. It worked beautifully.

acer

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

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