Always false float comparisons

[H. S. Teoh via Digitalmars-d]

On Mon, May 16, 2016 at 05:37:58AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/16/2016 3:27 AM, Andrei Alexandrescu wrote:
[...]
> >I think it's time to revisit our attitudes to floating point, which
> >was formed last century in the heydays of x87. My perception is the
> >world has moved to SSE and 32- and 64-bit float; the "real" type is a
> >distraction for D; the whole let's do things in 128-bit during
> >compilation is a time waster; and many of the original things we want
> >to do with floating point are different without a distinction, and a
> >further waste of our resources.
> 
> Some counter points:
> 
> 1. Go uses 256 bit soft float for constant folding.
> 
> 2. Speed is hardly the only criterion. Quickly getting the wrong
> answer (and not just a few bits off, but total loss of precision) is
> of no value.

An algorithm that uses 80-bit but isn't written properly to account for
FP total precision loss will also produce wrong results, just like an
algorithm that uses 64-bit and isn't written to account for FP total
precision loss.


[...]
> 5. Other languages not supporting it means D has a capability they
> don't have. My experience with selling products is that if you have an
> exclusive feature that a particular customer needs, it's a slam dunk
> sale.

It's also the case that maintaining a product with feature X that nobody
uses is an unnecessary drain on developmental resources.


> 6. My other experience with feature sets is if you drop things that
> make your product different, and concentrate on matching feature
> checklists with Major Brand X, customers go with Major Brand X.
[...]

If I were presented with product A having an archaic feature X that
works slowly and that I don't even need in the first place, vs. product
B having exactly the feature set I need without the baggage of archaic
feature X, I'd go with product B.


T

-- 
Real Programmers use "cat > a.out".