- Get rid of MantissaRange::getRanges() function. Rewrite
getMantissaScale to use all constexpr values.
- In Number::Guard::round(), document the "intentional" shadowing of
"mode", and simplify one of the checks. Add an assert.
* XRPLF/develop:
test: Add null check unit test for `Oracle::aggregatePrice` (7306)
ci: Patch conan recipe for Nix to be able to use on macOS (7532)
ci: Run sanitizers on release builds too (7527)
fix: Correct hybrid offer deletion on credential expiry (6843)
ci: Make sanitizer flags lists in the profile, not a string (7449)
ci: Make configurations launch on certain event types (7447)
fix: Add [[maybe_unused]] to fix320Enabled for assert=OFF builds (7446)
ci: Add `gh` and `file` to nix packages (7444)
fix: Disable transaction invariants (7409)
perf: Dispatch "hasInvalidAmount()" on type tag instead of dynamic_cast (7402)
refactor: Retire fixUniversalNumber amendment (5962)
test: Do not create data directory for memory databases (7323)
ci: Launch upload-conan-deps on profile change (7442)
- Expand documentation.
- Refactor Number::Guard::round() to simplify.
- Set the Guard sign correctly in += for numbers with the same exponent.
- Only really relevant if both values are negative.
- In +=, when needed, expand one mantissa to a size large enough to have
a few extra digits, which can be used to determine rounding.
- If the exponents are still different, trim the other mantissa as
before until the exponents match.
- For subtraction (where the values' signs are different), pop digits
out of the Guard as necessary, but go far enough to have a few extra
digits again for rounding later.
- Finally, don't discard any "leftover" digits in the Guard when
normalizing, to avoid the 0.5....nnn problem.
- NumberAddDirectedSignWrong
- Addition of two negative numbers with the same exponent rounds
ToNearest in the wrong direction.
- Also include unit test cases with same exponent, and mixed signs.
- No rounding issues in any combination, because the exponent can't
change.
- NumberAddToNearestPicksFarther
- In scenarios where the two operands have different signs, and
significantly different exponents, you can end up in a situation
where the rounding looks like 0.5, which may round down to even, but
is actually 0.5....nnn, which should always round up, you get the
wrong result.
