4 ms·

> You can't say, "always wrap-around when an operation overflows" or "always tell the user (panic) when an operation overflows". If you were designing the flig

> You can't say, "always wrap-around when an operation overflows" or "always tell the user (panic) when an operation overflows". If you were designing the flight software for the Ariane 5, which choice would you make?

GMoromisato 2y ago
I understood that reference. But it just reinforces my point that there are no absolute rules. You have to think.
TeMPOraL 2y ago
The important choice was made elsewhere: flight termination system successfully self-destructed the rocket once it was unlikely to recover from its problem. The Wiki quotes an interesting sentence from the official report - "An underlying theme in the development of Ariane 5 is the bias towards the mitigation of random failure." It's fortunate that that bias didn't extend to flight termination system. At the point flight control software intersects with real life, it's better to destroy an expensive rocket than have it rain fiery hell on some random people somewhere else. That principle holds to this day.
wang_li 2y ago
> If you were designing the flight software for the Ariane 5, which choice would you make? I would take note of the underlying hardware and what range of inputs are allowed and code appropriately. Stop pretending that your software doesn’t have a specific purpose and will run on an actual computer. If you’re doing finance you should be using fixed point integer arithmetic with two or three decimal places. If you’re doing physics simulations you need to be aware of how many significant digits exist. If you ignore your problem space and the kind of system your code is going to run on you’re living in spherical cow world and it doesn’t matter if you over- or under-flow because your software is garbage anyway.
- gizmo686 2y ago
  That is exactly what was done with Ariane. It lead to a complete failure and self destruct. In Ariane 4, they realized that an overflow was physically impossible, and so removed the check for efficiency reasons. The module containing the software ended up being reused on Ariane 5, where the overflow ended up being very possible.

GMoromisato 2y ago

I understood that reference. But it just reinforces my point that there are no absolute rules. You have to think.

TeMPOraL 2y ago

The important choice was made elsewhere: flight termination system successfully self-destructed the rocket once it was unlikely to recover from its problem. The Wiki quotes an interesting sentence from the official report - "An underlying theme in the development of Ariane 5 is the bias towards the mitigation of random failure." It's fortunate that that bias didn't extend to flight termination system. At the point flight control software intersects with real life, it's better to destroy an expensive rocket than have it rain fiery hell on some random people somewhere else. That principle holds to this day.

wang_li 2y ago

> If you were designing the flight software for the Ariane 5, which choice would you make? I would take note of the underlying hardware and what range of inputs are allowed and code appropriately. Stop pretending that your software doesn’t have a specific purpose and will run on an actual computer. If you’re doing finance you should be using fixed point integer arithmetic with two or three decimal places. If you’re doing physics simulations you need to be aware of how many significant digits exist. If you ignore your problem space and the kind of system your code is going to run on you’re living in spherical cow world and it doesn’t matter if you over- or under-flow because your software is garbage anyway.

gizmo686 2y ago
That is exactly what was done with Ariane. It lead to a complete failure and self destruct. In Ariane 4, they realized that an overflow was physically impossible, and so removed the check for efficiency reasons. The module containing the software ended up being reused on Ariane 5, where the overflow ended up being very possible.