I would suggest not doing that, if avoidable. The masking of the actual entries by dummy names may lead to use of a "hidden zero" as a pivot during computation of the inverse. If that happened (though perhaps quite unlikely) then the result would be incorrect. Zeros could appear in denominators upon resubstitution and unmasking of the actual entries, with numeric exception error ensuing.

But now we know that the actual entries are not just simple names, even if they recur with a given structure. So is the huge memory use due to printing of results, or perhaps also due to computational grind during the inversion? Instead of doing the inversion using a context-menu, as was described, do it by issuing the relevant command. And suppress printing of the output, terminating that command with a colon instead of a semicolon (as alec suggested).

The code in question could also be uploaded to this site, using its File Manager.

acer

I would suggest not doing that, if avoidable. The masking of the actual entries by dummy names may lead to use of a "hidden zero" as a pivot during computation of the inverse. If that happened (though perhaps quite unlikely) then the result would be incorrect. Zeros could appear in denominators upon resubstitution and unmasking of the actual entries, with numeric exception error ensuing.

But now we know that the actual entries are not just simple names, even if they recur with a given structure. So is the huge memory use due to printing of results, or perhaps also due to computational grind during the inversion? Instead of doing the inversion using a context-menu, as was described, do it by issuing the relevant command. And suppress printing of the output, terminating that command with a colon instead of a semicolon (as alec suggested).

The code in question could also be uploaded to this site, using its File Manager.

acer

Under the Classic or commandline interfaces, one should be able to issue,

plotsetup(maplet);

Doing that makes a big difference for the output of, say, plots:-polarplot(1). Or for plots with typeset 2D Math in the caption.

A disadvantage is that control doesn't appear to return to the Classic worksheet until the pop-up plot window is dispelled.

acer

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

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