[AccessD] Single vs. double issue...

MS adheres to IEEE 745 Standard (well mostly) for floating point 
numbers. In some older compilers they
used BCD arithmetic or MSF binary storage format.
There is a formula for number of significant digits obtainable from the 
mantissa size
It is log base 10 (2^ bits in mantissa)
or   using vba calculation with natural logs
Debug.Print (Log(2 ^ 52) / Log(10)) ' double word number of significant 
digits 52 bit mantissa = 15

real*4 sign bit, 8-bit exponent, 23-bit mantissa
real*8 sign bit, 11-bit exponent, 52-bit mantissa
real*10 sign bit, 15-bit exponent, 64-bit mantissa

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccelng4/html/elconTypedouble.asp


DJK(John) Robinson wrote:

>Nothing to do with MS - time to ring *your* bell, guys!  :-)
>
>A single has 32 bits: 24 for the mantissa, 8 for the exponent.  The exponent
>determines the *range* of values you can have, while the mantissa determines
>the *precision*, and each has effectively to use one bit for its sign.  So,
>with 23 bits of mantissa to provide the precision, how many significant
>decimal digits does that represent?  About 7.  (Strictly speaking, a little
>less than 7, since 2**23 = 8,388,608, not 9,999,999.)
>
>So a 32-bit floating-point number (a 'single') CANNOT represent 666,656,666
>in all its *nine*-significant-digit glory.  Nothing to do with Access, nor
>even MS:  just math.  (The 24/8 split could in theory be chosen differently,
>but 24/8 is the IEEE standard, widely used.)
>
>The Access documentation alludes to this degree of precision in the number
>of significant digits it shows in its definition of single: just 7.
>
>Incidentally, Bobby, it's not decimal *values* you're storing, just values -
>which you may think of in decimal representation.  There's a serious
>question here:  are your actual values here integers, or do they have a
>fractional part?  If integers, then of course you should not be using
>floating-point at all, both for efficiency of storage and speed of
>calculation.
>
>The 64 bits of a double are split 52/11.
>
>HTH
>John
>
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert
>Sent: 17 March 2006 20:17
>To: 'Access Developers discussion and problem solving'
>Subject: Re: [AccessD] Single vs. double issue...
>
>
>The difference between Single and Double is not just the number of decimal
>places, but also the range of values to the left of the decimal point.
>
>A Single can store -3.402823E38 to -1.401298E-45 for negative values and
>from 1.401298E-45 to 3.402823E38 for positive values. 
>
>A Double can store -1.79769313486231E308 to -4.94065645841247E-324 for
>negative values and from 4.94065645841247E-324 to 1.79769313486232E308 for
>positive values. 
>
>That's the official word. I just tested what you report and can confirm that
>singles in a table are doing this very strange 'rounding'. It also happened
>when you use Single type variables in code. It makes no sense at all to me
>as 666,656,666 is only ~6.66E8, well within the supposed range of a Single.
>
>So at first blush this is a VERY SERIOUS bug in the Single data type!!!!!!!
>
>Anyone care to ring the bell at M$?
>
>Lambert
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bobby Heid
>Sent: Friday, March 17, 2006 2:54 PM
>To: 'Access Developers discussion and problem solving'
>Subject: [AccessD] Single vs. double issue...
>
>
>Hey,
>
>I always thought that the main difference between a single and a double was
>that the single had 7 digits  and the double had 15 digits of precision
>AFTER the decimal point.
>
>Normally, I store decimal values as double.  But for some reason, this
>particular field was set to single.  Our client found an issue with that
>field today.  They had entered 666,656,666 into the field.  When you look at
>the table, it is 666,656,600.
>
>As a test, I changed the field to double, entered 666,656,666, and saved it.
>The value stuck.  Then I changed it to single, got the smaller field size
>warning, and saved it.  When I looked at the table, the value was
>666,656,600.
>
>So, I think the issue is that I misunderstood what the precision meant in
>the single vs. double declaration.  I wanted to be sure that this was the
>issue before I just blindly convert them to doubles.  Am I correct?
>
>Thanks,
>Bobby
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada