Re: Lua 5.3: 1 Month of use

[Coda Highland <chighland@...>]

On Tue, Mar 4, 2014 at 9:38 AM, Coda Highland <chighland@gmail.com> wrote:
> On Tue, Mar 4, 2014 at 9:36 AM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>>> Please don't. :( There's no good way to do this. A
>>> round-to-nearest-integer function should be sufficient for when people
>>> have a float that needs to turn into an integer (where //1's flooring
>>> behavior would be destructive on something like (1.0/3.0) * 3.0) but
>>> trying to claim that a function is smart about knowing when a float is
>>> actually an integer... not a good idea. MATLAB tries and gets subtle
>>> errors as a result.
>>
>>   x == math.ifloor(x)    ?
>
> If ifloor rounds that's very unexpected and unobvious behavior. I'd
> expect ifloor(0.9999999) to return 0, but ifloor(1.000001) to return
> 1. Meanwhile, I would expect, say, iround(0.9999999) to return 1.
>
> /s/ Adam

Oh wait, I realize what you meant -- that's the condition to determine
whether such a normalization function "gets it right".

That's definitely SAFE... but it doesn't address FP rounding problems.
Like I said, something similar to (1.0/3.0) * 3.0 may return an
epsilon short of an integer, when if it were perfectly evaluated it
would return the integer. Calling a normalize function that checks for
exact integer identity would miss this case. This limits its
usefulness.

/s/ Adam