[racket-dev] [racket] Question about round

I sent this to Matthew privately but I think we need to be
much more careful with 'interesting'. While you are right 
about the 'wired into our code' part, I think the two of 
you are wrong about the 'interesting' part. 

>From a type perspective, the numeric tower comes with major
flaws and it would be wonderful if a language that divorces
itself from the old flawed Scheme world could make a clean
cut and do better. 

But I am also the person who preaches 'the path from here to
there' and agree that the 'wired' argument for the existing
code base and outside consumers tells us that Racket isn't 
the language that can fix these mistakes. 




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

> This is my opinion, too.
> 
> Robby
> 
> On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt <mflatt at cs.utah.edu> 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
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>> 
> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev