core: Flexibly define float constant objects. #18396
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
An identifier like
MP_CONST_FLOAT_eintroduces a floating point constant object. This is preferable to the previous method where, presumably, a human hand-created the constant values. It also facilitates introducing new floating point constant objects, assuming they can be written as literals (this is missed in ulab & circuitpython).Testing
I locally built coverage, nanbox, and longlong. The CI may turn up additional mistakes.
Trade-offs and Alternatives
The alternative of doing nothing is a powerful one, since nothing is broken. This was on my mind because there's a suggestion of making a new OBJ_REPR for 32 bit floats that avoids losing 2 precision bits by storing some floats "boxed" and others "unboxed", and furnished a way for me to learn a little bit about float representation.