At 02:12 PM 9/10/2001 -0700, Hong Zhang wrote:
> > Uri Guttman
> > > we are planning automatic over/underflow to bigfloat. so there is no
> > > need for traps. they could be provided at the time of the
> > > conversion to big*.
> >
> > OK. But will Perl support signaling and non-signaling NANs?
>
>I don't think we should go for automatic overflow/underflow between
>float and bigfloat.
Not for N registers, no. Perl's standard scalar variable will do this, though.
>The float exception (overflow, underflow, inexact,
>divide zero, ...) is very difficult to handle.
That's why we wrap it in a generic macro and leave it for the individual
ports to handle.
>Using Unix signal is
>expensive and very platform-specific (lots of ucontext issues). Since
>C language does not support floating-point signal, we may use some
>assembly code to handle it, it will be porting nightmare.
Not if we do it right to start. Yes, there may be snippets of assembly in
solaris.c/vms.c/linux.c/whatever.c, but that's fine. We can use a boring
test comparison as a generic replacement on platforms people don't want to
use a specific one on.
>Since most of floating-point assumes IEEE-semantics, taking automatic
>float/bigfloat will change this assumption significantly.
Most people I know that use floating point numbers don't have any idea that
there are well-defined IEEE semantics, let alone what they are. Some folks
are, and for them we'll make sure you can avoid leaving IEEE floats.
Of course, that's as much an argument for automatically going straight to
bigfloats rather than going to native floats, since if people generally
have no idea what the errors inherent in IEEE floats are they probably
ought not use them. That's something to take up with Larry, though.
>It may a
>lot of code and algorithm. I think it is safer just to provide a
>BigDecimal class for developers to use, and keep the basic float
>semantics (close to 64-bit IEEE-754 if possible).
IEEE floats suck. (I've got an amazingly bad opinion of a lot of
widely-accepted computer practice, don't I? :) They're an OK option for
what they are, and the hardware speed support is nice, but let's face it,
they're a compromise with adequate characteristics, and the design
compromises are usually the wrong ones (with the single exception of speed)
for what most people do with floats in perl.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
