confused with DOUBLE data type

Associate
Joined
26 Feb 2004
Posts
971
Location
China (Qinhuangdao)
I'll setup the background to my problem first, as it might explain my problem. We've been using a device to store a serial number of another device in it's memory. This has worked fine with numerical serial numbers, because the data type is double. However, the new equipment has serial numbers containing both alpha and numerical data.

So my first thought was to somehow convert these new serial numbers into a sort of code number which I could store as DOUBLE. My method to do this was to grab the ascii code of each letter / number as 3 digits, and just create a number containing all these digits. For example, if the code was Alf, the number would be 065108102. I found I kept loosing the zero, so I started my number with 999.

Now my problem with this is as follows. In Visual Basic 6, the help file has the following description for the DOUBLE data type :

A double-precision floating-point value with a range of –*1.79769313486232E308 to *–*4.94065645841247E-324 for negative values, 4.94065645841247E-324 to 1.79769313486232E308 for positive values, and 0.

So this should manage a short serial number. However, even with a number as short as "999097098099100101102" I get some kind of conversion error, where the string converted to DOUBLE becomes "999097098099100000000". I really don't understand why.

My test code is below :

Dim TestNoString As String
Dim TestNoDbl As Double

TestNoString = "999097098099100101102"
TestNoDbl = CDbl(TestNoString)

Debug.Print TestNoDbl
Debug.Print Format(TestNoDbl, "000000000000000000000")
Debug.Print TestNoString


So why is this not working? And is there a better way of converting and storing a serial number such as "A12345bcde4" as double?
 
Apart from the obvious question as to why you can't store in a string (maybe because a 3rd party program won't allow that), could you not convert the letter into it's count within the alphabet?

Agree that the number can't start with a zero, but common sense could calculate this by saying if the figure entered is of an odd number of characters then prefix a zero.

For your example of Alf:

A=01
l=12
f=06

This would be 011206

The prefixing zero would be dropped giving a value of 11206 (an odd number of characters) so write a little routine to add the zero on.

This would be a far smaller number than the 065108102 you've mentioned.

Just a quick thought, I'm sure there's a few more technicalities involved into why you may not be able to do this, but, dunno - may the simple ideas are the answer.
 
Doubles are designed to represent numbers with decimals. It appears that you are using whole numbers, so I don't know why you need a double in the first place. Surely a long would have been better?

IIRC doubles in VB6 are 32 bits and if you try to encode a string into a number that has more than 32 bits of information you will lose some of it in conversion.
The documentation you quote specifying the values for doubles are valid, but you're misinterpreting what that means.
A 300 digit number cannot be represented in whole using a double, so it stores it in scientific notation.
e.g. 35167 = 3.5167 * 10^4 and only stores the first few digits, so in your example 999097098099100101102 is stored as 9.990970980991 * 10^20, hence the issues you're getting.

There is some fun reading here: http://en.wikipedia.org/wiki/Floating_point if you want to learn more about this.

Long story short, if you want to store more than 32-bits of data, double is the wrong type for you.

EDIT: Better link
http://en.wikipedia.org/wiki/Double_precision
 
Last edited:
I think the rounding is due to converting the mantissa into a binary (base 2) number from base 10. 52 bits in base 2 is equivalent to 15.995 digits in base 10, meaning only the first 15 digits are represented with 100% accuracy.
 
Unless there are size or conversion issues, or any other issues for that matter, I'd say using a string or array of characters would be by far the easiest solution to this problem.
 
Back
Top Bottom