On 29-mar-10, at 10:29, Don wrote:
Walter Bright wrote:
Don wrote:
(1) Converting a floating point literal into a double literal is
usually not lossless.
0.5f, 0.5, and 0.5L are all exactly the same number, since they
are exactly representable.
But 0.1 is not the same as 0.1L.
It depends. The D compiler internally stores all floating point
constants, regardless of type, in full 80 bit precision. Constant
folding and CTFE are all carried out in 80 bit precision regardless
of type. The only time it is actually truncated to the shorter
formats is when writing it out to the object file.
The central idea is that more precision == better. If your floating
point algorithm breaks if precision increases, then the algorithm
is a bad one.
The only time I've seen code that relied on roundoff errors is in
test suites that specifically tested for it.
There's some oddities.
//enum A = 1.0e400; // Error: number is not representable
enum B = 1.0e200 * 1e200; // yes it is!
enum C = 1.0e400L;
static assert(B==C);
So there's a bit of schizophrenia about whether the 'L' suffix
changes which values are representable, or whether it is just a type
marker.
I think we should tighten things up a little bit, but I don't think
it's a big deal.
good to have the numerics expert look into this.
Yes I think the situation is really quite ok, for example (now having
some doubts) I just checked (to be sure the correct thing would
happens as I thought) and
T mult1(T)(T x){
return 1.000000000000000001*x;
}
assert(mult1(1.0f)==1.0f,"float");
assert(mult1(1.0)==1.0,"double");
assert(mult1(1.0L)==1.0L*1.000000000000000001L,"real");
:)
