Movement against float.init being nan

[Steven Schveighoffer]

On 8/24/22 9:19 PM, Walter Bright wrote:
> On 8/24/2022 7:03 AM, Steven Schveighoffer wrote:
>> I actually proved this too with a test, so that's good news! Maybe I 
>> just need to define all my structs using C :P
> 
> You could, but NaN default initialization is better.
> 
> I inferred that you relied on detecting a wrong 0 initialization by 
> looking for unexpected behavior. This is less reliable than looking for 
> a NaN in the output. When the behavior of a mistake being most of the 
> time it will work out ok, is not acceptable because there's that case 
> where it won't be ok and could be very costly.

No, you are completely misunderstanding what I'm saying.

What I was saying is that NaN is not that much different from 0 when the 
outputs you have aren't "val = NaN". I.e. most of the time.

Once you have determined there is a problem, I don't really think NaN 
helps much finding the source -- the source can be long gone by the time 
you attach a debugger. The correct mechanism is to look at what possible 
places the value could be written, and trace it back to the incorrect value.

But what I *am* saying is that I frequently omit initialization of 
numbers I expect to start at 0. I forget that double is NaN by default, 
and then I have to find and fix that. The only thing NaN has ever done 
for me is found places where I forgot to initialize to 0.

> 
> It should not be "the output looks sort of right, so assume it is 
> right." It should *be* right, or be *obviously* wrong.
> 
> People should have to explicitly work at getting it wrong.
> 
> These are more of those lessons I picked up from working on flight 
> controls at Boeing.

NaN fails at that. It's silently swallowed by just about everything. 
Only when a human looks at some printout does it become obvious.

A better option would be to throw an exception if NaN is used in an 
operation.

> For example, hydraulic actuators (rams) drive the flight control 
> surfaces back and forth. The actuators have a hydraulic fluid input 
> port, and an output port. If the hydraulic lines are hooked to the wrong 
> ports, the airplane will be uncontrollable and will crash. This has 
> happened many times in the past. Boeing's solution is to:
> 
> 1. the ports are different sizes
> 2. one is a left-hand thread, the other is a right-hand thread
> 3. the lines and ports are color-coded
> 4. the lines are laid out so the hydraulic lines are not long enough to 
> connect to the wrong port
> 5. inspectors have to sign off on it
> 6. the flight controls are tested for correct operation as part of the 
> pre-flight checklist
> 
> This has stopped the problem. Note how hard a mechanic would have to 
> work to get it wrong, and if he succeeded it would be *obviously* wrong 
> to the inspector.
> 
> I try to infuse this philosophy into D's design where ever it fits.

I understand, but NaN is woefully inadequate for the task.

NaN is more like if you hooked up the ports wrong, a dye is added to the 
fluid, which isn't visible through the tubes. You have to extract and 
examine the fluid to realize something is wrong. Then you have to find 
the source of the dye (and it could come from anywhere in the system).

-Steve