- Rename MantissaRange::Get to MantissaRange::Access. The name doesn't
really matter, but since the intent of the class is to control access
to one function, this works.
- Exclude the MantissaScale enum from linting for
readability-enum-initial-value. clang-tidy was complaining that
"error: initial values in enum 'xrpl::MantissaRange::MantissaScale'
are not consistent, consider explicit initialization of all, none or
only the first enumerator", but I don't care. I just need Large to
match the last value.
- Add a static_assert in setCurrentTransactionRules, so that if another
MantissaScale is added (and Large is properly updated), the engineer
won't forget to add a case for it there.
- Move code around and add comments in `bringIntoRange` to make it
clearer that mantissas should not be 0, but fall back gracefully in
non-debug builds if they are.
- Make a test that checks for Large330 future-proof if more scales are
added later.
- 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.
- 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)
