|Problems? Is your data what you think it is?|
Re^3: Unpack mysql binary column databy graff (Chancellor)
|on Apr 24, 2013 at 03:15 UTC||Need Help??|
Expected value for example is 369790944 but unpack returns 46223868
Taking a different look at those values might be instructive, given that they should have some sort of binary relation when treated as uint64 values. Here's a one-liner that will read the integer values typed (actually, pasted) into STDIN, and spit out the corresponding bit sequence for the given value:
Who could have guessed that the value actually returned by your unpack usage was identical to the value expected, except that it's missing the 3 lowest bits! What could be going on in your script (or in its interaction with the database) that might be causing this?
The double values involve some extra work (and I'm not sure I'm doing this the "right" way to suit your purposes...)
Hmm... let's try that another way...
The first line of 64 bits is the "expected" value, the second is the value returned by your unpack, and the third has a "1" wherever the previous two don't match. I'm not sure how informative that is, actually, but it's curious to see the amount (and position) of agreement between the expected and returned values.
Still, as I said, there's a serious chance that this particular pursuit of the bit patterns in doubles is misguided - e.g. I may be using a different notion of "double" from the one being used to populate those binary fields.
UPDATE: Regarding the doubles, please note that adding an extra decimal place of precision to either (or both) the expected and returned values that you quoted will affect the position and amount of (dis)agreement between the two corresponding bit strings. You should look at the actual bit string as stored in the database, and see how many significant digits it takes to render it accurately as a decimal number (assuming you know how to interpret the binary(8) string correctly, of course).
ANOTHER UPDATE: For that matter, removing significant digits has an effect as well. Just for grins, I rounded off the "returned" value to 64852.468504 (removing the 3 least significant digits), and with that, the three binary strings (expected, returned, diff) came out like this:
Now, you want to see something really curious? Recall that your two uint64 values would have matched perfectly if the "returned" value had simply been shifted up 3 bits -- i.e. multiply by 8. Well:
If you ever succeed in coming up with an explanation for this, you will have surpassed me. Have fun with that.