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.

@Mac Dude It is specific to 2D Math input mode, and will not occur in 1D Maple Notation input mode.

Basically, if one enters an assignment to a function call, such as f(t):=t^2 then a diambiguation dialogue popup window appears, and one gets given the choice between assigning to f's remember table, or assigning a procedure like proc(t) t^2; end proc to f.

In 1D mode, it's always an assignment to f's remember table. And if `f` was previously unassigned then it gets a remember table, ie. it is assigned a proc with a remember table. It sounds like that's what you're seeing in your Variables palette. For example, as 1D Maple Notation input,

restart:
f(t):=t^2:
eval(f);
op(4,eval(f));

It is unfortunate that if one does it in 2D Math and chooses function definition instead of remember table assignment then the GUI and Typesetting mechanism doesn't replace the 2D Math input with t->t^2 or similar. So it doesn't bother to teach a syntax which works unambiguously in all interfaces and entry modes.

One can also set the default 2D Math parser interpretation of such assignments. See the Typesetting,Settings help-page and the `functionassign` option.

@Mac Dude It is specific to 2D Math input mode, and will not occur in 1D Maple Notation input mode.

Basically, if one enters an assignment to a function call, such as f(t):=t^2 then a diambiguation dialogue popup window appears, and one gets given the choice between assigning to f's remember table, or assigning a procedure like proc(t) t^2; end proc to f.

In 1D mode, it's always an assignment to f's remember table. And if `f` was previously unassigned then it gets a remember table, ie. it is assigned a proc with a remember table. It sounds like that's what you're seeing in your Variables palette. For example, as 1D Maple Notation input,

restart:
f(t):=t^2:
eval(f);
op(4,eval(f));

It is unfortunate that if one does it in 2D Math and chooses function definition instead of remember table assignment then the GUI and Typesetting mechanism doesn't replace the 2D Math input with t->t^2 or similar. So it doesn't bother to teach a syntax which works unambiguously in all interfaces and entry modes.

One can also set the default 2D Math parser interpretation of such assignments. See the Typesetting,Settings help-page and the `functionassign` option.

If the compile=true optional argument is supplied in the dsolve,numeric call then the total time to produce the associated implicitplot is reduced by about 20% on my Maple 16 system.

I confess that is news to me. I knew that dsolve,numeric has had (at least one form or another of) compilation functionality, for some time now. But I had thought that it was, for some releases now, automatically invoked by Maple.

I suspect that for many systems of simply expressed DEs (no special functions) the performance benefit to using this option can be considerable, especially for parametrized ODEs where the computation may be done for many sets of parameter values.

The machinery of `implicitplot` may incur a significant portion of overhead in this example, but a few other simple tests suggest to me that some other examples (eg. dsolve,numeric,parameters hooked up to GUI Slider Components, or invoked to produce traditional animations) may benefit a great deal more. Maybe up to 50% or so!?... I'll have to revisit some old posts.

acer

If the compile=true optional argument is supplied in the dsolve,numeric call then the total time to produce the associated implicitplot is reduced by about 20% on my Maple 16 system.

I confess that is news to me. I knew that dsolve,numeric has had (at least one form or another of) compilation functionality, for some time now. But I had thought that it was, for some releases now, automatically invoked by Maple.

I suspect that for many systems of simply expressed DEs (no special functions) the performance benefit to using this option can be considerable, especially for parametrized ODEs where the computation may be done for many sets of parameter values.

The machinery of `implicitplot` may incur a significant portion of overhead in this example, but a few other simple tests suggest to me that some other examples (eg. dsolve,numeric,parameters hooked up to GUI Slider Components, or invoked to produce traditional animations) may benefit a great deal more. Maybe up to 50% or so!?... I'll have to revisit some old posts.

acer