Re: Float numbers equality.

[Coda Highland <chighland@...>]

On Sun, Aug 11, 2013 at 11:51 AM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Aug 11, 2013, at 10:05 AM, Coda Highland <chighland@gmail.com> wrote:
>
>>>>
>>>>> Given that this subject comes up every couple of months, and that there
>>>>> are some subtleties to it, that this warrants a new function in the math
>>>>> library to do it the right way?
>>>>
>>>> I don't think so. Floating-point arithmetic is not simple. I think it'd be
>>>> a disservice to try to hide its complexities in a official function that
>>>> may give the impression that it solves the problem reliably, when it
>>>> can't.
>>>>
>>>
>>>
>>> In an effort to understand (not debate), where would:
>>>
>>>       return math.abs(lhs - rhs) < epsilon*rhs
>>>
>>> ...be unsuitable? Imagine that I'm dealing with float equality and it isn't
>>> working. Also imagine that I don't know very much about the issue.  I dig
>>> into the math library and find a function that does this.
>>>
>>
>> On Sun, Aug 11, 2013 at 9:03 AM, Victor Bombi <sonoro@telefonica.net> wrote:
>>> In case rhs < 0
>>
>> For the sake of having an actually productive discussion, let's assume
>> he ACTUALLY meant the bugfixed version:
>>
>> return math.abs(lhs - rhs) < math.abs(epsilon * rhs)
>>
>> The expression itself is never really WRONG (if you're paranoid you
>> might replace the < with a <= to handle underflow in the epsilon*rhs
>> term, but more on this later), but there are cases when direct
>> floating-point equality works just fine and the expression is a
>> comparatively-expensive waste of time.
>
> So I don't want to trigger another long debate (urgh), however I do want to make a couple of  observations:
>
> First, floating point equality, as everyone agrees, is a problem that naively appears simple but is actually quite subtle. Getting it right is complex (look at this debate!). Putting aside for a moment IF such a thing is possible, isn't that just the kind of thing that standard library functions ARE used for? I would classify table.concat() in the same bucket; it looks trivial, but doing an efficient concat is a subtle problem and so we have a library function to do the work.
>
> Second, isn't this a question of the target audience for Lua? While Lua is certainly a great language for professionals like myself, isn't it also (like most script languages) also designed to be more approachable for less experienced developers? That is, the ones who will hit this problem. Putting on the hat of a junior programmer, having been told I can't use equality in a naive way, my next question would be "So what DO i do then?". I think being told to "go and study numerical analysis" is a little steep (however correct it may be) … "go read up on math.compare()" or some such seems a better answer.
>
> Finally, I'm not sure about the "we can't make it work all the time, so we should not do it at all" philosophy. This seems a bit extreme; a function that works under a defined domain, as long as the domain is specified and has a wide enough applicability (say, 90% of cases), seems fine to me. After all, pretty much every library function has SOME limitations.
>
> --Tim
>
>

I'm fully in agreement with you here. "math.compare" does sound like a
really good idea, and your rationale on pointing junior devs to
useful, straightforward documentation is wise.

/s/ Adam