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: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-Thread: 103376,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-29 17:02:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!news.uoregon.edu!not-for-mail From: Bill Newsgroups: comp.software.extreme-programming,comp.lang.ada Subject: Re: Ariane Failure Date: Fri, 29 Mar 2002 18:02:54 -0700 Organization: University of Oregon Message-ID: <3CA50E9A.CBF24F1B@lanl.gov> References: <3CA4B8E5.72909C9B@adaworks.com> NNTP-Posting-Host: clodius.lanl.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Trace: pith.uoregon.edu 1017450231 29877 128.165.58.113 (30 Mar 2002 01:03:51 GMT) X-Complaints-To: news@news.uoregon.edu NNTP-Posting-Date: Sat, 30 Mar 2002 01:03:51 +0000 (UTC) X-Mailer: Mozilla 4.79C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en Xref: archiver1.google.com comp.software.extreme-programming:12776 comp.lang.ada:21866 Date: 2002-03-29T18:02:54-07:00 List-Id: 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.