Date: Sun, 5 Oct 1997 10:50:41 +1000 (EST) From: Andrew Reilly <reilly@zeta.org.au> To: bde@zeta.org.au Cc: rcarter@consys.com, freebsd-current@FreeBSD.ORG Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710050050.KAA09111@gurney.reilly.home> In-Reply-To: <199710041615.CAA31787@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Oct, Bruce Evans wrote: > optimization level. The only sure way to get consistent results is > to store the result of EVERY fp operation to main memory ... I wasn't quite able to figure out which "side" of the argument you were going for here (maybe your last comment indicates that it is my side after all), but all I can say is Bah, Humbug! I do numerical (DSP) work all the time, and I'd much rather the floating point maths was absolutely as fast as it possibly could be, rather than worrying about the last few bits of precision. I usually work with 32-bit floats anyway. Consistency of floating point results is a myth, and dependance on every bit of precision, and rounding modes is algorithmic error. I recently tried to port some speech recognition code that runs fine on two different DSPs, a Dec Alpha, a Sparc and a SCO Pentium box to my FreeBSD machine. The HMM is expected to underflow all the time. In the brief time I had available, I could not figure out how to stop the FreeBSD maths from trapping at that point, and I couldn't write a trap handler that would ignore the error and continue, so I gave up. So there is a magic function that enables the "exceptions" to be masked, but it isn't mentioned in math(3). >>Java is consistent, there is one fp format and as far as fp exceptions >>go mask 'em all! > > This is the best default behaviour. Absolutely! I only disagree with Java that exact precision is important. I don't want the math libraries to jump through hoops to achieve it. -- Andrew "The steady state of disks is full." -- Ken Thompson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710050050.KAA09111>