Question/request/bug(?) re. floating-point in dmd

[Don]

On Wednesday, 6 November 2013 at 06:28:59 UTC, Walter Bright 
wrote:
> On 11/5/2013 8:19 AM, Don wrote:
>> On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright 
>> wrote:
>>> Not exactly what I meant - I mean the algorithm should be 
>>> designed so that
>>> extra precision does not break it.
>>
>> Unfortunately, that's considerably more difficult than writing 
>> an algorithm for
>> a known precision.
>> And it is impossible in any case where you need full machine 
>> precision (which
>> applies to practically all library code, and most of my work).
>
> I have a hard time buying this. For example, when I wrote 
> matrix inversion code, more precision was always gave more 
> accurate results.

With matrix inversion you're normally far from full machine 
precision. If half the bits are correct, you're doing very well.

The situations I'm referring to, are the ones where the result is 
correctly rounded, when no extra precision is present. If you 
then go and add extra precision to some or all of the 
intermediate results, the results will no longer be correctly 
rounded.

eg, the simplest case is rounding to integer:
3.499999999999999999999999999
must round to 3. If you round it twice, you'll get 4.

But we can test this. I predict that adding some extra bits to 
the internal calculations in CTFE (to make it have eg 128 bit 
intermediate values instead of 80), will cause Phobos math unit 
tests to break.
Perhaps this can already be done trivially in GCC.

>> A compiler intrinsic, which generates no code (simply 
>> inserting a barrier for
>> the optimiser) sounds like the correct approach.
>>
>> Coming up for a name for this operation is difficult.
>
> float toFloatPrecision(real arg) ?

Meh. That's wordy and looks like a rounding operation. I'm 
interested in the operation float -> float and double -> double 
(and perhaps real->real), where no conversion is happening, and 
on most architectures it will be a no-op.

It should be a name that indicates that it's not generating any 
code,
you're just forbidding the compiler from doing funky weird stuff.

And for generic code, the name should be the same for float, 
double, and real.

Perhaps an attribute rather than a function call.

double x;
double y = x.strictfloat;
double y = x.strictprecision;

ie, (expr).strictfloat  would return expr, discarding any extra 
precision.
That's the best I've come up with so far.