Re: [racket] Question about round

[Jos Koot]

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.willi...@gmail.com] 
Sent: sábado, 01 de octubre de 2011 0:20
To: Jos Koot
Cc: Mark Engelberg; Stephen Bloch; users@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  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-boun...@racket-lang.org [mailto:users-boun...@racket-lang.org]
On Behalf Of Mark Engelberg

Sent: viernes, 30 de septiembre de 2011 18:18
To: Stephen Bloch
Cc: users@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



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

Re: [racket] Question about round

[Doug Williams]

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  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-boun...@racket-lang.org [mailto:
> users-boun...@racket-lang.org] *On Behalf Of *Mark Engelberg
> *Sent:* viernes, 30 de septiembre de 2011 18:18
> *To:* Stephen Bloch
> *Cc:* users@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
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Re: [racket] Question about round

[Jos Koot]

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-boun...@racket-lang.org [mailto:users-boun...@racket-lang.org]
On Behalf Of Mark Engelberg
Sent: viernes, 30 de septiembre de 2011 18:18
To: Stephen Bloch
Cc: users@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

Re: [racket] Question about round

[Stephen Bloch]

On Sep 30, 2011, at 12:31 PM, Robby Findler wrote:

> Just to clear up one more possible point: the rational? predicate
> actually recognizes inexact numbers, eg:
> 
> [robby@penghu] ~/git/plt/collects/drracket/private$ racket
> Welcome to Racket v5.1.3.9.
>> (rational? (sqrt 2))
> #t

Interesting.  I hadn't thought of that.  Technically, the floating-point 
approximation to (sqrt 2) is in fact a rational number...

I guess one could say that "rational?" returns false for anything represented 
in floating point.  Which would lead to the odd paradox of some integers not 
being rational.



The underlying question, it seems to me, is how closely we want to tie the 
numeric predicates to internal machine representations.

In C/C++/Java, there are two kinds of numbers (ignoring precision): exact ints 
and inexact floats.  The different types in the language correspond exactly to 
different binary representations.

In Racket, as I understand it, integerhood and exactness are orthogonal: you 
can have either one with or without the other.  I assume that all inexact 
numbers (integer or not) are represented in floating-point, but don't know how 
closely exact numbers are tied to a particular binary representation.


Stephen Bloch
sbl...@adelphi.edu


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

Re: [racket] Question about round

[Robby Findler]

Just to clear up one more possible point: the rational? predicate
actually recognizes inexact numbers, eg:

[robby@penghu] ~/git/plt/collects/drracket/private$ racket
Welcome to Racket v5.1.3.9.
> (rational? (sqrt 2))
#t

Robby

On Fri, Sep 30, 2011 at 11:18 AM, Mark Engelberg
 wrote:
> 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
>

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

Re: [racket] Question about round

[Mark Engelberg]

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

Re: [racket] Question about round

[Vincent St-Amour]

At Fri, 30 Sep 2011 09:25:50 -0400,
Eli Barzilay wrote:
> > Could we get an exception to the coercions in the case of +/-inf.0?
> > Or an alternative min/max that don't do it?
> 
> My guess is that changes in this area are hopeless, since they'll
> break a bunch of code in unexpected ways.  (Not to mention the TR
> guys, they might get out from such a change with a PTSD.)

That change wouldn't be much of a problem for us. TR would have to be
conservative when comparing exact integers with infinities, but it
wouldn't be any worse than it is now. Or we could have singleton types
for the infinities, which would take some work and are unlikely to be
useful in a lot of other cases.

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

Re: [racket] Question about round

[Noel Welsh]

Agreed in general, but I think we want an exact positive and negative
infinity, not more confusion to the coercion rules.  Ironically R6RS
includes max and min integers (at least I have a vague memory of such
an addition) which will do the job.

N.

On Fri, Sep 30, 2011 at 2:16 PM, Doug Williams
 wrote:
> Another such annoyance is than (min 1 +inf.0) => 1.0 - because if any
> argument is inexact, the result is inexact. I don't think this makes sense
> in the case of infinities. Infinities are very useful as initial values for
> things that are being minimized or maximized, but there is always the need
> for inexact->exact to protect against the (unexpected) coercion.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Re: [racket] Question about round

[Eli Barzilay]

A few minutes ago, Doug Williams wrote:
> Another such annoyance is than (min 1 +inf.0) => 1.0 - because if
> any argument is inexact, the result is inexact. I don't think this
> makes sense in the case of infinities. Infinities are very useful as
> initial values for things that are being minimized or maximized, but
> there is always the need for inexact->exact to protect against the
> (unexpected) coercion.

I agree with that (although less frequent than the previous one), but
the problem is that `exact-min' is no longer a good name for it...


> This is all from the original R5RS and continued in R6RS - but, we
> aren't that language.
> 
> Could we get an exception to the coercions in the case of +/-inf.0?
> Or an alternative min/max that don't do it?

My guess is that changes in this area are hopeless, since they'll
break a bunch of code in unexpected ways.  (Not to mention the TR
guys, they might get out from such a change with a PTSD.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Re: [racket] Question about round

[Doug Williams]

Another such annoyance is than (min 1 +inf.0) => 1.0 - because if any
argument is inexact, the result is inexact. I don't think this makes sense
in the case of infinities. Infinities are very useful as initial values for
things that are being minimized or maximized, but there is always the need
for inexact->exact to protect against the (unexpected) coercion.

This is all from the original R5RS and continued in R6RS - but, we aren't
that language.

Could we get an exception to the coercions in the case of +/-inf.0? Or an
alternative min/max that don't do it?

On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen wrote:

>
> exact-round is preferred.
>
>
>
> On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote:
>
> > Yesterday, Ryan Culpepper wrote:
> >> The pragmatic answer is you generally have to write
> >>
> >>   (inexact->exact (round x))
> >>
> >> which is annoying, but no one has yet bothered to add a standard
> >> library function for this, as far as I know.
> >
> > [From the annoyed side, especially since that thing tends to come in
> > bunches which can make some quick code look much heavier than it is:]
> >
> > Maybe it's time to add something for that?  `eround'?  (But even
> > `exact-round' would be better than the above.)
> >
> > --
> >  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> >http://barzilay.org/   Maze is Life!
> > _
> >  For list-related administrative tasks:
> >  http://lists.racket-lang.org/listinfo/users
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Re: [racket] Question about round

[Matthias Felleisen]

exact-round is preferred. 



On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote:

> Yesterday, Ryan Culpepper wrote:
>> The pragmatic answer is you generally have to write
>> 
>>   (inexact->exact (round x))
>> 
>> which is annoying, but no one has yet bothered to add a standard
>> library function for this, as far as I know.
> 
> [From the annoyed side, especially since that thing tends to come in
> bunches which can make some quick code look much heavier than it is:]
> 
> Maybe it's time to add something for that?  `eround'?  (But even
> `exact-round' would be better than the above.)
> 
> -- 
>  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
>http://barzilay.org/   Maze is Life!
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users

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

Re: [racket] Question about round

[Eli Barzilay]

Yesterday, Ryan Culpepper wrote:
> The pragmatic answer is you generally have to write
> 
>(inexact->exact (round x))
> 
> which is annoying, but no one has yet bothered to add a standard
> library function for this, as far as I know.

[From the annoyed side, especially since that thing tends to come in
bunches which can make some quick code look much heavier than it is:]

Maybe it's time to add something for that?  `eround'?  (But even
`exact-round' would be better than the above.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Re: [racket] Question about round

[Jos Koot]

See section 3.1 and 3.2 of the R6RS (http://www.r6rs.org/
 ).
Also see section 3.2 of the Racket Reference.
 
An integer result can be inexact. Consider a result whose absolute error is
greater than 1. Than rounding it gives an inexact result. For example:
 
#lang racket
(= (inexact->exact (round (/ 1.0 1.1e-200)))
   (round (/ #e1.0 #e1.1e-200))) ; -> #f
 
Jos
 



From: users-boun...@racket-lang.org [mailto:users-boun...@racket-lang.org]
On Behalf Of Mark Engelberg
Sent: jueves, 29 de septiembre de 2011 23:11
To: users@racket-lang.org
Subject: [racket] Question about round


I'm a bit baffled by this behavior:

> (exact? (round (sin 30)))
#f
> (integer? (round (sin 30)))
#t
> 

How is it possible to have an inexact integer?

I would expect the answer to both of these tests to be true.

Thanks,

Mark


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

Re: [racket] Question about round

[Stephen Bloch]

On Sep 29, 2011, at 5:11 PM, Mark Engelberg wrote:

> How is it possible to have an inexact integer?

That threw me, too, the first time I encountered it.

Where do inexact numbers come from?  Two common sources: physical measurement, 
and computations whose exact results can't be represented in any of the 
standard numeric formats.  So for example the location of the mouse is a 
physical measurement, and therefore inherently inexact.  However, it's measured 
in pixels, so it's an integer (or rather a pair of integers).

Now, how about an inexact computation whose result, to within rounding error, 
is an integer?

(define x #i1.001)
x ; not 1
(sqrt x) ; #i1.0004
(sqrt (sqrt x)) ; #i1.0002
(sqrt (sqrt (sqrt x))) ; #i1.0

But mathematically, the answer shouldn't be 1 because it's the square root of 
something that wasn't 1, so the "inexact" marker is correct.


Stephen Bloch
sbl...@adelphi.edu


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

Re: [racket] Question about round

[Ryan Culpepper]

On 09/29/2011 03:11 PM, Mark Engelberg wrote:

I'm a bit baffled by this behavior:

 > (exact? (round (sin 30)))
#f
 > (integer? (round (sin 30)))
#t
 >

How is it possible to have an inexact integer?


> (inexact? 1.0)
#t

The interpretation of "inexact" is subtle and contentious. But to a 
first approximation, "inexact" just means "floating-point".


To a second approximation, I interpret

  (integer? 1.0) = #t
  (inexact? 1.0) = #t

as "the representation is definitely an integer, but it may not exactly 
represent the quantity you really wanted to talk about". But I haven't 
studied this carefully, and it is possible that my interpretation is 
horribly wrong according to someone.


The pragmatic answer is you generally have to write

  (inexact->exact (round x))

which is annoying, but no one has yet bothered to add a standard library 
function for this, as far as I know.


Note also that round does not necessarily return an integer:

> (round +inf.0)
+inf.0

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

Re: [racket] Question about round

[Pierpaolo Bernardi]

#i42 is an inexact integer, there's noting notable about them.

43.0 is another one.

Cheers


2011/9/29, Mark Engelberg :
> I'm a bit baffled by this behavior:
>
>> (exact? (round (sin 30)))
> #f
>> (integer? (round (sin 30)))
> #t
>>
>
> How is it possible to have an inexact integer?
>
> I would expect the answer to both of these tests to be true.
>
> Thanks,
>
> Mark
>

-- 
Inviato dal mio dispositivo mobile
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users