One can avoid unnecessary re-evaluation (re-computation) by fsolve in the cases in the loop where it has returned unevaluated by doing the type-check as type(eval(ans,1),...). Or the whole loop might be done in a procedure, with `ans` declared locally so that it is evaluated 1-level by default.

In the given worksheet,. where it fails for T=755 to T=800, the time spent by fsolve searching in vain for a solution can be cut in half. On my machine, the total time in the loop lowers from about 105sec down to about 55sec.

Let's suppose now that we knew in advance not to start T as low as 755. This worksheet seems to be another example where using the previous iteration's solution (for x1 and x2) as a starting point for fsolve in the current iteration can speed things up. Starting from T=800, then this crude but effective technique can drop the total time in the loop from 4.8sec down to 3.2sec on my machine.

anotherfsolve.mw

(It's curious, that this is about the third time a a week or so that this kind of benefit to fsolve in a loop has come up. I would expect that the re-use of the previous result as initial guess to the next iteration is not limited to fsolve; it might well help a little with DirectSearch or another searching rootfinder.)

acer

I've previously expressed some thoughts on the general topic of your point a) about memory performance.

acer

You write that the red is less easy to read and takes longer to type down.

Does this mean that by "red" you mean 1D plaintext Maple Notation input, and by "black" you mean 2D typeset math input?

acer

The FileTools:-Compressed subpackage is set up to use gzread from zlib, I think, and so works with gzip'd files.

You might possibly be able to set up a define_external to an inflate function that would work with a pkzip'd file. You could look at the zlib manual, and maybe get hints from,

kernelopts(opaquemodules=false):
print(FileTools:-Compressed:-ModuleLoad);
print(FileTools:-Compressed:-defun);

acer

@Christopher2222 It's not that the first argument to Remove evaluates (by itself) to true. It's that in Maple 12 it has to be an appliable thing (eg. procedure) which can be applied in turn to each character of string `a` and return true or false for each.

@Christopher2222 It's not that the first argument to Remove evaluates (by itself) to true. It's that in Maple 12 it has to be an appliable thing (eg. procedure) which can be applied in turn to each character of string `a` and return true or false for each.

Note that your readdata call will produce a list of lists, which isn't a Matrix. You can pass a list of lists to the Matrix() constructor.

An alternative might be something like this, which can be used to produce a 4x24 Matrix of strings,

fscanf(".../alpha.txt","%{4,24}sm")[1];

acer

@GrecoRoman The task at hand is to write a recursive procedure which reverses strings. Using any other (nonrecursive) procedure which reverses strings is surely breaking the rules and not keeping true to the spirit of the given task.

Isn't the assignment to construct a procedure which accomplishes string reversal via the act of calling itself recursively?

@GrecoRoman The task at hand is to write a recursive procedure which reverses strings. Using any other (nonrecursive) procedure which reverses strings is surely breaking the rules and not keeping true to the spirit of the given task.

Isn't the assignment to construct a procedure which accomplishes string reversal via the act of calling itself recursively?

@GrecoRoman Consider the following, where we are inside some procedure which is supposed to be reversing the string S.

S:="abcdef":

cat( S[-1], S[1..-2] );

                            "fabcde"

Notice that the above takes the last character of S and concatenates it with the earlier substring.

But you don't really want to prepend "f" to "abcde". You want to prepend "f" to the reverse of "abcde". So..., if only we had some procedure that could reverse "abcde"...

Oh, but wait! The procedure that we are inside is supposed to reverse strings.

@GrecoRoman Consider the following, where we are inside some procedure which is supposed to be reversing the string S.

S:="abcdef":

cat( S[-1], S[1..-2] );

                            "fabcde"

Notice that the above takes the last character of S and concatenates it with the earlier substring.

But you don't really want to prepend "f" to "abcde". You want to prepend "f" to the reverse of "abcde". So..., if only we had some procedure that could reverse "abcde"...

Oh, but wait! The procedure that we are inside is supposed to reverse strings.

I have both 32bit and 64bit Maple 16.01 installed on 64bit Windows 7 Professional.

The Compiler:-Compile command works (using the watcom that installed with Maple) in the 32bit Standard GUI.

But in the 32bit Classic interface the call to Compiler:-Compile just hangs. The cursor shows as hourglass, and control is not returned to the worksheet, though no process is chewing up cpu. The Classic GUI's menubar is all grayed out. But closing the GUI using the usual MS-Windows titlebar does lead to "You are in the middle of a computation...", and "Do you want to save....".

I have the free MSVC++ compiler installed and working in the 64bit Maple 16.01 Standard GUI. I haven't ever configured the 32bit Maple to use the 32bit MSVC++, however.

[edited] It seems to work ok in the 32bit Maple 16.01 commandline interface (cmaple.exe) running in a DOS shell terminal-window.

acer

@student302 Okay, this sheet has separate issues. One is that `Pi` is treated specially. If you want to compare it numerically inside a conditional (which by default uses `evalb` implicitly) then you have to either convert it to a floating-point number or use a different boolean evaluator than `evalb`.

if 2 < Pi then "ok"; end if;
Error, cannot determine if this expression is true or false: 2 < Pi

if 2 < evalf( Pi ) then "ok"; end if;
                              "ok"

if is( 2 < Pi ) then "ok"; end if;
                              "ok"

Note also that powering by the base of the natural logarithm ("e") is done using the `exp` command, and not by raising to the power `e`. That is for 1D input. Maple can typeset 2D Math output and make it look like e^stuff.

Your procedure could be written this way, for example,

f := proc(x)
     local result:
     if is( x <= (-3*Pi/2) ) then 
         result :=  exp(x+((3*Pi)/2)):
     elif is( x > (-3*Pi/2) and x <= (3*Pi)/2 ) then 
         result := 1 - (exp(I*x)/2) - exp(-(I)*x)/2:
     elif is( x > 3*Pi/2 ) then 
         result := exp(-(x)+((3*Pi)/2)):
     end if:

     return result;
end proc:

You're certainly not the first person to write code which runs afoul of these subtleties. Have a look at this great post by Robert Israel.

@student302 Okay, this sheet has separate issues. One is that `Pi` is treated specially. If you want to compare it numerically inside a conditional (which by default uses `evalb` implicitly) then you have to either convert it to a floating-point number or use a different boolean evaluator than `evalb`.

if 2 < Pi then "ok"; end if;
Error, cannot determine if this expression is true or false: 2 < Pi

if 2 < evalf( Pi ) then "ok"; end if;
                              "ok"

if is( 2 < Pi ) then "ok"; end if;
                              "ok"

Note also that powering by the base of the natural logarithm ("e") is done using the `exp` command, and not by raising to the power `e`. That is for 1D input. Maple can typeset 2D Math output and make it look like e^stuff.

Your procedure could be written this way, for example,

f := proc(x)
     local result:
     if is( x <= (-3*Pi/2) ) then 
         result :=  exp(x+((3*Pi)/2)):
     elif is( x > (-3*Pi/2) and x <= (3*Pi)/2 ) then 
         result := 1 - (exp(I*x)/2) - exp(-(I)*x)/2:
     elif is( x > 3*Pi/2 ) then 
         result := exp(-(x)+((3*Pi)/2)):
     end if:

     return result;
end proc:

You're certainly not the first person to write code which runs afoul of these subtleties. Have a look at this great post by Robert Israel.

@Christopher2222 Does the code get a wrong value for `ans`? That is what it uses as the IP address to query.