Conversion now has both a value and a factor type #453
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
Initially, `ConversionFactor` and thus `Conversion::T` requred `PartialEq`. This makes sense for the conversion factor itself (i.e. scaling across units), however it breaks once you introduce complex numbers. Those can *still* be scaled just like normal numbers - you essentially just increase or decrese a vector length, but the conversion function cannot compare them - "Z_1 < Z_2" is not trivially decidable. It is, however, also not needed - unit scales are just that - scalars that scale. And those can be easily compared. This commit seperates `Conversion::T` into `Conversion::VT` and `Conversion::T` and moves the `PartialEq` requirements from `ConversionFactor` into `Conversion::TT` directly. This requires a lot of trait bounds added down the line, so im not 100% that this does not break anything down the line. There might be a nicer way to go about this, but i haven't found any. closes iliekturtles#452
|
Thanks for the PR. I kicked off the CI checks and will try to review this weekend. |
|
Should i rebase this and try again? Or do you have a different solution/idea/want for this? Not sure when i can schedule time again, but with any luck i can get it in before the weekend. |
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.
Initially,
ConversionFactorand thusConversion::TrequredPartialEq. This makes sense for the conversion factor itself (i.e. scaling across units), however it breaks once you introduce complex numbers.Those can still be scaled just like normal numbers - you essentially just increase or decrese a vector length, but the conversion function cannot compare them - "Z_1 < Z_2" is not trivially decidable.
It is, however, also not needed - unit scales are just that - scalars that scale. And those can be easily compared.
This commit seperates
Conversion::TintoConversion::VTandConversion::Tand moves thePartialEqrequirements fromConversionFactorintoConversion::TTdirectly.This requires a lot of trait bounds added down the line, so im not 100% that this does not break anything down the line.
There might be a nicer way to go about this, but i haven't found any.
closes #452
Please have a look and see if this is where it should go.
Things that still need to be done: