Choice of database column types, part 2: float(53) (or BINARY_DOUBLE) versu

Question

Original post in this series:
http://forum.java.sun.com/thread.jspa?threadID=629958
Issue #2: float(53) (or BINARY_DOUBLE) vs float(126)
The original database design uses float(126) for several floating point type columns. Conversation with one of the database guys involved reveals that this was not a particularly conscious choice, but came when migrating an earlier database which simply used float as the column type.
From my perspective as a Java programmer who needs to work with this data via JDBC, the choice of float(126) as a type is poor as it (a) is probably overkill, storing unneeded precision and thus wasting space (b) is unrepresentable as a Java double type unless truncation error is introduced (c) might be the cause of subtle bugs.
Point (a) needs no further explanation.
For point (b), note that oracle's float(53), not float(126), is the float type that best corresponds with Java's (IEEE 754) double type.
Unfortunately, float(53) is NOT exactly equivalent to Java's double: Oracle internally uses binary coded decimal to represent numbers (float is essentially an oracle number type with added restrictions), which will not be the same bits as Java's double format (for a reference, see http://builder.com.com/5100-6388-5224536.html). This means that there can be conversion and rounding issues even when you use float(53) (see http://www.stanford.edu/dept/itss/docs/oracle/9i/java.920/a96654/oraint.htm#1000888 which states "Performing mathematical manipulations of the data directly in SQL format avoids the loss of precision that occurs in converting between SQL and Java formats").
For point (c), here is an example of how I think that subtle bugs can be introduced. Suppose that you do a query and among the results is some floating point type, internally stored in the db as float(126) but which can only be represented in a normal computer language program by a double type, which is equivalent to a float(53). (No one wants to use a class like Java's BigDecimal if at all possible because it is very awkward to use and is extremely slow as well.) So truncation has to occur. Then suppose that the programmer wishes to use that floating point value, unmodified, as part of a subsequent query, say in an equals condition. But now it may not equal because the value in his program has lost information present in the original, so the query does not work as expected. Of course, for this scenario, one could query based on "approximately equal" instead of exactly equal. But that assumes that the programmer knows to do this, and then even if he does, it is a pain to write, may be a performance hit, and subjectivity is involved (e.g. in how much being off you will tolerate). So, if it is at all possible to reasonably avoid this, yuo want to.
It appears that Oracle 10g now offers the BINARY_DOUBLE type which DOES exactly correspond to Java's double type; see http://builder.com.com/5100-6388-5224536.html
What are people's thoughts on the points that I raise above: is using a float(126) a suboptimal design choice, or are there no significant issues?
Anyone have experience with the new BINARY_DOUBLE type? (Unfortunately, we are currently using Oracle 9i so this may not be an option for us.)

Answer 1

Original post in this series:
http://forum.java.sun.com/thread.jspa?threadID=629958
You could have posted it as a reply to that post. :)
It's difficult managing to keep multiple posts close together.