Always false float comparisons

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun May 15 21:02:54 PDT 2016


On 16 May 2016 at 12:56, Walter Bright via Digitalmars-d
<digitalmars-d at 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.


More information about the Digitalmars-d mailing list