[racket] Question about round

You wrote earlier:
Still seems weird and inconvenient for round to give you back an inexact
integer rather than an exact one
I gave my example to show that it is not weird and that in my opinion it is
convenient.. 
The absolute error of
 
(round (/ 1.0 1.1e-200)))

is of the order (expt 10 183) (with 32 bit Racket)
Although the relative error is of the order of (expt 10 -17)
it would be nonsense to classify the result as exact.
I do agree with you for the special cases.
 
Jos

 

  _____  

From: Doug Williams [mailto:m.douglas.williams at gmail.com] 
Sent: sábado, 01 de octubre de 2011 0:20
To: Jos Koot
Cc: Mark Engelberg; Stephen Bloch; users at racket-lang.org
Subject: Re: [racket] Question about round


I was only advocating it in the case of infinities. The R(5,6)RS
documentation for min/max says: "If any argument is inexact, then the result
is also inexact (unless the procedure can prove that the inaccuracy is not
large enough to affect the result, which is possible only in unusual
implementations)." I would claim that the inaccuracy in the min/max in this
case is finite and not large compared to infinity, so the result is not
affected.

I seem to remember that PLT Scheme used to handle infinities as exact
quantities. Can anyone confirm or deny that? 

Doug


On Fri, Sep 30, 2011 at 3:42 PM, Jos Koot <jos.koot at telefonica.net> wrote:



I already wrote:
 
#lang racket
(= (inexact->exact (round (/ 1.0 1.1e-200)))
 (round (/ #e1.0 #e1.1e-200))) ; -> #f
 
A computation that ends up with an integer may introduce a computational
error when during the computation inexact numbers have been used.
Inexactness should remain contaguous.
 
I do admit that (min 0 +inf.0) can retuirn an exact integer.
 
Jos
 


  _____  


From: users-bounces at racket-lang.org [mailto:users-bounces at racket-lang.org]
On Behalf Of Mark Engelberg

Sent: viernes, 30 de septiembre de 2011 18:18
To: Stephen Bloch
Cc: users at racket-lang.org
Subject: Re: [racket] Question about round


I'm amazed at how long I've gone with the misconception that:
Exact Numbers = Integers union Rationals
Inexact Numbers = Floating Point numbers
(Frankly, I never really thought much about what infinities were.  I assumed
they were a separate, distinct type).

When I saw in the docs for round that it returns an integer, and I was
getting an inexact number, I was sure it was a mistake.  Thanks for helping
me straighten out my thinking on this.  I can see how you might want to test
an inexaxct number for whether it is the floating point approximation of an
"integer", so that makes sense.  Still seems weird and inconvenient for
round to give you back an inexact integer rather than an exact one, but I
can see now how this behavior matches the standard.

Thanks,

Mark



_________________________________________________
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20111001/30c6d6f6/attachment.html>