Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 20.05.2016 08:12, Walter Bright wrote:
> On 5/19/2016 1:26 PM, Timon Gehr wrote:
>> Those two lines producing different results is unexpected, because you
>> are
>> explicitly saying that y is a double, and the first line also does
>> implicit
>> rounding (probably -- on all compilers and targets that will be
>> relevant in the
>> near future -- to double).
>  > [...]
>> It's obviously bad language design on multiple levels.
>
> Floating point semantics simply are not that simple,

This is about how the language defines floating point semantics. They 
can be that simple if the specification says so.

> on any compiler,

gdc/ldc seem to get it right. David, Iain, is this the case?

> language

Anybody can invent a language and IEEE 754 semantics are possible to 
support. Recent hardware does it.

> or hardware. I recommend reading what the C/C++ Standards say
> about it, and look at the plethora of compiler switches for
> VC++/g++/clang++.
> ...

I don't really need to look at examples of how to do it wrong, but I 
will read whatever relevant link you can give me carefully. In D you 
don't need compiler switches to change the semantics of your code. We 
have more or less sane conditional compilation.

> The people who design these things are not fools,

I don't know those people, but I would like to know their thoughts about 
the current discussion.

> and there are good reasons for the way things are.
> ...

It is not unusual that there is some good reason for a design mistake.

> Sorry, I don't agree.
>
>> If you say so. I would like to see an example that demonstrates that
>> the first
>> roundToDouble is required.
>
> That's beside the point.

Absolutely not.

> If there are spots in the program that require
> rounding, what is wrong with having to specify it?

I explained what is wrong with it.

What is wrong with having to specify the precision that is /required for 
your code to run correctly/?

> Why compromise speed & accuracy in the rest of the code

You don't compromise speed or accuracy if the rest of the code just 
correctly specifies the precision it should be run at.

> that does not require it? (And yes,
> rounding in certain spots can and does compromise both speed and accuracy.)
> ...

Because it is the only sane thing to do, as explained from many 
different angles in this thread. If it does compromise accuracy, that 
means the code is bad (it relies on precision enhancements that are not 
guaranteed to happen, hence it is hardly correct).

>
>> And if you are not? (I find the standard assumption that
>> counterexamples to
>> wrong statements are one-off special cases tiresome.
>
> You might, but I've implemented a number of FP algorithms, and none of
> them required rounding to a lower precision.

double x=..., z=...;
double y=roundToDouble(x+z);

Lower than what precision? It is not a 'lower' precision, it is the 
precision that was specified.

> I've also seen many that
> failed due to premature rounding.
> ...

Yes. Your results might be garbage more often if you run at too low 
precision. I and everyone else are very aware of this. I am not arguing 
against any of this. There seems to be a total communication failure here.

>
>> Creating useful programs in D shouldn't require knowing (or thinking
>> about) an
>> excess amount of D-specific implicit arcane details of the language
>> semantics.
>> Being easy to pick up and use is a major selling point for D.
>
> As pointed out innumerable times here, the same issues are in C and C++
> (with even more variability!).

As also pointed out here, it does not matter. I'm *not* trying to make 
the point that C and C++ do it better or anything like that. (But well, 
in practice, the actual commonly used C and C++ implementations probably 
do get it right by default.)


> When designing an algorithm that you know
> requires rounding in a certain place, you are already significantly
> beyond implementing a naive algorithm, and it would be time to start
> paying attention to how FP actually works.
>
> I'm curious if you know of any language that meets your requirements.
> (Java 1.0 did, but Sun was forced to abandon that.)

x86_64 assembly language.