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