Always false float comparisons

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Thu May 19 23:12:44 PDT 2016


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, on any compiler, language 
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++.

The people who design these things are not fools, and there are good reasons for 
the way things are.

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. If there are spots in the program that require 
rounding, what is wrong with having to specify it? Why compromise speed & 
accuracy in the rest of the code that does not require it? (And yes, rounding in 
certain spots can and does compromise both speed and accuracy.)


> 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. I've also seen many that failed due to 
premature rounding.


> 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!). 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.)


More information about the Digitalmars-d mailing list