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.
