With x87 reals available, this unittest passes, although it shouldn't:
```
float f(float a)
{
return 100*a;
}
unittest
{
enum f1 = float.max;
pragma(msg, f(f1)); // 3.40282e+40F (>float.max)
pragma(msg, typeof(f(f1)).stringof); // float
// at least one of these three asserts should fail,
// IMHO the last one
static assert(is (typeof(f(f1)) == float));
static assert(f(f1) > float.max);
static assert(f(f1) != float.infinity);
}
```
The same is true for doubles.
Comment #1 by razvan.nitu1305 — 2021-03-08T10:50:49Z
Shouldn't the second assert fail? My expectation would be that `float.max * 100` causes an overflow and therefore the value is trimmed to the size of `float` which is a value smaller than `float.max`. Or do we guarantee that in case of an overflow, float.infinity is seated in the variable?
Comment #2 by bugzilla — 2021-03-08T10:55:27Z
When not in CTFE, float.max * 100 leads to float.infinity (as it should in my opinion). So I expect CTFE to behave the same way. Also reals in CTFE behave that way.
Comment #3 by kinke — 2021-03-08T12:53:31Z
This is a consequence of CTFE not operating with float or doubles at all - all floating-point values are `real_t` types at compile-time, which corresponds to `real` for DMD, but not with LDC and GDC. So something like this can happen with `real` as well, and CTFE calculations likely yield a different result than runtime computations, not just for float and double.
Comment #4 by ibuclaw — 2021-03-08T13:03:45Z
I think this is a duplicate of issue 9937.
Comment #5 by bugzilla — 2021-03-08T19:18:31Z
(In reply to Iain Buclaw from comment #4)
> I think this is a duplicate of issue 9937.
Yes, maybe.
In my opinion, the whole idea of a) having different reals and b) using them internally for better precision is questionable. It sounds good in theory; in practice (with a little bit of exaggeration) the results can be used as seeds in random number generators... ;-)
Not to get me wrong: Each of these two ideas might be useful on its own (*) - it's the combination of the two, that produces headaches. At least, I wish there were a possibility for the programmer to decide if reals should be used for calculation or not.
But probably, this discussion is beyond this bug report...
(*) If only a) is present, the programmer can decide, not to use reals. If only b) is present, the result of computations is still predictable (in a certain range, like usual with floating points).
Comment #6 by robert.schadek — 2024-12-13T19:14:59Z