Movement against float.init being nan

[drug007]

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?