Repository navigation
Conversation
…rmat DecimalCodec.EncodeDecimal wrote coefficients with more digits than the format allows, and exponents outside its range, without any check (only a Debug.Assert). In Release builds the excess bits overflowed into the combination/exponent fields and the server stored a different value, e.g.: 12345678901234567890123456789012345 -> DECFLOAT(34) stored 8345678901234567890123456789012345 30000000000000004E-17 -> DECFLOAT(16) stored 0.08000000000000004 1E400 -> DECFLOAT(16) stored 8.000000000000001E-353 The encoder now brings the value into the format's ranges without changing its numeric value (dropping trailing zeros of the coefficient, folding the exponent into the coefficient, clamping the exponent of zero), and throws OverflowException when the value cannot be represented exactly (too many significant digits, exponent overflow or underflow). Values that previously got corrupted although representable (e.g. 1E384 in DECFLOAT(16)) now work.
The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).
- decimal: converted exactly from its 96-bit integer and scale, so the
value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.
A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).
Random.NextInt64() never returns a negative value, so the random doubles were all positive. Use the full long range and assert both signs are covered.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1299. Based on #1304: a converted
doublecan have 17 digits, and must throw instead of being corrupted when sent toDECFLOAT(16).Summary
Fixes the explicit conversions from
decimal,doubleandfloattoFbDecFloat. They threw for every value without a fractional part, and they lost digits.Changes
decimal: converted exactly from its 96-bit integer and scale, so the scale is kept (1.10mbecomes110E-2).(FbDecFloat)decimal.Negate(0m)isFbDecFloat.NegativeZero.doubleandfloat: converted to the shortest decimal that converts back to the same binary value (the"R"format).1mArgumentOutOfRangeException1E01.10m11E-1110E-22.0ArgumentOutOfRangeException2E01e-20ArgumentOutOfRangeException1E-206e-161E-156E-160.1 + 0.23E-130000000000000004E-17-0.0ArgumentOutOfRangeExceptionWhy a 17-digit double throws for DECFLOAT(16)
0.1 + 0.2converts to30000000000000004E-17(17 digits), which does not fitDECFLOAT(16). Sending it to aDECFLOAT(16)parameter therefore throwsOverflowException(#1304).Firebird's own
CAST(0.1e0 + 0.2e0 AS DECFLOAT(16))rounds to0.3000000000000000;DECFLOAT(34)gives0.30000000000000004, the same digits as this conversion. The provider deliberately does not round: an explicit conversion of the value would lose information silently. Callers who want the server's rounding can round first, or let the server do it withCAST.Tests
FbDecFloatTypeTests(NoServer):decimal,doubleandfloatedge values: min, max, epsilon, negative zero, NaN and infinities,FbDecFloat16SupportTestsandFbDecFloat34SupportTests: converted values round trip through the server, and0.1 + 0.2anddecimal.MaxValuesent toDECFLOAT(16)throwOverflowException.