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

Re: Unifying the two generic arithmetic alternatives

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.



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