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

--- Comment #10 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Leandro Lucarella from comment #9)
> (In reply to David Eckardt from comment #8)
> > My point is: NaN was intentionally chosen as the initial floating point
> > value to detect the common bug of forgetting to initialize a variable
> > (http://dlang.org/faq.html#nan). The standard way to detect bugs is a plain
> > assert(). So assert() should fail with NaN.
> 
> Yeah, this is the key, NaN should behave the same as null, it should explode as soon as it's used.

NaN is designed not to explode when used, but to propagate in that all operations on NaN should yield NaN as a result. Changing this would be not only a drastic change to the language, but would cause D to behave very differently from every other language that deals with NaNs.

I propose instead that, here, the real problem is what lround() did with a NaN value - it returned garbage. I suggest that you ban use of lround() from your system and replace with one that asserts on NaN arguments.


> > (PS. Amounts like 80,833,756,980 Vietnamese Đồng do happen so limiting them is far from trivial...)
> 
> Yeah, you should have to check the currency and maintain a table of conversion rates. Not a very promising approach ;-)

That's 80 billion, far short of the 9 trillion in the original error. It is essential to have sanity checks on the results of critical calculations.

D2 has also recently added core.checkedint with functions in it to do overflow checking addition, subtraction, multiplication and division. These are portable to D1. They replace ad hoc methods that are often misguided or simply wrong.

--

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

--- Comment #11 from Don <clugdbug@yahoo.com.au> ---
>> > (PS. Amounts like 80,833,756,980 Vietnamese Đồng do happen so limiting them is far from trivial...)
>> 
>> Yeah, you should have to check the currency and maintain a table of conversion rates. Not a very promising approach ;-)

>That's 80 billion, far short of the 9 trillion in the original error. It is >essential to have sanity checks on the results of critical calculations.

FWIW we advertise some real estate in the €20 million price range. That is 0.4 trillion Đồng. I don't see any reason why the Đồng couldn't collapse even further, and push it into the trillions. We have a long history of our sanity checks being incorrect - the real world is a crazy place!
----

But, back on topic -- I think it is debatable whether assert(NaN) should be
false (as originally proposed here), or if it should fail to compile.

But I am certain that the current behaviour, that assert(NaN) passes, is wrong.

Pretty much all existing code containg
   assert(f);
except where f is known at compile time, is broken code. And this is the point
-- it's a place in the language where something that looks completely innocent,
is actually a landmine.


We can either make it have the behaviour that the author clearly intended,
(ie, assert( !(f == 0) );  <--- Look Mum, no NCEG operators! )
or we could statically disallow implicit conversion from float to bool unless
we can prove that the float isn't NaN.

I mean, is NaN true, or is it false? The answer is NO, it isn't!

So a sensible mapping from IEEE float to bool is not possible.

--

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

monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com

--- Comment #12 from monarchdodra@gmail.com ---
(In reply to Don from comment #11)
> But I am certain that the current behaviour, that assert(NaN) passes, is
> wrong.

Agreed. It was my understanding anyways that anything that operates on NaN produces "false" anyways.

I'd expect *both*:
assert( NaN);
assert(!NaN;

to fail, actually, since the fist one is "Are you non 0? No" and the second is "Are you 0? No."

--

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

Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv

--- Comment #13 from Dicebot <public@dicebot.lv> ---
(In reply to monarchdodra from comment #12)
> (In reply to Don from comment #11)
> > But I am certain that the current behaviour, that assert(NaN) passes, is
> > wrong.
> 
> Agreed. It was my understanding anyways that anything that operates on NaN produces "false" anyways.
> 
> I'd expect *both*:
> assert( NaN);
> assert(!NaN;
> 
> to fail, actually, since the fist one is "Are you non 0? No" and the second is "Are you 0? No."

I agree with this.

One additional thing to point out is that `assert` has already a precedent of being more than just check for 0 - it calls object invariant. Thus meaning of `assert(object)` is closer to "check if this thing is in usable state" and NaN is not a usable state by definition.

--

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

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D2

--

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

Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com

--- Comment #14 from Stewart Gordon <smjg@iname.com> ---
(In reply to David Eckardt from comment #0)
> ulong calcAmount ( double x )
> in
> {
>     assert(x); // succeeds for NaN
> }
> body
> {
>     // do calculation with x
>     return lround(fabs(x)); // returns 9223372036854775808 if x is NaN
> }
> ---

This looks to me like a problem with either lround or fabs, rather than with the boolean semantics of a floating point.  Still, I agree that the boolean semantics are an issue.

(In reply to Walter Bright from comment #2)
> In other words, both of them treat NaN as "TRUE". I fear that if we deviate from this behavior, we'll get subtly broken code that is written by former C++ programmers or that is transliterated from C++.

Can you give an example of how real-world code might explicitly rely on NaN being boolean true?

(In reply to bearophile_hugs from comment #4)
> The current D situation seems standard:
> 
> http://stackoverflow.com/questions/9158567/nan-to-bool-conversion-true-or- false
> 
> http://stackoverflow.com/questions/15686318/why-do-not-a-number-values-equal- true-when-cast-as-boolean-in-python-numpy

The spec snippets pasted there don't mention NaN; as such, it looks to me like an oversight.  Furthermore, I have just offered this insight on the C/C++ treatment:

But does NaN constitute a value at all? It's similar to NULL in typical database systems. I was explicitly taught that NULL is not a value, but the absence of a value. Unless there's evidence to the contrary, I think we can claim the same about NaN. As such, I argue that this leaves the behaviour of convert NaN to a bool undefined, unless there's something elsewhere in the spec that covers the issue.

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #15 from Dlang Bot <dlang-bot@dlang.rocks> ---
@Geod24 created dlang/dmd pull request #10363 "Fix issue 13489:  Boolean semantics of floating point types should handle float" fixing this issue:

- Fix issue 13489:  Boolean semantics of floating point types should handle float

https://github.com/dlang/dmd/pull/10363

--

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

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pro.mathias.lang@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #16 from Mathias LANG <pro.mathias.lang@gmail.com> ---
Walter rejected the PR made to fix this. Closing as "WONTFIX".

--