Our discussion on this in the last few days inspired me to write a blog post about it:

http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/

http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723

Walter Bright:

> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723

You have omitted the detail that double.nan !is double.init.

On a more general note, I know many professionals in other fields that never write small articles about what they are doing. So is it normal just for programmers to write (small) articles like this? I write them, and other programmers I know write similar things. Maybe to program you need (among other things) active linguistic centers in the brain :-)

Bye,
bearophile

Your example:

    float f;
    if (condition1)
        f = 7;
    ... code ...
    if (condition2)
        ++f;

is flawed in that condition1 is _required_ to pass in sync with condition2, or you'll get a NaN in the result. In this scenario, you're forced to provide a usable default explicitly no matter what, so your later argument:

> "This leads to the programmer getting annoyed with false positive error diagnostics, and he'll likely add an =0"

doesn't make sense, because he needs to provide a usable value in the first place.


This is exactly why I was arguing that explicit assignment to NaN was better for debugging as well. Because a maintenance programmer, that steps in at a later date, would:

    1. be less likely to change an explicit assignment to NaN without understand the code fully first.

    2. have an easier time tracking down the origin of a NaN error, because variables not explicitly assigned to NaN _can't_ be the culprit.

Imagine we have code that looks like:

    class SomeClass
    {
        float foo;
        float bobDole;
        float someKind;
        float barFoo = float.nan;
        float aVariable;
        float barBaz;

        this() { ... lotsa init code ... }
    }

If floats defaulted to 0.0f, then we'd know exactly which variable to analyze in order to find the source of our NaN bug: 'barFoo'. Since we don't have this visual clue, we have to analyze all of them. Of course, we can reverse this by explicitly assigning all, except 'barFoo', to 0.0f, but that's:

1. less convenient to type
2. harder to visually parse to find the potential NaNs
3. inconsistent with 'int'




This is how I wish D worked:

1. Functions:

    void foo() {
        float f;
        f ++; // compiler error
    }

    void foo() {
        float f;
        if (condition1)
            f = 5;
        if (condition2)
            f ++; // compiler error
    }

2. Structs & Classes:

    class Foo {
        float f; // 0.0f
        void bar() { f++; }
        // Notice: no constructor defined
    }

    void main() {
        auto foo = new Foo();
        foo.bar(); // works fine
    }


Unfortunately, structs don't have default constructors in D. I'm not sure exactly why that is, but if there's some design or performance issue, structs could always work like this instead:

3. Structs:

    struct Foo {
        float f; // compiler error
    }

    struct Foo {
        float f = 0; // OK
    }

    struct Foo {
        float f; // OK, if:
        this() { f = 0; } // set in constructor
    }

bearophile wrote:
> On a more general note, I know many professionals in other fields that never write small articles about what they are doing. So is it normal just for programmers to write (small) articles like this? I write them, and other programmers I know write similar things. Maybe to program you need (among other things) active linguistic centers in the brain :-)

Why would it matter what is "normal"? Normality is constantly changing anyways. Or are you just curios if it's been common practice in the past?

F i L:

> Why would it matter what is "normal"?

It matters to me because I am curious.

Why aren't my friends that work or study chemistry writing free small online articles like my programmer&CS friends do? Maybe it's systematic differences in their brain brain? Or it's just more easy to talk about coding compared to botany and chemistry and making engines? Or maybe programmers don't know what they are doing? Or maybe it's just I am not looking in the right places? :-)

Bye,
bearophile

I remember you (Walter) or somebody else talking about signaling NaNs before, but I don't remember many details about it. Does D use them? Is this an answer to the Reddit commenter who mentioned immediately throwing an exception?

On Saturday, 18 August 2012 at 01:07:43 UTC, F i L wrote:
> Your example:
>
>     float f;
>     if (condition1)
>         f = 7;
>     ... code ...
>     if (condition2)
>         ++f;
>
> is flawed in that condition1 is _required_ to pass in sync with condition2, or you'll get a NaN in the result.

It is not flawed as that is exactly what he said condition1 did until the maintenance programmer made a change which caused this to no longer be in sync with condition2 (most likely fixing a bug as condition1 really should have been false).

On 8/17/2012 5:03 PM, Walter Bright wrote:
> Our discussion on this in the last few days inspired me to write a blog post
> about it:
>
> http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/
>
> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723

http://news.ycombinator.com/item?id=4399635

On 8/17/2012 8:03 PM, bearophile wrote:
> Why aren't my friends that work or study chemistry writing free small online
> articles like my programmer&CS friends do?

I have no idea. Please ask them and report back.

On Saturday, 18 August 2012 at 05:07:19 UTC, Walter Bright wrote:
> On 8/17/2012 8:03 PM, bearophile wrote:
>> Why aren't my friends that work or study chemistry writing free small online
>> articles like my programmer&CS friends do?
>
> I have no idea. Please ask them and report back.

"When a non-programmer hears about Michael’s articles the source code
I have released, I usually get a stunned “WTF would you do that for???”
look.

They don’t get it.

Programming is not a zero-sum game. Teaching something to a fellow pro-
grammer doesn’t take it away from you. I’m happy to share I can, because
I’m in it for thelove of programming. The Ferraris are just gravy, honest!"

-John Carmack

---

I enjoyed ze article very much.