Andrew Wilcox scripsit:

> Note that a floating point number (aside from INF and NaN) represents
> one and precisely one rational number.  Thus to perform an accurate
> calculation with a flonum, we simply use its actual value.

In fact not.  When you add 1.0 to MAX_SAFE_INT_FLONUM (the smallest flonum
whose successor is not representable as a flonum, 2^53 for IEEE 64-bit floats),
the result of flonum addition interpreted as a rational number is *not*
accurate.

> FAST+ always performs a fast (if perhaps inaccurate) operation --
> returning a flonum, or a complex number made up of flonums.

Why a flonum?  Addition of two fixnums with no overflow should be able to
return a fixnum, no?

> Thus I propose that support for EXACT?, INEXACT? and contagious
> inexactness be optional in R6RS.

Sounds to me like a very specialized feature that should be supported outside
the core if at all.

> ACCURATE+ isn't *required* to make any conversions in the types of its
> arguments in the way that Generic Exact Arithmetic converts all
> arguments to "exact" representations.

It's not required, but it's very hard to avoid it.

--
John Cowan      http://www.ccil.org/~cowan      xxxxxx@reutershealth.com
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath