[racket-dev] [racket] Question about round

From: Vincent St-Amour (stamourv at ccs.neu.edu)
Date: Fri Sep 30 14:14:09 EDT 2011

I will implement the change locally, and see what a DrDr house call
reports.

If that sounds promising, I'll check PLaneT packages too.

(On a side note, house calls are great! It would be nice to have
something like that for PLaneT too. Something like: download all the
packages, make sure they build, and if they have tests, make run
them. That would be useful any time someone makes a
backwards-incompatible change.)

Vincent


At Fri, 30 Sep 2011 10:20:36 -0600,
Matthew Flatt wrote:
> 
> I think this is a good change for the next language, but not for `#lang
> racket'.
> 
> As confusing as the current `integer?' may be, I think its definition
> is deeply wired into our code, tests, and documentation. I may guess
> wrong, but my best estimate of the hassle for this change is that it's
> too much trouble for too little payoff, and we could spend our energy
> on more interesting things.
> 
> At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote:
> > On a more general note, do we really need inexact integers?
> > 
> > The behavior of `integer?' is confusing, and I don't see especially
> > compelling reasons to keep it this way. The subject comes up every
> > couple of months on the mailing list, so we should do something about it.
> > 
> > Here's a proposal:
> > `integer?' becomes the same as `exact-integer?' (which is kept for
> > backwards compatibility).
> > `positive-integer?' and `nonnegative-integer?' are added as
> > equivalents to their `exact' counterparts.
> > `inexact-integer?' is added, to cover for the use case of checking is
> > an inexact number has been rounded.
> > 
> > I volunteer to implement this if we agree that this is the right
> > thing.
> > 
> > Vincent
> > 
> > 
> > 
> > At Fri, 30 Sep 2011 07:16:22 -0600,
> > 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.
> > > 
> > > 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 
> > <matthias at ccs.neu.edu>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/dev


Posted on the dev mailing list.