On 16 May 2016 at 12:56, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/15/2016 7:04 PM, Manu via Digitalmars-d wrote: >>> >>> I understand there are some cases where this is needed, I've proposed >>> intrinsics for that. >> >> Intrinsics for... what? > > > float roundToFloat(float f); > > >> I really don't want to use an intrinsic to have float behave like a >> float at CTFE... nobody will EVER do that. > > > Floats aren't required to have float precision by the C or C++ Standards. I > quoted it for Ola :-) > > >>> It's 128 bits on other CPUs. >> >> What? > > > Some CPUs have 128 bit floats.
Yes, but you don't accidentally use 128bit floats, you type: extended x = 1.3; x + y; If that code were to CTFE, I expect the CTFE to use extended precision. My point is, CTFE should surely follow the types and language semantics as if it were runtime generated code... It's not reasonable that CTFE has higher precision applied than the same code at runtime. CTFE must give the exact same result as runtime execution of the function. >>>> This sounds like designing specifically for my problem from above, >>>> where the frontend is always different than the backend/runtime. >>>> Please have the frontend behave such that it operates on the precise >>>> datatype expressed by the type... the backend probably does this too, >>>> and runtime certainly does; they all match. >>> >>> >>> >>> Except this never happens anyway. >> >> >> Huh? I'm sorry, I didn't follow those points. > > > The belief that compile time and runtime are exactly the same floating point > in C/C++ is false. I'm not interested in C/C++, I gave some anecdotes where it's gone wrong for me too, but regardless; generally, they do match, and I can't think of a single modern example where that's not true. If you *select* fast-math, then you may generate code that doesn't match, but that's a deliberate selection. If I want 'real' math (in CTFE or otherwise), I will type "real". It is completely unreasonable to reinterpret the type that the user specified. CTFE should execute code the same way runtime would execute the code (without -ffast-math, and conformant ieee hardware). This is not a big ask. Incidentally, I made the mistake of mentioning this thread (due to my astonishment that CTFE ignores float types) out loud to my colleagues... and they actually started yelling violently out loud. One of them has now been on a 10 minute angry rant with elevated tone and waving his arms around about how he's been shafted by this sort behaviour so many times before. I wish I recorded it, I'd love to have submit it as evidence.
