Re: Python from Wise Guy's Viewpoint
From: Joachim Durchholz (joachim.durchholz_at_web.de)
Date: 10/20/03
- Next message: Joachim Durchholz: "Re: Python from Wise Guy's Viewpoint"
- Previous message: Duncan Grisby: "Re: Python <-> Java RMI"
- In reply to: Kenny Tilton: "Re: Python from Wise Guy's Viewpoint"
- Next in thread: Markus Mottl: "Re: Python from Wise Guy's Viewpoint"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 20 Oct 2003 13:22:08 +0200
Kenny Tilton wrote:
>
> Dennis Lee Bieber wrote:
>
>> 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."
That's the sequence of events that led to the crash.
Why this sequence could happen though it shouldn't have happened is
exactly how Dennis wrote it: the conversion caused an exception because
the Ariane-5 had a tilt angle beyond what the SRI was designed for.
> 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
Lisp might not have helped even in that case.
1. The SRI was designed for an angle that would have fit into a 16-bit
operand. If the exception hadn't been thrown, some hardware might still
have malfunctioned.
2. I'm pretty sure there's a reason (other than saving space) for that
conversion to 16 bits. I suspect it was to be fed into some hardware
register... in which case all bignums of the world aren't going to help.
Ariane 5 is mostly a lesson in management errors. Software methodology
might have helped, but just replacing the programming language would
have been insufficient (as usual - languages can make proper testing
easier or harder, but the trade-off will always be present).
Regards,
Jo
- Next message: Joachim Durchholz: "Re: Python from Wise Guy's Viewpoint"
- Previous message: Duncan Grisby: "Re: Python <-> Java RMI"
- In reply to: Kenny Tilton: "Re: Python from Wise Guy's Viewpoint"
- Next in thread: Markus Mottl: "Re: Python from Wise Guy's Viewpoint"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
