float equality

[spir]

On 02/21/2011 10:17 PM, so wrote:
>>> If one doesn't know what floating point is and insists on using it, it is
>>> his own responsibility to face the consequences.
>>
>> I don't buy this argument.
>
> Why not? A logical flaw on my part or the statement being somewhat harsh?
> Because i don't think it is the former, i will give an example for the latter.
> I am a self-taught programmer and i too made big mistakes when using FP,
> probably i still do since it is a strange beast to deal with even if you know
> all about it.
> For this reason it is somewhat understandable for people like me failing this
> kind of traps but can we say same thing for others?
> Do they have this excuse? Not knowing the fundamental thing about FP and use it?

I understand your position. But I don't share it.
The problem is binary floating point representations of numbers introduce a 
little set of traps due to the fact that they are implicitely supposed to be 
the type representing "fractional" or real numbers, but they cannot do that in 
a way that matches our (widely unconscious) intuitions in the domain, 
themselves (I guess) a by-product of years of manipulation at school. The 
simple notation "1.1" comes with a huge baggage of pre-existing knowledge by 
everyone (programmers).

We should not blindly make abstraction of that fact, and put the burden on the 
users' shoulders, without even a honest trial in solving the issue.
When a programmer writes:
	x = 1.1;
or
	x = 1/3.0;
the meaning is just that, and refers to all this knowledge. There is in most 
cases no intention (not even implicite) to use binary floating point numbers, 
instead to have a representation for the plain arithmetics values as written 
down. Hope I'm clear. Very few people (ones that have repetedly been caught by 
the conceptual traps) will have "alarm bell" ring when writing this, and 
consequently take all appropriate precautions required to avoid subsequenty 
falling into the traps and... have buggy code.

This may be a bit different if the notation did not recall all of that knowledge:
	x = 1.1f; // alarm bell!?

I would advocate that a general-purpose language should use a different 
representation for ordinary need of fractional/real numbers, one that does not 
introduce such traps and/or warns about them (via warnongs/errors, like 
Bearophile's proposal). One possibility may be to use fixed point with a 
/decimal/ scale factor (the mantissa beeing binary or decimal integer). Other 
possibilities: true rationals, decimal 'reals'.
The issue is indeed any of those solutions has a cost (even more with modern 
machines having native float artithmetic). But numeric computation intensive 
apps would just use floats, /explicitely/ (and hopefully correctly).

A similar issue is the one of signed <--> unsigned ints. I would just make as 
default the range of unsigned ints be a subset of signed ones. And let the full 
range available for people who really need it, to be used explicitely.

Anyway, such solutions may not be good for D, beeing (also) a systems 
programming language in the C line. Still, I think it's worth exploring the 
topic instead of letting bug-prone features silently sit at the deep core of 
the language.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com