lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




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