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,d853e66024dcd092,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-04 10:16:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3F2E94D5.610F50F4@raytheon.com> From: "James A. Krzyzanowski" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Ada 64-bit IEEE compliant float & Oracle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 04 Aug 2003 12:16:05 -0500 NNTP-Posting-Host: 151.168.132.188 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1060017366 151.168.132.188 (Mon, 04 Aug 2003 12:16:06 CDT) NNTP-Posting-Date: Mon, 04 Aug 2003 12:16:06 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:41173 Date: 2003-08-04T12:16:05-05:00 List-Id: OK folks, Here's what I hope you'll consider an interesting problem. I hope that someone else has already tackled this issue so we can have some alternative solutions to choose from. Problem: We are using Rational Ada and the IEEE compliant definition for 64-bit floating point numbers. We recently changed our DB to Oracle which uses a proprietary format for storing floating point numbers with greater precision than the average software system could possibly need. Oracle uses 17 bytes to store floating point numbers; but I have read documentation that they use 126 bits (not 136) to store floating point numbers. We have declared new types based on the IEEE standard 64-bit float that have constrained ranges. For example, we have: type Radian_Type is new Float_64_Bit range -2_Pi .. +2_Pi; subtype Latitude_Type is Radian_Type range -Pi_Over_2 .. +Pi_Over_2; subtype Longitude_Type is Radian_Type range -Pi .. +Pi; When we store Latitude_Type'Last in the DB and then retrieve it, we get a Constraint Error. Possible Solutions: 1) Extend the range of Latitude_Type & Longitude_Type slightly (by some Epsilon) and prohibit ever using 'First or 'Last. ==> easy solution; kind of a kludge 2) In the interface with the DB, catch the exception and assign to 'First or 'Last as necessary. ==> not sure if we can determine if constraint was on the negative side or positive side 3) On the DB side, specify 18 digits of precision and force the 18th digit to be zero or 4 or 5 and rely on rounding for consistent results. ==> twiddling with digits seems like a kludge and will add processing time to an already slow interface 4) When storing floats to the DB, use unchecked conversion to 64-bit integer and store it. Do the inverse on retrieve. ==> provides exact digital equivalence, but prohibits taking advantage of any built in DB operations for floating point processing since DB would no longer realize number is a float Any comments or ideas out there? -- --------------------------------------------------------------------------- James A. Krzyzanowski - Staff Software Engineer - AFATDS %c% [*=] Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446 cus mailto:James_A_Krzyzanowski@raytheon.com %s% ---------------------------------------------------------------------------