On Saturday, 18 August 2012 at 04:44:16 UTC, Jesse Phillips wrote:
> 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).

It's flawed because condition2 relies upon condition1 to function without error. The example, as Walter presented it, is logically describing:

    float f;
    if (condition1) {
        f = 7;
        if (condition2)
            f ++;
    }

because the only way Walter's next argument, that "a programmer will haphazardly supply a default value where there _should_ be a NaN", is in error, because if condition2 _does_ rely upon condition1, then there _shouldn't_ be a NaN by the time condition2 is reached, as condition2 _should_ be nested (like above), and the programmer made a logical mistake (which the compiler can warn him about). Remember, NaN in this example is only used as error checking to ensure 'f' is assigned before it's manipulated.

If however, condition2 isn't intended to rely upon condition1, then 'f' needs to be explicitly assigned a usable value before condition2, and outside of condition1. Which also negates Walter's "haphazardly assigned" argument, because 'f' _isn't_ intended to be NaN (so assigning to 0.0f makes sense), and condition1 is the only place 'f' is assigned in the example.

The only way code like Walter's example is written, is when the coder has made a logical mistake. Which, again, the compiler can warn us about:

    float f;
    if (condition1)
        f = 7;
    // f _could_ be unassigned, therefor...
    if (condition2)
        f ++; // ...should be error


Furthermore, in a situation where the value _is_ intended to be NaN (for example, to check 'f' for NaN after condition2) then an explicit assignment to NaN will help document that intent, and help keep a third party from mistakenly assigning it to something else at a later date:

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

    ...lotsa code...

    if (f == float.nan)
        doSomething();
    else
        doSomethingElse();

In this situation, if floats default to NaN and 'f' wasn't explicitly defined, a maintenance programmer might not recognize the last condition, think "gee, I need to set that to a value in case condition1 fails when condition2 does not", and mistakenly assign 'f' a usable value, thus introducing a silent bug.

F i L:

> It's flawed because condition2 relies upon condition1 to

Some people suggest:
http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_respect/c5uzt46

Regarding that Reddit thread in general, most people there seem quite ignorant about NaNs, so this little article was a small improvement.

Bye,
bearophile

On Saturday, 18 August 2012 at 03:03:23 UTC, bearophile wrote:
> 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? :-)

I'd also like to know this.

Maybe it's just the size of the audience. There's a very large community of programmers online, but the community of chemists and botanists is not so large, so there's less reason to share online.

Maybe it's because programming is so accessible, allowing younger, more opinionated people to share their thoughts. It's easy to achieve something in programming: just download a compiler/interpreter, follow some online tutorials and you'll have something worth sharing. In Chemistry on the other hand, you really need to go to university before you can start doing something beyond simple experiments with household ingredients.

Maybe it's a delusion of grandeur. A lot of programmers have the idea that they could program up the next big computer game, or make the next Facebook or Twitter. When they inevitably fail, they turn to blogging ("Those who can't, teach"). I've noticed this especially on HackerNews, which is of course filled with people with such delusions. P.S. before anyone gets offended, I'm not suggesting this applies to all programming bloggers!

Maybe it's related to the tendency for programmers to be libertarians, which would also explain the whole open source software movement. They want to share knowledge freely, and online articles would be part of that.

Maybe it's related to the religion thing. Programmers tend to be religious about their languages and practices, and are often challenged on their beliefs, so they'll tend to want to preach their ideas to the masses. This reason likely explains this particular article: there was disagreement on the use of NaNs for initialisation, so Walter wanted to express his take on the matter to the masses. I have done similar things in the past, e.g. blogging about my thoughts on immutable in D.

Maybe it's all those things plus more.

That's my thoughts anyway.

On Saturday, 18 August 2012 at 09:32:01 UTC, F i L wrote:

> It's flawed because condition2 relies upon condition1 to function without error. The example, as Walter presented it, is logically describing:
>
>     float f;
>     if (condition1) {
>         f = 7;
>         if (condition2)
>             f ++;
>     }

This greatly changes the semantics of the code. I do not disagree that the example indicates the original programmer is likely wrong and needs to improve the description of his intent.

What I disagree on is that it is that complaining that f might not be initialized will force the programmer to think and address the true issue. It is also taking the example at face value. The complexity of the relationship could be harder too see (I don't know what that would be), and somewhere else where condition1 is set there could be code:

auto condition1 = getmevalue();
enforce(condition1 && condition2, "Huston this is the problem!");

Someone is probably at fault and the one addressing the issue may still get it wrong; if it is the second programmer hopefully they will have more information about what they need as they were the ones changing the semantics of the code.

On Saturday, 18 August 2012 at 14:29:12 UTC, Jesse Phillips wrote:
> On Saturday, 18 August 2012 at 09:32:01 UTC, F i L wrote:
>
>> It's flawed because condition2 relies upon condition1 to function without error. The example, as Walter presented it, is logically describing:
>>
>>    float f;
>>    if (condition1) {
>>        f = 7;
>>        if (condition2)
>>            f ++;
>>    }
>
> This greatly changes the semantics of the code. I do not disagree that the example indicates the original programmer is likely wrong and needs to improve the description of his intent.

I agree, and that's my point here. The original example is an erroneous presupposition that leads to faulty conclusions. If the compiler warned against this error the programmer would likely fix the code to a state which prevents the potential bug this example was originally intended to illustrate.


> What I disagree on is that it is that complaining that f might not be initialized will force the programmer to think and address the true issue. It is also taking the example at face value. The complexity of the relationship could be harder too see (I don't know what that would be),

I too, don't know of any examples where defaulting to NaN would prevent an error where static analysis would not, though I'm always open to argument. Given the benefits of static analysis and defaulting to 0.0f for class members (which I listed in previous posts), I see that position as the one with demonstrable benefit.


> and somewhere else where condition1 is set there could be code:
>
> auto condition1 = getmevalue();
> enforce(condition1 && condition2, "Huston this is the problem!");

I don't see how this changes the situation with NaN vs. static analysis.

On 8/18/2012 6:51 AM, Peter Alexander wrote:
> Maybe it's related to the tendency for programmers to be libertarians, which
> would also explain the whole open source software movement. They want to share
> knowledge freely, and online articles would be part of that.

I find this peculiar, as the open source software movement is frequently associated with communism, not libertarianism. (Although I do think it is much more correct to associate it with libertarianism.)

> This reason likely
> explains this particular article: there was disagreement on the use of NaNs for
> initialisation, so Walter wanted to express his take on the matter to the
> masses. I have done similar things in the past, e.g. blogging about my thoughts
> on immutable in D.

I write the blogs in Dr. Dobbs because the editors of DDJ have always been very nice to me and supportive of my efforts, going all the way back to my Zortech days. They asked me to write the blogs, and send me nice comments about them. The positive responses they get on reddit encourage me to continue doing them.

I wrote the NaN one because there was a lot of interesting discussion on it in the n.g., and so I thought a wider audience would find it interesting as well.

On Saturday, 18 August 2012 at 18:06:12 UTC, F i L wrote:
> If the compiler warned against this error the programmer would likely fix the code to a state which prevents the potential bug this example was originally intended to illustrate.

It is this statement that indicates you didn't fully comprehend what was written in the article.

It is likely that the author will initialize f to a value. In which case you have increased the likelyhood that the incorrect value of 0 will be assigned instead of NAN. So I do not agree that it is likely he will fix the code in a manner that would prevent this bug from happening.

Another sub-thread that shows a very important thing, that's missing:

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

Bye,
bearophile

On 8/17/12 8: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/

Homerun. Nice!!

Andrei

On Sat, 18 Aug 2012 23:12:10 +0200
"Jesse Phillips" <jessekphillips+D@gmail.com> wrote:

> On Saturday, 18 August 2012 at 18:06:12 UTC, F i L wrote:
> > If the compiler warned against this error the programmer would likely fix the code to a state which prevents the potential bug this example was originally intended to illustrate.
> 
> It is this statement that indicates you didn't fully comprehend what was written in the article.
> 
> It is likely that the author will initialize f to a value. In which case you have increased the likelyhood that the incorrect value of 0 will be assigned instead of NAN. So I do not agree that it is likely he will fix the code in a manner that would prevent this bug from happening.

Bullshit, I've used C# which does exactly what Walter is arguing against, and the result never involved getting annoyed and blindly tossing in an "=0".