Problem in plot3d?



>>>>> "Robert" == Robert Dodier <robert.dodier at gmail.com> writes:

    Robert> On 1/28/07, Mario Rodriguez <biomates at telefonica.net> wrote:
    >> > What happened is that f(x, y) was evaluated for x=0 and y=0,
    >> > which caused a divison by 0, which was not handled gracefully
    >> > by plot3d. Sorry for the bother; this is a bug in the plotting code.
    >> > (Specifically a function named COERCE-FLOAT-FUN.)
    >> 
    >> This is also a bug to be fixed in 'gpdraw' (ok, ok, let's call it 'draw'
    >> in the near future :), since it also calls 'coerce-float-fun'.

    Robert> Well, I wonder where we should try to catch errors -- whether
    Robert> in the function constructed by COERCE-FLOAT-FUN or in its caller.

    Robert> Although an error could theoretically be interesting to the caller,
    Robert> I don't think that's exploited in current Maxima code.
    Robert> So I guess at this point I'm inclined to say the function constructed
    Robert> by COERCE-FLOAT-FUN should catch any Lisp or Maxima errors
    Robert> (and return NIL in those cases).

Doesn't coerce-float-fun already catch errors?  At least there's a
comment and some catch/handler-case statements in the code.

The 2D adaptive plotter depends on this to work because that's how it
detects discontinuities.  Unfortunately, it's a rather imprecise
mechanism, because the adaptive plotter can't tell if it's because of
a discontinuity or domain error or some other unexpected case.  I
think the original design had coerce-float-fun signal an error which
the caller could catch and decide what to do.  But gcl (the version at
that time) didn't implement handler-case and friends very well, so the
code doesn't do that.

I sometimes think gcl is hindering development of some parts of
maxima.  Could we use ecl instead, which, I think, is much more ansi
compliant?  I think ecl runs on all the platforms we need, including
Windows.  But I have never used ecl, so I don't know what it's really
like.

Ray