one thing I found is that all FLOAT (and probably DOUBLE) values are returned as string
That does make a certain amount of sense.
If you converted floats to their binary numeric representation, then you could introduce typical floating point representation errors. If you are going to do math with them in your perl code, then that will happen anyway and you'd have to deal with it.
But if you are only going to display them, or store them into another table somewhere, then returning them as strings means that you don't have to deal with those errors.
Whether that is the reasoning behind it I cannot say, but it could be.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I would expect this to be the case for Fixed-Point values (DECIMAL and NUMERIC types), but not for FLOAT and DOUBLE, which already suffer from floating point representation errors because, well, that's what they are (even inside MySQL).
| [reply] |
They may be stored on disk as IEEE floats (or some other binary representation), but if they are defined as FLOAT(7,2), then the DB needs to return them to you in that form. Ie. with no more than 2 decimal places.
But if the value arises due to math internal to the DB, then the binary representation may contain more than two decimal places. just as when you do math in perl. Eg.
$n = 1/10;;
printf "%.17f\n", $n;;
0.10000000000000001
So, when it returns a value it needs to round or truncate to meet the column type, and the easiest way to do that is sprintf which returns a string.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
