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

*To*: hal*Subject*: another dumb question about numbers*From*: Alan Bawden <bawden@parc.xerox.com>*Date*: Thu, 2 Nov 89 17:46 PST*Cc*: rrrs-authors*In-Reply-To*: <8911022257.AA13507@zurich.ai.mit.edu>

Date: Thu, 2 Nov 89 17:57:49 est From: Hal Abelson <hal@zurich.ai.mit.edu> Why not have round, floor, ceiling, and truncate produce exact integers, and provide some other names for the analogous (more primitive?) operations that do not force exactness? Suppose you were porting your program from a Scheme that supported exact rationals to a scheme that only supported exact integers. Suppose that in the case where (/ P Q) is not an integer the latter Scheme implementation returned an inexact number (perhaps represented using floating-point). Then if FLOOR did a silent coercion, (FLOOR (/ P Q)), where P and Q are exact integers in both implementations, might return different exact integers as answers -- the correct answer in the first Scheme, and an incorrect answer in the second. Again the "silent coercion" has silently introduced a potential bug. If you -expected- an inexact quotient, then you probably should have written (INEXACT->EXACT (FLOOR (/ P Q))). I think we already had an analogous discussion about MAX and MIN.

**References**:**another dumb question about numbers***From:*hal (Hal Abelson)

- Prev by Date:
**another dumb question about numbers** - Next by Date:
**floor & inexact->exact** - Prev by thread:
**another dumb question about numbers** - Next by thread:
**another dumb question about numbers** - Index(es):