- 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.
- 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.
* XRPLF/ximinez/number-round-maxrep-down:
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"
* XRPLF/ximinez/number-round-maxrep-down:
Clean up the "New" names
Update to use a new amendment, since this PR will not be part of 3.2.0
fix: Fix Number comparison operator (7406)
feat: Use C++ 23 standard (7431)
refactor: Introduce XRPL_ASSERT_IF for amendment-gated assertions (7378)
refactor: Change config section and key string literals into constants (7095)
refactor: Use `std::move` and `std::string_view` where possible (7424)
refactor: Use const function arguments where possible (7423)
ci: Use XRPLF/actions build-multiarch-image workflow (7428)
ci: Use new packaging images and don't cancel develop builds (7417)
ci: [DEPENDABOT] bump codecov/codecov-action from 6.0.1 to 7.0.0 (7426)
* ximinez/number-round-maxrep-down:
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
build: Create single test binary xrpl_tests (7327)
ci: [DEPENDABOT] bump actions/checkout from 6.0.2 to 6.0.3 (7414)
ci: Refactor build-related nix / docker / workflows (7408)
refactor: Construct Number::Guard from MantissaRange or relevant fields
ci: Use multiple directories in dependabot config (7413)
ci: Update clang-tidy to nix-based v22 (7412)
clang-tidy: template param names, const correctness, braces
- 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.
- Treat values in between kMaxRep (2^63-1) and kMaxRepUp (((kMaxRep
/ 10) + 1) * 10, which is the next multiple of 10 above kMaxRep) as if
those values were sequential, and values in between were "fractional".
- This results in values above the midpoint rounding up to kMaxRepUp,
and below the midpoint to kMaxRep when rounding to nearest. Other
rounding modes act along the same lines.
- Also refactor "Number::Guard::round()` to return an enum making it
clearer what's going on.
