* 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)
* commit '5703ca5': (23 commits)
Number improvements
test: Add more Number edge case tests, showing failures
Also fix local 3_2_0 variable names
Future proofing: Rename Large and Enabled to Large330 and Enabled330
clang-tidy: rename MantissaScale enums from "3_2_0" to "320"
Clean up the "New" names
Update to use a new amendment, since this PR will not be part of 3.2.0
clang-tidy: Guard public member variable names; Missing include
Clean up tests
Reorganize the subtraction tests
Fix formatting, add an assert
Revert "Rollback Number class changes; show the fix works without side effects"
Rollback Number class changes; show the fix works without side effects
Include rounding in failed unit tests
Improve comment descriptions
Rework subtraction rounding (again) for more accuracy
refactor: Construct Number::Guard from MantissaRange or relevant fields
clang-tidy: template param names, const correctness, braces
Remove the kMaxRep+1 rounding tests
Improve accuracy of Number::operator+=
...
* 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.
