Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED!nerds-end From: "Jonathan Thornburg" Newsgroups: comp.compilers Subject: Re: Programming language and IDE design Date: 10 Nov 2013 04:41:55 GMT Organization: Compilers Central Lines: 59 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-11-011@comp.compilers> References: <13-10-016@comp.compilers> <13-10-017@comp.compilers> <13-11-003@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1384093131 14936 64.57.183.58 (10 Nov 2013 14:18:51 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sun, 10 Nov 2013 14:18:51 +0000 (UTC) Keywords: design, arithmetic Posted-Date: 10 Nov 2013 09:18:51 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1035 Martin Ward wrote: > (2) Absolutely no behaviour should be "implementation dependent" > or "undefined". Every syntactically valid program should have > a single semantically valid meaning (even if that meaning > is "halt with an error message"). This is really problematic in the area of floating-point arithmatic. For example, at what point should floating-point arithmetic overflow or underflow, and what should be the consequences of this happening? To be very precise, what "single semantically valid meaning" should we perscribe for trying to compute the square of 1.0e300? If we say "the answer should be 1.0e600" then we're forbidding the efficient use of hardware floating-point on machines that provide IEEE-double (for which the multiplication of 1.0e300 by itself will overflow). If we say "the answer should be a floating-point overflow" then we're forbidding the efficient use of hardware "double extended" floating-point on machines that provide extended-precision floating-point registers with a wider exponent range (so that the multiplication of 1.0e300 by itself will not overflow). And if we don't use hardware floating-point, on some codes we lose a lot of performance. Underflow presents even worse problems: Apart from the question of just where the underflow threshold should be, what happens after an underflow? Should our "single semantically valid meaning" specify gradual underflow or flush-to-zero or underflow-is-an-error? And dwarfing all of these problems are the question of what to do about trancendental (math) functions? Just what should we specify the result of cos(x) to be? Some possibilities include * specify one particular approximation (this is what Java did at first) --> blocks the use of better approximations if/when they're developed in the future * specify "the floating-point number closest to the exact result" --> is rather hard to implement; it's doable for cos(x) but pow(x,y) is still an active (not-yet-solved) research problem Java encountered all of these problems, and eventually chose to back off its "precise specification" to allow implementation-defined semantics for floating-point arithmetic. Most other languages which have or want to have substantial use for scientific computation left floating-point arithmetic machine-dependent from the start. -- -- "Jonathan Thornburg [remove -animal to reply]" Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"