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

[Camm Maguire]

Greetings!

Richard Fateman <address@hidden> writes:

> Steve Haflich wrote:
> 
> >   From: Camm Maguire <address@hidden>
> >but as a Common Lisp implementor I don't believe it is compatible with
> >the other real-world constraints on Common Lisp.  Mathematically
> >consistent treatment of the IEEE exceptional fp values (the Infinities
> >and NaNs) in both their generation and detection is hard to reconcile
> > with achieving raw platform fp speed.
> I suspect just the opposite is happening.
> The way to make floats run at raw platform speed is to let the
> hardware do what it
> is supposed to do.  Lisp doesn't do this, and consequently is
> SLOWER. That is, Lisp
> checks before dividing to see if it is dividing by zero. (etc.). The
> right way is to catch the exception.

OK, in the light of current GCL, compiled arithmetic with the right
declarations and optimization settings is simply machine arithmetic.
There is also machinery for trapping and processing SIGFPE (floating
point exception on Unix), which could doubtlessly be improved from its
current state.

What could conceivably be achieved is that in the boxed protected
arithmetic routines, which are going to be slow no matter what, to
avoid checking for zero denominators etc. and rely on the floating
point signal, the trapping of which could be linked into the error
system (and turned off with ignore-errors, etc.)  I'm not sure if this
would be useful from a speed standpoint, but it might be for a
consistency with compiled code standpoint.

In addition, right now the GCL printer triggers an error on NaN and
Inf.  This could be easily remedied through the definition of the
appropriate constants as lisp symbols.  I suppose this would be useful
for clarity.

> I've written a paper somewhere about extending rationals
> http://www.cs.berkeley.edu/~fateman/papers/extrat.ps
> ......
> 

I've retrieved this and will try to look at it time and (user)
interest permitting.

> >I suppose nearly all serious platforms pretty much support IEEE these
> >days, and FPUs have lotsa neat status bits to get the behavior the
> >imlpementation wants, but experience moer than a decade ago showed it
> >is hard to guarantee that mad-prion routines here and there don't mess
> >with these bits and forget to restore them.
> >
> Lisp systems could provide access to the hardware instead of being the
> prion propagator.

What is a prion?

> Occasionally I have tried to use the underlying hardware and could get
> access to it by
> using full optimization on arithmetic expressions.  Allowing the lisp
> to do any error checking
> generally means that your result will be wrong on all hardware. There

??? I.e. that the boxed versions don't behave identically to the fully
optimized ones?

> are good C and Fortran
> routines that are careful about bits.
> RJF
> 

Take care,

> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah