comp.lang.ada
 help / color / mirror / Atom feed
From: "James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com>
Subject: Ada 64-bit IEEE compliant float & Oracle
Date: Mon, 04 Aug 2003 12:16:05 -0500
Date: 2003-08-04T12:16:05-05:00	[thread overview]
Message-ID: <3F2E94D5.610F50F4@raytheon.com> (raw)

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%
---------------------------------------------------------------------------






             reply	other threads:[~2003-08-04 17:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-04 17:16 James A. Krzyzanowski [this message]
2003-08-04 19:49 ` Ada 64-bit IEEE compliant float & Oracle Stephen Leake
2003-08-04 23:32 ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox