[Issue 9937] CTFE floats don't overflow correctly

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9937



--- Comment #13 from Don <clugdbug at yahoo.com.au> 2013-04-25 08:07:33 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> 
> > This is about making compile-time behave the same as runtime.
> 
> Floating point answers can (and do) vary depending on optimization settings.
> This is true for C and C++ compilers, too, even though the arithmetic is
> Standard compliant.

Sure, but in practice the semantics are predictable. It's not "all bets are
off". The reality is, x87, 68K and Itanium may do intermediate operations at 80
bit precision, some embedded systems use alias float = double
and all other systems use the precision of the largest operands.

There are only these three possibilities to worry about. And there will never
be any more. All new systems will use the precision of the largest operands.

That's completely different from "the semantics are not even consistent during
compilation of a single module".

> > Specifically:
> > 1. A manifest constant should not be carrying extra precision. That's simply
> > incorrect.
> 
> This is an assertion that earlier I would have accepted without question. I
> question it now.

If you can have a floating point constant that's between float.max and
float.infinity, it's not an IEEE value. That sucks.

> > 2. JIT compilation onto the target machine should be valid for CTFE.
> 
> I agree.
> 
> > 3. The results of CTFE should be as reproducible as runtime results are.
> 
> The definition should provide a minimum precision, not a maximum. As long as
> the runtime results comply with a minimum precision, they are D standard
> compliant.
> 
> I feel kinda strongly about this.

So do I. I think it is completely wrong.
The D spec also says that you can assume IEEE behaviour. If extra arbitrary
precision is possible, it is not IEEE. It's back to the bad old days.
Basically it makes ALL floating point operations into implementation-defined
behaviour!

> (Note that Go uses infinite precision for all integer constant folding. I think
> that is superior to what D does, which limits the precision to the target
> integer size.)

I think infinite precision is a big mistake. When CTFE becomes capable of
running BigInt, it can be used in those rare cases when it's actually required.

> My earlier proposal to provide functions roundToFloat and roundToDouble at
> least provide solid documentation at points in an algorithm where precision
> ceilings are required.

That would be a useful guarantee. That would be enough to deal with my original
test case.
It does not deal with the second one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------