Re: Papers on the Ariane-5 crash and Design by Contract

["Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>]

Nick Roberts <Nick.Roberts@DIAL.PIPEX.COM> writes:
>>     it overflow. It might have saved the Ariane. What might also have
>>     saved them would be if the arithmetic on the machine had saturated
>>     instead of causing an interrupt. (Disable the interrupt & let the
>>     hardware saturate or enable the interrupt & put your own
>>     saturation software in there.) Floating point usually saturates
>>     the way you want it to from hardware, but fixed usually doesn't.
>>
>
>I would be very grateful if you (or someone) would explain the term
>'saturation' in this context. I'm not accusing you of incorrect usage of a
>technical term, merely myself of ignorance. I would be very interested.
>
>
    I'm not sure if there is some formal academic definition of the
    term in either mathematics or computer science. I've only learned
    to use the term the way it gets used in the embedded world around
    here.

    Integer arithmetic is the simplest case: If you have a 16bit
    signed integer with a value of +32766 in it and you add, say +10
    to it, instead of getting a value that wraps around to the
    negative (including an interrupt for fixed point overflow) you get
    +32767. In other words, the register "saturates" to its maximum
    possible value.

    Floating point overflow/underflow is similar, except you have to
    deal with very large & very small numbers as well as negative &
    positive. If you have "saturated" floating point arithmetic, as
    you continually divide a number by 0.1 and it gets closer and
    closer to zero, eventually you trip over the smallest number
    representable and the number "saturates" to zero. Likewise, in the
    other direction.

    If you're lucky, your hardware will do this for you. If not,
    you've got to implement this effect in software - which in Ada is
    easy to do by defining your own type with it's own "+", "-", etc
    operators - but that can be terribly slow!

    The reason that saturation is such a good thing in "control"
    systems is because it is very much like the real world works. If
    you're commanding some motor to turn at a given rate, sooner or
    later you hit the maximum rate the motor can turn and commanding
    it to turn faster does no good. Thus your math which calculates
    how to command the motor ought to saturate the same way the motor
    does. If it wraps around to a big negative number, chances are you
    just commanded the motor to spin at max rate in the opposite
    direction. (Generally considered "bad") Naturally, you want all
    your math to work correctly and never generate an overflow. But if
    you made a mistake? An unanticipated, "out-of-range" condition?
    If your math saturates, chances are you're doing the right thing -
    or at least the least harmful thing.

    Hope this explains it. Maybe more hardware designs (or language
    designs?) will one day provide this sort of behavior for us
    control geeks.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "That which belongs to another."

        --  Diogenes, when asked what wine he liked to drink.
===============================================================================