* XRPLF/ximinez/number-round-maxrep-down:
Change placeholder "fixNumberStuff" to "fixCleanup3_3_0"
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)
* 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.
- Go back to the old method of computing the mantissa, but when post
processing, expand the mantissa to slightly larger than maxMantissa,
then in doRoundDown, if the result is not exact, subtract one.
Finally, let doNormalize figure out the rounding of the result.
- Simplifies the function signatures in Guard, because it doesn't need
to have those values passed in constantly.
- Also simplifies some of the functions because they don't need to store
values just to pass them to Guard functions.
- 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.
