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.

@jschulzb With the compile=true option in the (single) call to dsolve it takes approximately 13 sec on an Intel i5 on 64bit Linux in Maple 15 with gcc as the compiler, 15 sec on that i5 in Maple 16, and about 17 sec on an i7 in 64bit Maple 16 on Windows 7 with the free MSVC++ compiler.

event0compiled.mw

Those timings seem to be about 15-20% faster than without the compile=true option. For the compile=true option to work I suspect that one needs Compiler:-Compile to also function OK. Hmm, I'm not sure where dsolve,numeric's compile=true option might be documented. (!)

That try..catch might not be necessary. I guess I was concerned that if the solver halted with an error that the subsequent bits to extract and test the "last" computed point might get skipped.

There is overhead in implicitplot, which might be overshadowing the performance benefit of using compile=true here. In some other examples where I only did multiple calls to the emitted procs, or multiple calls to `odeplot`, I saw even more timing gains. I suspect that this would also be very useful when doing parameter optimization (as in Optimal Control).

If I may be allowed a general remark: for simple models an exact symbolic result might be obtained, as is the case here. But of course for more involved systems computing an exact result in full might not be possible or practical. Hence numerical solving gets its day in the spotlight. For simple systems and problems it might even be that using a rootfinder like fsolve to find a special value's occurrence is practical. And it's easier to implement an fsolve search using dsolve's output procs than it is to set up even the simplest of events. But in general as parametrized ode systems and the events get more complicated, or for parametrized systems which must be run many times to search the parameter space, using dsolve's event handling mechanisms should be the clear performance winner. The combination of dsolve's events and dsolve's parameters can be very powerful. Combine that with top-notch DAE solvers and it's possible to build a modelling environment as powerful as... MapleSim.

@jschulzb With the compile=true option in the (single) call to dsolve it takes approximately 13 sec on an Intel i5 on 64bit Linux in Maple 15 with gcc as the compiler, 15 sec on that i5 in Maple 16, and about 17 sec on an i7 in 64bit Maple 16 on Windows 7 with the free MSVC++ compiler.

event0compiled.mw

Those timings seem to be about 15-20% faster than without the compile=true option. For the compile=true option to work I suspect that one needs Compiler:-Compile to also function OK. Hmm, I'm not sure where dsolve,numeric's compile=true option might be documented. (!)

That try..catch might not be necessary. I guess I was concerned that if the solver halted with an error that the subsequent bits to extract and test the "last" computed point might get skipped.

There is overhead in implicitplot, which might be overshadowing the performance benefit of using compile=true here. In some other examples where I only did multiple calls to the emitted procs, or multiple calls to `odeplot`, I saw even more timing gains. I suspect that this would also be very useful when doing parameter optimization (as in Optimal Control).

If I may be allowed a general remark: for simple models an exact symbolic result might be obtained, as is the case here. But of course for more involved systems computing an exact result in full might not be possible or practical. Hence numerical solving gets its day in the spotlight. For simple systems and problems it might even be that using a rootfinder like fsolve to find a special value's occurrence is practical. And it's easier to implement an fsolve search using dsolve's output procs than it is to set up even the simplest of events. But in general as parametrized ode systems and the events get more complicated, or for parametrized systems which must be run many times to search the parameter space, using dsolve's event handling mechanisms should be the clear performance winner. The combination of dsolve's events and dsolve's parameters can be very powerful. Combine that with top-notch DAE solvers and it's possible to build a modelling environment as powerful as... MapleSim.