[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>*Subject*: Re: Unifying the two generic arithmetic alternatives*From*: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>*Date*: Mon, 14 Nov 2005 20:44:10 -0700*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051115001633.49A59600037@xxxxxxxxxxxxxxxxxxxxxxx>*References*: <20051115001633.49A59600037@xxxxxxxxxxxxxxxxxxxxxxx>*User-agent*: Mutt/1.4.2.1i

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 jcowan@xxxxxxxxxxxxxxxxx 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

**References**:**Unifying the two generic arithmetic alternatives***From:*Andrew Wilcox

- Prev by Date:
**Re: Unifying the two generic arithmetic alternatives** - Next by Date:
**Re: Unifying the two generic arithmetic alternatives** - Previous by thread:
**Re: Unifying the two generic arithmetic alternatives** - Next by thread:
**Re: Unifying the two generic arithmetic alternatives** - Index(es):