Movement against float.init being nan
Timon Gehr
timon.gehr at gmx.ch
Tue Aug 30 00:27:05 UTC 2022
On 25.08.22 18:56, Walter Bright wrote:
> On 8/25/2022 9:16 AM, IGotD- wrote:
>> Which is strange because HW wise it is trivial to check if the result
>> is NaN. To check that NaN is not based on input is of course more
>> complicated. Then again an x86 complicated in an unhealthy way.
>>
>> This kind of makes another motivation to let floats default to zero,
>> if this is correct.
>
>
> There's nothing to be afraid of in getting a NaN in the output. One
> should be glad, because then one *knows* there's a bug.
>
> This thread reminds me of the threads about assert, and the contention
> that the program should continue after a failed assert.
> ...
Clearly you should throw away your computer after a failed assert.
> 1. It is not better to pretend a program is working when it is not.
>
> 2. It is not better for a language to guess at what the programmer must
> have meant, even if the guess is correct 99% of the time.
>
> 3. It is not better to never check the output of the program for
> correctness.
>
> D is a tool for helping the programmer create correct, robust, and
> bug-free programs.
Which is why asserts can introduce new _undefined behavior_?
More information about the Digitalmars-d
mailing list