[comp.sys.ridge] Ridge 3200 Floating Point Underflow Bug

bruce@wpi.wpi.edu (Bruce P Johnston) (06/06/90)

Has anyone experienced floating point underflow problems on
a Ridge 3200 system?

We are having problems working with very small numbers near
the lower limit of double precision (ie ~1.0d-308).  Instead of 
underflowing to zero (0.0) as they should, underflowed numbers
"wrap around" to very large numbers (~1.0d+308).

I would appreciate hearing from anyone who has experienced this
and might have a fix (other than scaling or software checks) for
this problem.

mike@suns.UMD.EDU (Mike Briley) (06/06/90)

If the floating point implementation is anything like that of a 32C,
the underflow behavior isn't a bug, it's a feature.
From what I heard, rather than having the overhead required to
set FPU's to zero, Ridge hardware just lets them go be whatever they
want.  Ridge got a little more speed out of the deal by doing this.  We
had underflows in one of our stellar atmosphere code for about a year
before we knew about this.  We just trapped 'm out and kept on going.
Unfortunately, the only way we've been workng around this is either by
doing our business in logs, or software checks.  It is possible to roll
your own signal handler in C via a call to signal (see signal(2)), but
I've never gotten around to it.

-Mike Briley
-University of MAryland School for Famous Astronomers