On 6 November 2013 09:09, Don <x...@nospam.com> wrote: > 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. > > > The only tests that break in GDC because GCC operates on 160 bit intermediate values are the 80-bit specific tests (the unittest in std.math with the comment "Note that these are only valid for 80-bit reals").
Saying that though, GCC isn't exactly IEEE 754 compliant either... > 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. > double y = cast(float) x; ? :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
