From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/27 Message-ID: <97032709031579@psavax.pwfl.com>#1/1 X-Deja-AN: 228750166 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-03-27T00:00:00+00:00 List-Id: Nick Roberts 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. ===============================================================================