OT: Ariane 5 Launcher Failure

Folks,

I've been in a LinkedIn discussion in which the following analysis an
Ariane 5 failure is documented:

  http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

I'm just reposting it here since I find it fascinating, and I bet there
are a few folks here (Tim, you come to mind especially) who might have a
few things to say about it.

I find it almost laughable (if it weren't for the expense and danger
such a failure had or potentially had) that the root cause was a
conversion from float to integer! It supports a "feeling" I've had for a
long time that coding in float is dangerous for just such reasons.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 9/1/15 7:36 AM, Randy Yates wrote:
> Folks,
>
> I've been in a LinkedIn discussion in which the following analysis an
> Ariane 5 failure is documented:
>
>    http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
>
> I'm just reposting it here since I find it fascinating, and I bet there
> are a few folks here (Tim, you come to mind especially) who might have a
> few things to say about it.
>
> I find it almost laughable (if it weren't for the expense and danger
> such a failure had or potentially had) that the root cause was a
> conversion from float to integer! It supports a "feeling" I've had for a
> long time that coding in float is dangerous for just such reasons.

i'm fiddling with a SHArC at the moment, and sometimes i like to do 
reversible operations on numbers.  just can't trust them friggin' 
floating-point operations to be reversible, even when the underlying 
math is supposed to be.

BTW, before 2006 i never knew this about the PDP-10, but instead of 
sign-magnitude floating point (as IEEE-754 is), it was like "2's 
complement" floating point.  so the integer compare worked with PDP-10 
floats in the same way as it does with 2's-comp integers.  that's really 
smart.

some company that i once worked for (and will go unnamed), extended that 
PDP-10 floating-point format by adding denormals to it.  that was 
really, really smart.  so the mapping of a mathematical value to a 
signed-integer representation was a piecewise-linear approximation to 
the arcsinh() function.  smooth (sorta), monotonic, and complete.  no 
bit pattern was a NaN.  every bit pattern sensibly mapped to a number.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On 9/1/2015 7:36 AM, Randy Yates wrote:
> Folks,
>
> I've been in a LinkedIn discussion in which the following analysis an
> Ariane 5 failure is documented:
>
>    http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
>
> I'm just reposting it here since I find it fascinating, and I bet there
> are a few folks here (Tim, you come to mind especially) who might have a
> few things to say about it.
>
> I find it almost laughable (if it weren't for the expense and danger
> such a failure had or potentially had) that the root cause was a
> conversion from float to integer! It supports a "feeling" I've had for a
> long time that coding in float is dangerous for just such reasons.

I find this conclusion to show an immense lack of understanding of the 
cause of the failure.  Did we read the same report?

The use of integers for the variable that was the float would not have 
mitigated the accident.  If you had used an N bit integer the same 
conversion to a 16 bit integer would have resulted in the same overflow 
and conversion error.

The two primary causes of the accident were allowing the software for 
alignment of the strap-down inertial platform to continue to run after 
liftoff when it received invalid inputs which resulted in the out of 
range problem and the decision to shut down the processor on this error 
based on the assumption that the software was not faulty but rather the 
hardware was, which was an erroneous assumption in this case.

-- 

Rick

Randy Yates  <yates@digitalsignallabs.com> wrote:

>I find it almost laughable (if it weren't for the expense and danger
>such a failure had or potentially had) that the root cause was a
>conversion from float to integer! It supports a "feeling" I've had for a
>long time that coding in float is dangerous for just such reasons.

This puts you with Von Neumann.

Floats and doubles are not dangerous.  They can store integers within a
certain range, just like any other format.

Programmers however are dangerous.

Steve

On Tue, 01 Sep 2015 07:36:01 -0400, Randy Yates wrote:

> Folks,
> 
> I've been in a LinkedIn discussion in which the following analysis an
> Ariane 5 failure is documented:
> 
>   http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
> 
> I'm just reposting it here since I find it fascinating, and I bet there
> are a few folks here (Tim, you come to mind especially) who might have a
> few things to say about it.
> 
> I find it almost laughable (if it weren't for the expense and danger
> such a failure had or potentially had) that the root cause was a
> conversion from float to integer! It supports a "feeling" I've had for a
> long time that coding in float is dangerous for just such reasons.

Well, I don't see that as the biggest error, or even one that, given the 
nature of the root problem, would have saved the thing if it was 
corrected.

The problem, as I see it, is that when they wrote the software for the 
Ariane 4 they were a bit sloppy (in the floating-to-integer conversion).  
Then, when they decided to reuse the software in the Ariane 5 they did 
not fully consider the impact of the change in the flight trajectory -- 
i.e., they were sloppy.  Then, they didn't fully test the software -- 
i.e., they were sloppy.

So they basically crashed an entire rocket system because they were 
sloppy.

Now, if I'm going to bring MY prejudices to bear on this, it was because 
the systems engineering team was of the opinion that embedded software is 
Black Magic, or they considered that it doesn't really have value because 
it doesn't show up as a line item on the bill of materials.

-- 
www.wescottdesign.com

On 9/1/2015 10:59 AM, Tim Wescott wrote:
>
> Now, if I'm going to bring MY prejudices to bear on this, it was because
> the systems engineering team was of the opinion that embedded software is
> Black Magic, or they considered that it doesn't really have value because
> it doesn't show up as a line item on the bill of materials.

Prejudice is exactly the right word.

-- 

Rick

On Tue, 01 Sep 2015 07:36:01 -0400, Randy Yates wrote:

> Folks,
> 
> I've been in a LinkedIn discussion in which the following analysis an
> Ariane 5 failure is documented:
> 
>   http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
> 
> I'm just reposting it here since I find it fascinating, and I bet there
> are a few folks here (Tim, you come to mind especially) who might have a
> few things to say about it.
> 
> I find it almost laughable (if it weren't for the expense and danger
> such a failure had or potentially had) that the root cause was a
> conversion from float to integer! It supports a "feeling" I've had for a
> long time that coding in float is dangerous for just such reasons.

Also, to the extent that it was a problem with using floating point, 
rather than general sloppiness, it was a problem of _mixing_ floating 
point with integers -- you can get similar difficulties when you mix 
integers of different sizes, or when you change from one scaling to 
another in integer math.

I just don't see using floating point as a universal bugaboo, except 
perhaps to the extent that it consumes a lot of computational power and 
that what traps it has are better hidden than the traps with fixed-point 
math.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Tuesday, September 1, 2015 at 11:36:05 PM UTC+12, Randy Yates wrote:
> Folks,
> 
> I've been in a LinkedIn discussion in which the following analysis an
> Ariane 5 failure is documented:
> 
>   http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
> 
> I'm just reposting it here since I find it fascinating, and I bet there
> are a few folks here (Tim, you come to mind especially) who might have a
> few things to say about it.
> 
> I find it almost laughable (if it weren't for the expense and danger
> such a failure had or potentially had) that the root cause was a
> conversion from float to integer! It supports a "feeling" I've had for a
> long time that coding in float is dangerous for just such reasons.
> -- 
> Randy Yates
> Digital Signal Labs
> http://www.digitalsignallabs.com

I thought they used ADA for such things

On 9/1/2015 3:01 PM, gyansorova@gmail.com wrote:
> On Tuesday, September 1, 2015 at 11:36:05 PM UTC+12, Randy Yates wrote:
>> Folks,
>>
>> I've been in a LinkedIn discussion in which the following analysis an
>> Ariane 5 failure is documented:
>>
>>    http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
>>
>> I'm just reposting it here since I find it fascinating, and I bet there
>> are a few folks here (Tim, you come to mind especially) who might have a
>> few things to say about it.
>>
>> I find it almost laughable (if it weren't for the expense and danger
>> such a failure had or potentially had) that the root cause was a
>> conversion from float to integer! It supports a "feeling" I've had for a
>> long time that coding in float is dangerous for just such reasons.
>> --
>> Randy Yates
>> Digital Signal Labs
>> http://www.digitalsignallabs.com
>
> I thought they used ADA for such things

They did.  What's your point?

-- 

Rick

rickman  <gnuarm@gmail.com> wrote:

>On 9/1/2015 3:01 PM, gyansorova@gmail.com wrote:

>> On Tuesday, September 1, 2015 at 11:36:05 PM UTC+12, Randy Yates wrote:

>>> I find it almost laughable (if it weren't for the expense and danger
>>> such a failure had or potentially had) that the root cause was a
>>> conversion from float to integer! It supports a "feeling" I've had for a
>>> long time that coding in float is dangerous for just such reasons.

>> I thought they used ADA for such things

>They did.  What's your point?

Clearly the root problem was more the inappropriate exception
handling, than the fact of using a float to store and integer.

There is nothing dangerous about storing an integer in a float
or double, people do it all the time and in many scenarios
it leads to a more consistent coding style.

Steve