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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-Thread: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-ArrivalTime: 2002-03-30 05:37:29 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!paloalto-snh1.gtei.net!lsanca1-snf1!news.gtei.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsfeed0.news.atl.earthlink.net!news.atl.earthlink.net!news.mindspring.net!not-for-mail From: "Michael Feathers" Newsgroups: comp.software.extreme-programming,comp.lang.ada Subject: Re: Ariane Failure Date: Sat, 30 Mar 2002 08:36:24 -0500 Organization: MindSpring Enterprises Message-ID: References: <3CA4B8E5.72909C9B@adaworks.com> <3CA50E9A.CBF24F1B@lanl.gov> NNTP-Posting-Host: d1.56.a3.ce X-Server-Date: 30 Mar 2002 13:39:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Xref: archiver1.google.com comp.software.extreme-programming:12794 comp.lang.ada:21887 Date: 2002-03-30T13:39:05+00:00 List-Id: "Bill" wrote in message news:3CA50E9A.CBF24F1B@lanl.gov... > > Michael Feathers wrote: > > > IIRC, there's also the issue of casting integers across sizes. It is great > > when you can hide representation and promote or demote its size as needed. > > > Promoting and demoting size as needed was part of the problem. Because of > limitations of typical launch vehicals, in particular their down link > capabilities to ground operations, but also limitted on board storage and > central processing, it is often necessary to reduce the size of a value from > larger storage representations to a smaller storage representations, typically > from floats or doubles to 8 or 16 bit integers. In order to ensure that the > real time constraints of the system are met, there has to be an explicit > decision as to what information needs to be communicated, at what rate, and > precision. It is tempting to maintain more precision than you need, just to be > certain you haven't misjudged the need, by applying an offset and scale factor > prior to the conversion to an integer, such that all possible values of the > rescaled number just fit within the range of values of the integer. However, > that decision is subject to the error of underestimating the range of possible > values of the original number before rescaling. In particular, a velocity scale > factor that was valid for the Ariane IV, for the actual and planned operating > conditions of the Ariane V, resulted in a value that exceeded the integer range > of the desired integer size, because the Ariane V has a larger acceleration and > more horizontal trajectory than the Ariane IV. > > Note that information hiding per se doesn't help with this. If the writer of > the software has made the explicit decision to rescale and the rescale factor > to use, but doesn't communicate that information to others so they can make no > decisions based on a knowledge of the rescale factor, the rescale factor could > still be inappropriate and cause breakage. Also designing the software to > automatically rescale using more global heuristcs, can cause other problems as > additional information about its decisions then needs to be communicated to the > ground station so that it can interpret the rescaled data. Yes. It seems like the error prone part is going back to integers at all. Since it is a safety consideration it seems like it would be great to revisit that as processing and communications speeds increase. Michael Feathers www.objectmentor.com