This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
On Sun, 7 Aug 2005, Paul Schlie wrote: > I pre-apologize if this is a dumb question, but as it seems that > exact values are only interesting for integer ratios, which > correspondingly seem reasonable to expect to have some practical > limited representational precision, therefore also imply the > necessity to depict an over/underflowed value (i.e. +/- infinity and > reciprocals); why is it perceived as necessary and/or appropriate to > presume it's the responsibility of the programmer to limit computed > values to reasonable precision rational values as opposed to > possibly more simply defining that exacts are merely only more exact > than inexacts to some definable precision? As beyond academic > definition of exact, pretending that an arbitrary exact > implementation supports infinitely exact computations seems both > naive and impractical? Well, exact answers are just that -- exact. That's all it means, really; the computer is telling you whether this number is *exactly* right, not making any statements about how it's represented. If it wasn't able to produce an exact answer due to the numeric representation being limited to some particular precision where the exact answer requires more precision to express, then usually I want at least an inexact answer. It is not unreasonable for an implementation to limit the dynamic range or precision of its numbers. If the implementation has, then rather than return an exact number outside the dynamic range, we must either report a violation of an implementation restriction, or return an inexact number within the dynamic range. If the implementation has not imposed such a limit, then inevitably the hardware does anyway. In that case we must either return an inexact number, or report an out of memory error. Typically the dynamic range or precision of inexact numbers is much less than that of exact numbers. But how much less and in what ways is an interesting question in dialect design. My own opinion is that for consistent mathematics, exact and inexact numbers should have similar dynamic ranges - meaning more limited "exact" representations than most implementors use and greatly extended "inexact" representations of about the same size as the "exact" representations. But most people feel that "inexact" should be a codeword for "Hardware-supported floating-point format," and for some calculations and applications, that's actually better. There's a lot of room for interpretation in this part of the standard. There's also a lot of room for extensions and variations in behavior. It's hard to say what is "The Right Thing," really - and it frequently depends on your particular application. Bear