Python from Wise Guy's Viewpoint

[Kenny Tilton]

Dennis Lee Bieber wrote:

> Scott McIntire fed this fish to the penguins on Sunday 19 October 2003 
> 15:39 pm:
> 
> 
>>There was a nice example from one of the ILC 2003 talks about a
>>Europian Space Agency rocket exploding with a valueable payload. My
>>understanding was that there was testing, but maybe too much emphasis
>>was placed the static type checking of the language used to control
>>the rocket. The end result was a run time arithmetic overflow which
>>the code intepreted as "rocket off course". The rocket code
>>instructions in this event were to self destruct. It seems to me that
>>the Agency would have fared better if they just used Lisp - which has
>>bignums - and relied more on regression suites and less on the belief
>>that static type checking systems would save the day.
>>
>> I'd be interested in hearing more about this from someone who knows
>> the
>>details.
>>
> 
>         Just check the archives for comp.lang.ada and Ariane-5.
> 
>         Short version: The software performed correctly, to specification 
> (including the failure mode) -- ON THE ARIANE 4 FOR WHICH IT WAS 
> DESIGNED.

Nonsense. From: http://www.sp.ph.ic.ac.uk/Cluster/report.html

"The internal SRI software exception was caused during execution of a 
data conversion from 64-bit floating point to 16-bit signed integer 
value. The floating point number which was converted had a value greater 
than what could be represented by a 16-bit signed integer. This resulted 
in an Operand Error. The data conversion instructions (in Ada code) were 
not protected from causing an Operand Error, although other conversions 
of comparable variables in the same place in the code were protected. 
The error occurred in a part of the software that only performs 
alignment of the strap-down inertial platform. This software module 
computes meaningful results only before lift-off. As soon as the 
launcher lifts off, this function serves no purpose."


>         LISP wouldn't have helped -- since the A-4 code was supposed to 
> failure with values that large... And would have done the same thing if 
> plugged in the A-5. (Or are you proposing that the A-4 code is supposed 
> to ignore a performance requirement?)

"supposed to" fail? chya. This was nothing more than an unhandled 
exception crashing the sytem and its identical backup. Other conversions 
were protected so they could handle things intelligently, this bad boy 
went unguarded. Note also that the code functionality was pre-ignition 
only, so there is no way they were thinking that a cool way to abort the 
flight would be to leave a program exception unhandled.

What happened (aside from an unnecessary chunk of code running 
increasing risk to no good end) is that the extra power of the A5 caused 
oscillations greater than those seen in the A4. Those greater 
oscillations took the 64-bit float beyond what would fit in the 16-bit 
int. kablam. Operand Error. This is not a system saying "whoa, out of 
range, abort".

As for Lisp not helping:

 > most-positive-fixnum ;; constant provided by implementation
536870911

 > (1+ most-positive-fixnum) ;; overflow fixnum type and...
536870912

 > (type-of (1+ most-positive-fixnum)) ;; ...auto bignum type
BIGNUM

 > (round most-positive-single-float) ;; or floor or ceiling
340282346638528859811704183484516925440
0.0

 > (type-of *)
BIGNUM

kenny

-- 
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
  http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey