You are quite right in most of your points. I was counting on the PC to do the number crunching so I would not have to think about the process at all.
I don't see anything wrong with the do but it may not be a standard way so I changed it to a block. The extra parentheses were there because the original do block needed them and then after some changes they were no longer needed and I did not catch that.
I did not know that bfloat were contagious so I eliminated most of them.
For this plot a value of 32 for fpprec turns out to be more than sufficient.
Structural indentation would have helped a lot but I although I knew it was possible to enter on more than one line at a time until now I have not used this feature.
The c[i] are independent of x but not of the energy and since this is a 2d plot of x by energy you have to recalculate them for each new energy. The only way I know of to get around that is to use draw3d(explicit(f[i](x), x, -4, 4,... with about 600 explicits and 600 functions to plot, one for each line. I tried that and it did not work. The point of failure was in the plotting, the function and all of the c[i] only took about 40 seconds to compute.
The use of the power series directly was just dumb. I didn't think of that. I will change it to calculate an accumulating value for x, then x^2, then x^3 etc... using multiplication which hopefully will make this go a lot faster.
Bottom line is I created 601 functions f[0](x) to f[600](x) then used stringout and makelist to send the output to 600 txt files. Then I wrote some code in another programming language to pull all the data into a table and then plotted the result myself with my own code. It still took 4.5 hours to write all the text files for 300 terms, but it worked. Maybe with the x, then x^2 , then x^3 accumulator it can go faster, but I am working on that now.
I still don't know why the crash during the plot3d. 200 terms is good enough also.
Rich
------------Original Message------------
From: "Stavros Macrakis" <macrakis at alum.mit.edu>
To: "Robert Dodier" <robert.dodier at gmail.com>
Cc: "Maxima List" <maxima at math.utexas.edu>, rvh2007 at users.sourceforge.net
Date: Tue, Apr-8-2008 12:17 PM
Subject: Re: [Maxima] Fwd: [ 1934732 ] Plotting Complicated Functions Generates Error
On Sat, Apr 5, 2008 at 5:16 PM, Robert Dodier <robert.dodier at gmail.com> wrote:
> Hi, I'd like to draw your attention to this bug report:
> https://sourceforge.net/tracker/index.php?func=detail&aid=1934732&group_id=4933&atid=104933
> If anyone can take a look, that would be great.
Here are some comments on the code style. They shouldn't be causing
any substantive problems, but they may reflect some misunderstandings
about how Maxima operates:
-- The outermost "do" (an infinite loop) should be a "block" (a simple
block). This shouldn't matter, since there are explicit "return"
statements at the end to exit from it, but it would be clearer.
-- It's not clear why the code between "fpprec:150" and "p:c[0]" is
enclosed in parens.
-- There shouldn't be a need to use bfloat(...) in so many places,
since bfloats are contagious. Probably enough to start out with
En:bfloat(En), x:bfloat(x)
-- It's not clear what the intent of float(2.5) is. Why not just 2.5?
float(p^2) is presumably there to downconvert from bfloats to floats.
-- the value of the last statement in a block (but not a do) is
returned, so the return functions aren't necessary
-- structural indentation makes it easier to read the code. This may
be an issue with wxm, but I'm afraid I don't know anything about wxm.
If execution time is an issue -- and I suspect it is with fpprec=150,
max=210, and a grid of 860x580 (104m executions of each loop!) -- the
code should be reorganized. For one thing, c[n] is independent of x,
so why calculate it for every value? Calculating sum(c[i]*x^i...)
using x^i rather than multiplications is expensive. Less
significantly, instead of comparing p^2 to 10^25, it would be faster
to compare abs(p) to 1.0b13. That sort of thing.
-s
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima