https://issues.dlang.org/show_bug.cgi?id=21688

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
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?

--

https://issues.dlang.org/show_bug.cgi?id=21688

--- Comment #2 from Berni44 <bugzilla@bernis-buecher.de> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=21688

kinke <kinke@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #3 from kinke <kinke@gmx.net> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=21688

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I think this is a duplicate of issue 9937.

--

https://issues.dlang.org/show_bug.cgi?id=21688

--- Comment #5 from Berni44 <bugzilla@bernis-buecher.de> ---
(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).

--

https://issues.dlang.org/show_bug.cgi?id=21688

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=21688

--- Comment #6 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/19880

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--