Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have the same casts in GetDecimal as in GetDouble #785

Merged
merged 2 commits into from Mar 24, 2020

Conversation

danielgindi
Copy link
Contributor

Support casts to decimal from float/double.

Rationale:
It is already supported for the other way.
Casting from decimal to float/double could result in data loss.
If that is supported, so why not the other way, where there's no data loss?

Signed-off-by: Daniel Cohen Gindi <danielgindi@gmail.com>
@bgrainger
Copy link
Member

Seems reasonable.

The conversions the other way were added to fix #664.

(Note that decimal has a much smaller range than a double or even a float, so some conversions might result in an OverflowException for extremely large or small values, but that would be expected.)

Signed-off-by: Bradley Grainger <bgrainger@gmail.com>
@bgrainger
Copy link
Member

I'm not sure why the Netlify checks are failing, but they don't need to block this PR.

Thanks for the fix!

@bgrainger bgrainger merged commit 65c5735 into mysql-net:master Mar 24, 2020
@danielgindi
Copy link
Contributor Author

(Note that decimal has a much smaller range than a double or even a float, so some conversions might result in an OverflowException for extremely large or small values, but that would be expected.)

It is true and untrue at the same time :-)
decimal has precision of up to 128 bits, while double is 64 bits and float is 32 bits.
So decimal stores more information, up to more digits before/after the decimal point.
But for math calculations - decimal will lose precision because it contains the actual digits, not the parts that make the actual number. So fractions in float/double could continue forever (i.e 1.333333333333333333333) while in decimal they have a fixed count.

In cases where the user cares about "money" precision, they can safely cast to decimal, and keep all the information. Casting back from decimal to float in this case will have a different number than the original float, but that is true when casting directly from decimal to float.

So there's potential data-loss in casting both ways, and it always sums up to what you intend to do with the number.

@bgrainger
Copy link
Member

So fractions in float/double could continue forever

Nitpick: this isn't actually true; float and double always have a finite decimal expansion (accessible using the "R" roundtrip format) and need at most 9 or 17 decimal digits (respectively). They do not store rational numbers precisely.

I think decimal always has more precision than a double (this is not something I've looked into), but it doesn't have as large a range: decimal can go up to 7.9228 x 10²⁸, while float can go to 3.4 x 10³⁸ (and double even greater).

@danielgindi
Copy link
Contributor Author

@bgrainger Let's agree that they weirdly mismatch in all categories :-)

@bgrainger
Copy link
Member

Fixed in 0.63.0; thanks for the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants