Re: Float numbers equality.

[Andrew Starks <andrew.starks@...>]

On Sunday, August 11, 2013, Lorenzo Donati  wrote:
> On 11/08/2013 20.51, Tim Hill wrote:
> > 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.
>
> The problem here is not of efficiency, but of correctness. You really
> can't have a one-size-fits-all function which is correct in 90% of
> simple cases. Numerical analysis *is hard* (theoretically, I mean) and
> when mixed with FP numbers it's more so.
>
> I've lost most memories about my university NA course, but IIRC (please
> some mathematician to the rescue :-) I dare say that for any trivial
> equality function you can devise, there are trivial cases that can make
> it fail (although it might require a clever guy to discover them).
>
> As Dirk said in another post, without deep knowledge of the computation
> at hand you cannot *guarantee* that a given equality function will be
> correct.
>
> It's not a matter of agreement on some limits (say precision, accuracy,
> domain, etc.), you cannot know the limits *in general*!
>
> >
> > 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.
> >
> I agree that user friendliness is not to be undervalued, but a trivial
> "general" equality function is a three liner, as others have posted. But
> including it in the std library would be smoke in the eyes. As Luiz
> said, you would give a false sense of security to newbies, and all other
> people having better understanding of the issue will never use it,
> adding bloat to the libraries.
>
>
> > 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.
>
> see above and [1]. Sadly (IMHO) there is no such thing as "wide enough
> applicability" when it comes to FP.
>
> Of course I will highly value good pointers and references to easy
> tutorials that explains how FP work. Admittedly the Goldman paper is
> tough reading for most undergraduates. I myself never quite understood
> it in the details, but at least it gave me a sound sense of paranoia
> (pun intended :-)
> that reemerges every time I have to do non-toy algorithms involving many
> FP calculations!
>
> @Andrew too:
>
> The bottom ground is that the newbie may have false expectations: when a
> novice dev approaches FP numbers his mental model is probably that of
> real numbers, whereas FP numbers are a far nastier beast.
>
> The problem lies, IMHO, also in the fact that when you use integers on a
> computer they seem to work like true (math) integers, beside some
> "quirks" (e.g. overflows) that you rarely see when you just "play" with
> them, as most newbies do.
>
> So it is easy for a newbie to apply the same approach to FP numbers
> (again - false expectations), and be very puzzled when simple operations
> lead to funny results (how would you explain to a newbie why 1.0 + 1e-15
> result *could* be equal to 1.0 without talking about the gory details of
> FP at least a little?)
>
>
> >
> > --Tim
> >
> >
> >
>
> Cheers!
>
> -- Lorenzo
>
>
> [1] Just an interesting anecdote: this year as a teacher I had to hold a
> basic C++ course for teenagers in high school (age 15-18). I had a
> student whose father is a former professional programmer and helped her
> daughter with the home assignments. To cut a long story short, this was
> more or less the program:
>
> #include <iostream>
> int main()
> {
>         for ( double x = 0.0; x < 1.0; x += 0.1 )
>                 std::cout << x << "\n";
>         return 0;
> }
>
> and the output:
>
> 0
> 0.1
> 0.2
> 0.3
> 0.4
> 0.5
> 0.6
> 0.7
> 0.8
> 0.9
> 1
>
> Why the last 1 has been printed?!? The father asked me during office
> hours whether the compiler I gave the students maybe was defective :-) .
>
> Not even the inequalities are "foolproof" when you work with FP!
> You must know something of FP arithmetic if you require some degree of
> correctness, no magic math.compare will save the newbies' day!
>
>
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments

This thread was increadibly helpful. Hall of fame quality. 

If I may summarize the essence while polluting it with my own conjecture:

Any library function offered would be used exclusively by people too inexperienced to know that they can't solve their problem through an abstraction provided by an opaque library. 

Hard things are hard and you're better off understanding the underlying issues.

This thread would serve as good prose for the wiki. 

-Andrew