Gustav Brock
gustav at cactus.dk
Wed Oct 22 03:32:30 CDT 2003
Hi Marty Many thanks for the nice explanation. One just wonders why this "D" was brought into Access (where I see it documented nowhere). On the other hand it falls well in line with the original concept of Access "to give the user access from a single point to a variety of database engines" - at least that is how I understood it. /gustav > Here is a start. > http://h18009.www1.hp.com/fortran/migrating-va.html > I think, this has to do with different mantissa lengths on different > platforms. I have seen it used in Fortran and Oracle. Oracle has an > option NOG_Float. If your C program uses the D-floating format for > floating-point data, you should compile with the NOG_FLOAT qualifier. > This forces SQL to convert the double-precision data in the database > from the G-floating format used by Oracle Rdb to the D-floating format > used by C, and vice versa. > I wonder what happens on the new Win 64 bit platforms? > The VAX architecture defined two different "double precision" represen- > tations: The original D_FLOAT (inherited from PDP-11's), and the newer > G_FLOAT. They differ in the assignment of bits to mantissa and > exponent: G_FLOAT moved three bits from the mantissa to the exponent, so > you get a much wider dynamic range at the expense of a few less bits of > precision. This change was made because it turned out that the greater > dynamic range was more useful than the extra couple of bits. > more significant problem due to the change to G_float can occur in > programs which, intentionally or unintentionally, pass single-precision > (REAL*4) values as arguments to routines which declare the argument as > REAL*8. This often goes unnoticed when an F_float value is interpreted > as D_float, as the two datatypes have the same format in the first 32 > bits. But when an F_float is interpreted as a G_float, the value read > will be wildly different. For example, an F_float 1.0 is interpreted as > 128.0 in G_float! The most common case for this type mismatch, which is > a programming error, is when a REAL*4 constant such as 1.0 or 2.3E0 is > passed to a REAL*8 argument. To ensure that the datatype of a constant > is REAL*8, use the D exponent letter, for example 3.14D0, or use a > PARAMETER constant which is declared as REAL*8. If the caller and callee > are compiled together, the AXP compiler will warn about type mismatches > if WARNINGS=ARGUMENT_CHECKING is specified on the compile command line. > Gustav Brock wrote: >>Hi Mark >> >>You are welcome! >> >>I knew about the "E" trap (say, 3E4 which is 30000) but I have never read about the >>"D" trap which turns, say, 1D4 into 10000 (or 1E4). >>It's easy to figure out it means 10^4 but where may that be >>documented?? >> >>/gustav >>>Holy cow...I'm in awe. I remember a quote from this list a long time ago >>>that seems appropriate at the moment. It read something like "Gustav is a >>>legend...cha cha cha" >> >>>Thank you sir, >> >>>Mark