Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: R4RS, section 6.5.5, round
Message-ID: <hbakerCx3zM5.FKn@netcom.com>
Organization: nil
References: <19941003T142911Z.enag@gyda.ifi.uio.no>
Date: Mon, 3 Oct 1994 18:06:04 GMT
Lines: 52

In article <19941003T142911Z.enag@gyda.ifi.uio.no> Erik Naggum <enag@gyda.ifi.uio.no> writes:
>"Round returns the closest integer to _x_, rounding to even when _x_ is
>halfway between two integers."
>
>Common Lisp the Language is only slightly more specific on _round_, adding
>that "halfway between two integers" means "of the form _integer_+0.5".
>
>both point to the IEEE floating point standard as the rationale, and I must
>hasten to add that I have read this standard.
>
>several Common LISPs work as advertised.  several Schemes (including MIT
>Scheme 7.1 and 7.3, and elk) do not.  or, to be precise, integer+x, for x
>in [-0.5, +0.5) rounds to integer, as is custom in C.  there is also a
>slight anomaly between exact and inexact numbers: (round 0.5) => 1, but
>(round 1/2) => 0.
>
>two questions:
>
>(1) why was round defined to be integer+x, for x in (-0.5, +0.5) if integer
>    is odd, and integer+x, for x in [-0.5, +0.5] if integer is even?

The IEEE numerical analysts were trying for an 'unbiased' rounding
scheme.  For random physical (i.e., inexact) values expressed as
floating point numbers, this scheme should have no correlations.  For
exact numbers that happen to be represented as floating point numbers,
this scheme is probably not very good.  On the other hand, you can
always roll your own:

(defun my-round-down-with-1-result (x) (values (floor (+ x 0.5))))

>(2) why do several schemes fail to get this right?

Because most people seem to be interested in getting wrong answers
fast, rather than getting right answers.

(Translated: most Lisps convert into whatever the underlying hardware
and/or C compiler/library does, and never bother to check if this
meets the standard.)

----------

A much bigger problem, in my mind, is the senseless inefficiency which
is forced on Common Lisp implementations which do not have
_incredibly_ good compilers.  Most of these rounding functions are
defined to have 2 results, of which only rarely is the second one ever
used, and the second (modular) result can be very expensive to compute
(and often generate additional garbage through flonum and/or bignum
consing), due in part to the issues mentioned above.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.

