Add implementation and docs for Constant
#200
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the basic machinery for representing physical constants. Later on, we plan to include `Constant` instances in the library out of the box, but first we want to explore the feature in production inside Aurora's internal repo. The first set of basic features is to multiply and divide a wide variety of types. When we do this, the operations always take place _at compile time_, and symbolically. The next set of features is various kinds of conversions to `Quantity` types and/or raw numbers. The standout feature here is the _perfect conversion policy_: since each `Constant` fully encodes its value in the type, we know exactly which `Quantity<U, R>` instances it can convert to. Doc updates are included: I added a new reference page for `Constant`. I also updated the alternatives page. A couple libraries that were previously "good" are now "fair", because they use quantities for their constants, which is sub-optimal. mp-units moved from "best" to "good" because I think on balance we're now tied. On the one hand, they have actually included pre-defined constants. On the other hand, our core implementation is better because we also support converting to `Quantity` types. Once we include constants out of the box, I expect we'll be "best". Finally, I re-alphabetized the BUILD rules. This basically meant simply moving `//au:operators` to its rightful place; not sure how it ended up way up in the "C" section in the first place.
chiphogg
added
the
release notes: ✨ lib (enhancement)
geoffviola
approved these changes
Nov 27, 2023
au/constant_test.cc
Outdated
| // numerator of `1`, and would therefore always be zero. | ||
| // | ||
| // Uncomment to make sure the compilation fails: | ||
| // EXPECT_THAT((c / 2).coerce_as(meters / second), |
There was a problem hiding this comment.
Q: Can you elaborate on this code? Wouldn't coerce_as allow for truncation?
There was a problem hiding this comment.
The c / 2 is the only part that really matters here. I'll eliminate the rest --- it's quite a distraction. Nice catch!
Kinda neat that #200 ended up being a pretty big feature like this. Didn't plan it this way! 😁 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is the basic machinery for representing physical constants. Later
on, we plan to include
Constantinstances in the library out of thebox, but first we want to explore the feature in production inside
Aurora's internal repo.
The first set of basic features is to multiply and divide a wide variety
of types. When we do this, the operations always take place at compile
time, and symbolically.
The next set of features is various kinds of conversions to
Quantitytypes and/or raw numbers. The standout feature here is the perfect
conversion policy: since each
Constantfully encodes its value in thetype, we know exactly which
Quantity<U, R>instances it can convertto.
Doc updates are included: I added a new reference page for
Constant. Ialso updated the alternatives page. A couple libraries that were
previously "good" are now "fair", because they use quantities for their
constants, which is sub-optimal. mp-units moved from "best" to "good"
because I think on balance we're now tied. On the one hand, they have
actually included pre-defined constants. On the other hand, our core
implementation is better because we also support converting to
Quantitytypes. Once we include constants out of the box, I expectwe'll be "best".
Finally, I re-alphabetized the BUILD rules. This basically meant simply
moving
//au:operatorsto its rightful place; not sure how it ended upway up in the "C" section in the first place.
Helps #90.