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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*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):