Date: Fri, 03 Oct 1997 15:23:55 -0700 From: "Russell L. Carter" <rcarter@consys.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@freebsd.org Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710032223.PAA04679@cssunix.conceptual.com> In-Reply-To: Your message of "Sat, 04 Oct 1997 05:05:45 %2B1000." <199710031905.FAA28989@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
} }Who is Bruce? ;-) bde's point of view is recorded in npx.h: } }--- }/* Intel prefers long real (53 bit) precision */ }#define __iBCS_NPXCW__ 0x262 }/* wfj prefers temporary real (64 bit) precision */ }#define __386BSD_NPXCW__ 0x362 }/* } * bde prefers 53 bit precision and all exceptions masked. }--- } Interesting, in the long run 0x200 is the most "standard", if Sun has its way. I did not realize that it was possible to control the internal precision of arithmetic operations, silly me. A lot of the debate on "Pure" java fp focuses on the (unmodifiable) 80 bit internal representation of x87 operands stored on the fp stack, but this flag apparently renders that problem moot. Oddly, Sun has been insisting that the only way to make x87 fp "Pure" is to store the result of EVERY fp operation to main memory and read it back in again. That way of course every arithmetic operation gets performed with 53b precision operands. Surely they know about this flag... no no I won't be cynical ;-) However, your comment in npx.h opines that "64-bit precision often gives bad results", and that is not true at all. More accurately, (oops, I punned:) if computing intermediate values to higher precision causes *different* final results, then in all but the mostly highly contrived cases the problem lies with the code, or in your terminology it's a bug :). (in that case the algorithm is unstable wrt precision). Not to say counterexamples don't exist but they are uncommon enough to be addressed in Kahan's SIAM talk this year. So there is an inconsistency here: on the one hand your preferences yield compatibility for buggy programs when the bug is instability of the program algorithm when subjected to (increased) intermediate precision; OTOH if the "bug" is manifested by something that generates an exception, FreeBSD by default calls it out. Java is consistent, there is one fp format and as far as fp exceptions go mask 'em all! What do I think? I don't really care that much, as long as *I* can modify that control word. And java doesn't let me do that... Regards, Russell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710032223.PAA04679>