On Sat, 18 Aug 2012 21:12:33 -0700
Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> FWIW, I'm very surprised by how negatively many programmers seem to react to NaN. I think that how D handles it is great.

Yea, it's kind of like Unicode: ASCII is much simpler and therefore far more enticing. But unfortunately we have to deal with reality and reality dictates that NaNs and non-ASCII chars exist and must be taken into consideration.

Am 19.08.2012 06:12, schrieb Jonathan M Davis:
> On Friday, August 17, 2012 17:03:13 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_res
>> pect/
>>
>> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723
>
> FWIW, I'm very surprised by how negatively many programmers seem to react to
> NaN. I think that how D handles it is great.

i think many of these programmers seems to think that D is introducing this NaN-Type ...

On 8/18/2012 9:21 PM, Nick Sabalausky wrote:
> After actually *using* both D (default-initialization) and C#
> (statically/conservatively ensure things can't be accessed without
> being explicitly inited), and I'm convinced the benefits of the static
> checks easily outweigh the fear of a knee-jerk "=0".


I'm less willing to throw default initialization out - I like it & rely on it. The C# approach pretty much ends default initialization, including for user defined types.

On 8/18/2012 9:33 PM, Nick Sabalausky wrote:
> It sounds like it's some EE joke, but yea, strange as it seems, not
> only is there really a "Don't care", but it's actually useful

Yup, it turns out that all 4 states are very useful.

On 8/19/2012 12:12 AM, dennis luehring wrote:
> Am 19.08.2012 06:12, schrieb Jonathan M Davis:
>> On Friday, August 17, 2012 17:03:13 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_res
>>>
>>> pect/
>>>
>>> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723
>>
>> FWIW, I'm very surprised by how negatively many programmers seem to
>> react to
>> NaN. I think that how D handles it is great.
>
> i think many of these programmers seems to think that D is introducing
> this NaN-Type ...
>

Nobody knows how floats work, without being locked in a closet for a at least a week and told to change their doubles back into floats and fix their code, since thats where 99% of precision problems actually come from.

On 8/18/2012 11:21 PM, Sean Cavanaugh wrote:
> Nobody knows how floats work, without being locked in a closet for a at least a
> week and told to change their doubles back into floats and fix their code, since
> thats where 99% of precision problems actually come from.


I was forced to figure out how they work in excruciating detail, as I had to write an emulator in case the user didn't have an 8087.

Actually, that knowledge has served me well.

On Sunday, 19 August 2012 at 05:13:09 UTC, dennis luehring wrote:
> Am 19.08.2012 06:12, schrieb Jonathan M Davis:
>> On Friday, August 17, 2012 17:03:13 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_res
>>> pect/
>>>
>>> http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723
>>
>> FWIW, I'm very surprised by how negatively many programmers seem to react to
>> NaN. I think that how D handles it is great.
>
> i think many of these programmers seems to think that D is introducing this NaN-Type ...

Yes, I got this impression as well. What a sad state of affairs.

Walter Bright:

> Oh come on. That's called a "user defined type."

This D code compiles and it throws an "Enforcement failed" Exception at runtime:

import std.typecons: Nullable;
void main() {
    Nullable!int x;
    int y = x;
}


With a different type system the compiler makes sure at compile-time that x is not empty (this means the compiler makes sure in no code paths x is used before testing it contains something), avoiding the run-time exception.

Bye,
bearophile

On 2012-08-19 05:54:49 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 8/18/2012 9:21 PM, Nick Sabalausky wrote:
>> After actually *using* both D (default-initialization) and C#
>> (statically/conservatively ensure things can't be accessed without
>> being explicitly inited), and I'm convinced the benefits of the static
>> checks easily outweigh the fear of a knee-jerk "=0".
> 
> I'm less willing to throw default initialization out - I like it & rely on it. The C# approach pretty much ends default initialization, including for user defined types.

I like default initialization too, and I rely on it. By that I mean that all the time I write "size_t count;" and assume it'll be default initialized to zero. I like it because it's less typing and it's simple: if I don't assign anything it's zero. I can't do that for floats or chars, because the default initialization gives me a unusable value. In my mind C#-style conservative flow analysis errors are better than default initialization to a bogus value because they catch the problem at compile time. But on the other side I'd rather not give up on integer default initialization to zero, as I actually prefer this over everything else.

So Walter, which default initialization do you like an rely on?

As I said, personally, I'd have everything initialized to zero by default. But at this point you can't really change this even if you want to: some program somewhere might rely on float being initialized to NaN by default and might start to give erroneous results if you change the default. (Notice the irony?)

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Sunday, 19 August 2012 at 14:14:00 UTC, Michel Fortin wrote:
> On 2012-08-19 05:54:49 +0000, Walter Bright <newshound2@digitalmars.com> said:
>
>> On 8/18/2012 9:21 PM, Nick Sabalausky wrote:
>>> After actually *using* both D (default-initialization) and C#
>>> (statically/conservatively ensure things can't be accessed without
>>> being explicitly inited), and I'm convinced the benefits of the static
>>> checks easily outweigh the fear of a knee-jerk "=0".
>> 
>> I'm less willing to throw default initialization out - I like it & rely on it. The C# approach pretty much ends default initialization, including for user defined types.
>
> I like default initialization too, and I rely on it. By that I mean that all the time I write "size_t count;" and assume it'll be default initialized to zero. I like it because it's less typing and it's simple: if I don't assign anything it's zero. I can't do that for floats or chars, because the default initialization gives me a unusable value. In my mind C#-style conservative flow analysis errors are better than default initialization to a bogus value because they catch the problem at compile time. But on the other side I'd rather not give up on integer default initialization to zero, as I actually prefer this over everything else.
>
> So Walter, which default initialization do you like an rely on?
>
> As I said, personally, I'd have everything initialized to zero by default. But at this point you can't really change this even if you want to: some program somewhere might rely on float being initialized to NaN by default and might start to give erroneous results if you change the default. (Notice the irony?)

The problem with implicit initialisation to zero is that it is indistinguishable from simply forgetting to initialise the value.

There's three scenarios here:

1. You intentionally relied on implicit initialisation: GOOD.
2. You forgot, 0 wasn't what you wanted, but the error shows up quickly: NOT BAD
3. You forgot, 0 wasn't what you wanted, but the error is subtle/rare: BAD

#3 is where the nasty bugs come in. From my experience, these bugs have the potential to be monsters, and in my opinion, avoiding them is far more important than saving a couple of keystrokes in initialisation.

There's two solutions:

1. Conservative compile-time error on uninitialised variables.
2. Initialise to a value that will make scenario #2 more likely than scenario #3 (e.g. NaN)

Personally, I'd prefer option 1. Walter's argument is that this "leads to the programmer getting annoyed with false positive error diagnostics, and he'll likely add an =0", which is true, but in my opinion this scenario is quite rare to start with, and it's even more rare that 0 isn't actually the right initialisation value, and even then it's only a problem if the introduced bug is hard to reproduce. I find it more likely that the NaN will go unnoticed and cause rare bugs.