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