On 8/21/22 20:28, claptrap wrote:
> On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:
>> Consider the following pattern, which doesn't appear
>>
>>
>> 1. x is default initialized to NaN. bar(x) produces a NaN result on everything dependent on x. User knows there's a problem.
>>
>> 2. x is default initialized to 0. bar(0) may exhibit problems, but these problems won't necessarily be noticed.
> 
> This is the problem, you suggest that if a variable is zero initialised in error the problems it causes "wont necessarily" be noticed.
> 
> I'm saying that's not true, I'm saying it will almost always be noticed.
> 
> 
> 

It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.

On Sunday, 21 August 2022 at 17:56:58 UTC, drug007 wrote:
> On 8/21/22 20:28, claptrap wrote:
>> On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:
>>> Consider the following pattern, which doesn't appear
>>>
>>>
>>> 1. x is default initialized to NaN. bar(x) produces a NaN result on everything dependent on x. User knows there's a problem.
>>>
>>> 2. x is default initialized to 0. bar(0) may exhibit problems, but these problems won't necessarily be noticed.
>> 
>> This is the problem, you suggest that if a variable is zero initialised in error the problems it causes "wont necessarily" be noticed.
>> 
>> I'm saying that's not true, I'm saying it will almost always be noticed.
>> 
>> 
>> 
>
> It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.

Price for this float=NaN & char=FF
1. Runtime bloat -> all struct/class with (float or char) need special initializer
2. Slow -> all struct/class not able to utilize zero initialized from memory manager
3. Inconsistent with other value types (all zero bits)
4. Aggregated/Sum float var should start with zero

So -> Better error when var is not initialized than this special value

On Sunday, 21 August 2022 at 19:57:52 UTC, apz28 wrote:
>
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
> 3. Inconsistent with other value types (all zero bits)
> 4. Aggregated/Sum float var should start with zero
>
> So -> Better error when var is not initialized than this special value

These are very good points which I agree with. Previously I was a bit it didn't matter for me (either Nan or 0.0) but with these my mind tipped over in favor of zero for both char and floats. It is a better design because of the consistency as well it enables the optimizer to use large moves in order to initialize the memory. However, will it be the real use case after optimizing away unused values, that is the question.

On 8/21/22 22:57, apz28 wrote:
>>
>> It will be noticed but what price? You've initialized all vars to 0 so how do you know that this exactly initialization to zero is wrong? To detect it you should track down manually checking the intermediate results that is manually calculate results and compare to what you get. It takes much more time than checking if the value is NaN.
> 
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
> 3. Inconsistent with other value types (all zero bits)
> 4. Aggregated/Sum float var should start with zero
> 
> So -> Better error when var is not initialized than this special value
> 

Let me disagree to you

1) Every struct/class needs special initializer because datatypes definitely are different. According to your logic user should initialize all fields to zero and only zero. No other values are possible. It is really strange point.
2) Again you argue against non-zero initialized fields in aggregate types.
3) Once again - not all types should be zero initialized. For example, covariance matrix in Kalman Filter should NOT be initialized to zero. In other case the filter won't work at all.
4) No, you are wrong again. sum accumulator should not start with zero, in other case sum algorithm has no this argument at all, right?

On Sunday, 21 August 2022 at 19:57:52 UTC, apz28 wrote:
> Price for this float=NaN & char=FF
> 1. Runtime bloat -> all struct/class with (float or char) need special initializer
No. If intentional you can explicitly leave them uninitialized (= void)

> 2. Slow -> all struct/class not able to utilize zero initialized from memory manager
Fill with specific pattern is _really_ fast, so very very low performance lost - and only once as you shouldn't do initialization in a loop, do you?

> 3. Inconsistent with other value types (all zero bits)
I agree to this, but you choose the wrong solution.
Correct would be to initialize the remaining types also with an invalid value instead of zero.

> 4. Aggregated/Sum float var should start with zero
Why? For this to be an argument on its own, it should not refer to (1)..(3)

So: no argument left. Too bad.