Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!portc02.blue.aol.com!howland.erols.net!vixen.cso.uiuc.edu!uchinews!not-for-mail
From: Tim Pierce <twpierce+usenet@mail.bsd.uchicago.edu>
Subject: Re: inexact truncation?
X-Nntp-Posting-Host: bio-5.bsd.uchicago.edu
Message-ID: <E5u7no.GDD@midway.uchicago.edu>
Sender: news@midway.uchicago.edu (News Administrator)
X-Newsposter: Pnews 4.0-test51 (15 Jan 97)
Organization: U Chicago, Biological Sciences Division, Academic Computing
X-No-Archive: yes
References: <E5t0LK.Ix9@midway.uchicago.edu> <5edfni$m2u@emf.emf.net>
Date: Wed, 19 Feb 1997 06:35:48 GMT
Lines: 22

In article <5edfni$m2u@emf.emf.net>, Tom Lord <lord@emf.emf.net> wrote:

>[I wrote:]
>   Why are floor, truncate, ceiling and round defined to return
>   inexact results in R4RS?  Are there any circumstances in which
>   truncating or rounding a number to an integer value may result in
>   an inexact quantity?
>
>Since round returned an inexact result [to a floating-point
>computation], we know that the answer may not be mathematically
>precise: this implementation of Scheme had to use approximations
>somewhere along the way to computing x or (round x).
> ...
>If "round" returned an exact number for an inexact argument, then whenever
>we used "round" we'd loose track of the fact that our computation is just
>an approximation.  The whole reason to keep tract of exactness in the first
>place to know which results are approximations and which are precise.

This clarifies the matter considerably; thank you.

-- 
Support the Hawaii Equal Rights Marriage Project: call 1-900-97-MARRY ($5/call)
