MaplePrimes - answers and comments on Question, looking for source of maple slow down

does that file crash the printer sub system ?

Axel Vogt — Mon, 21 Jan 2013 00:45:33 Z

Usually I was off *.mw sheets ...

That seems to have crashed my standard printer, which is a pdf-printer.
Printing just hangs up. The only thing which worked was printing to file
in the printer menu - but that seems to print postscript command code
(to be inspected with a proper editor), however it was possible to read
it with a postscript viewer (like ghostview) and to convert that to pdf.
My printer has its own, independent postscript system.

So I guess that file damaged the postscript for the printer.

I had to de-install and re-install the printer, which now works again.

Also had some strange entries in my registry, displaying non-Ascii,
it looked like chinese or so - non-readable for me.

Very strange ...

PS: I am using Win7

evalf here and there

Preben Alsholm — Mon, 21 Jan 2013 01:18:30 Z

I had a brief look at it. Make sure that floats are used all over. An evalf here and there will help.

It seems that you are solving a second order ode by a difference scheme. What is the point? Why not solve the ode numerically in Maple using dsolve/numeric? Unless the point is to see how well the difference scheme works for different stepsizes?

Torq:= t-> 1:
m := 1;
L := 1;
g := 9.81;
ode:=m*L^2*diff(x(t),t,t)=Torq(t)-m*g*L*sin(x(t));
res:=dsolve({ode,x(0)=0,D(x)(0)=0},numeric,range=0..12);
plots:-odeplot(res,[[t,x(t)],[t,diff(x(t),t)],[t,rhs(ode)]],0..12,refine=1);

thanks i'll try adding a few evalf()

umjack — Tue, 22 Jan 2013 01:45:00 Z

thanks i'll try adding a few evalf(),

yeah the point of the assignment was to not use in built funtions and see the effecrts of step size on first order numerical estimations