Re: [Gcl-devel] Re: [Maxima] float to bfloat

[Steve Haflich]

   From: Raymond Toy <address@hidden>
   
   I think it was in one of Kahan's papers.  But it was talking about the
   FPU signaling an overflow.  The register would have useful
   information.  If you don't signal the overflow, then you'd get a
   infinity, which doesn't have room for anything else, as you say.

OK, makes sense.  Many fpus have implementation-dependent status bits
controlling whether and how the unit signals traps.  As I've groused
ill-naturedly before, it is hard to keep these bits from being tweaked
and not restored correctly by foreign libraries or even system
software.
   
   Like you, I rather like integer-decode-float signaling an error, but I
   didn't see anything really wrong with it.  But then you'd need some
   other way of determining if the output of i-d-f represented infinity
   or NaN.  I like cmucl providing float-infinity-p and float-nan-p, if
   that is really necessary or just handling the error from i-d-f.

Allegro has similar functions for NaNs and infinities, but they are
not exported.  Probably the exact mechanism whereby i-d-f informs
about exceptional floats is less important a design consideration than
the fact that it should do it one way or another.

By the way, although I don't consider myself a Maxima developer, I'd
like to explain tangentially why I sometime chime in on the side of
Common Lisp Compatibility In Maxima language details.  It is one thing
-- and certainly a very good thing -- to package Maxima as a closed,
easily-installed package for popular platforms.  The UI and graphingh
capabilities in that environment are crucial, much more important than
the invisible details how Maxima and Lisp work inside.

But there is another class of potential users, those who would treat
Maxima as a symbolic computation library internal to some other
application.  This community has little interest in the UI etc., but
they do need Maxima to cooperate with Common Lisp and to have calling
and representation conventions that aren't at odds with the rest of
the programming language.  (Franz has a certain corporate customer
with a very important engineering package that uses Maxima in this
way.  The program is more than a decade old and has saved untold
zillions of dollars in engineering process efficiency.)  The argument
could be made that the value of Maxima is contained in its
computational capabilities and libraries, and the UI etc. is an
unpleasant price you have to pay in order to access that value.  I
suggest the developer community in its zeal to package up a slick
self-contained symbolic mathematic application shouldn't forget about
this other potential community.