-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I miss value_cast<ToQ>
and potentially value_cast<ToQP>
#568
Comments
Quantity type can be changed with a |
I am not so sure if a translation between vector spaces is a cast operation? |
|
Here, my line of though is again in "representation" vs "semantic meaning". For me Of course, this only applies as long as the reference points are all embedded in the same vector space; exactly the same requirement as for |
Sure, I understand. Do you have good motivating examples for such a use case, as I will need to defend this in the ISO C++ Committee? Said otherwise, do you often change both a unit and a representation type? |
We cross-posted, but the second paragraph (minus the point-origin discussion) also is the motivating example for the E.g. a lidar sensor could output as |
OK, so we can consider adding those overloads. I would prefer to be conservative first and require quantity specs to be exactly the same. Unless you have a good motivation example for the implicitly convertible ones? Unfortunately, I am unable to implement those things now as we have an ISO C++ Committee mailing deadline 12 days from now, and I scope on writing the next revisions of the papers. It sucks, but most of my time lately is spent on writing those papers instead of extending the library. And the backlog of things to design and implement grows all the time... Can you provide a PR? |
I'll try. I do have a deadline for this refactor myself (a customer needs a firmware update in just 7 days from now). |
Thanks a lot! And good luck. A week for a refactor is not that much at all. |
How do I test "equality" of quantity specs? |
Just use |
I see that the library now offers casts that are explicit in what they do - I like! I currently see the following overloads:
value_cast<ToU>
value_cast<ToRep>
value_cast<ToU,ToRep>
These exist for both quantities and quantity points. For quantities, I miss the overload
value_cast<ToQ>
, which is equivalent tovalue_cast<ToQ::unit,To:Q::rep>
, but shorter.Furthermore, I argue that
qp.point_for(ToPO)
is in fact also a cast of the same style: changing the representation without changing the meaning, but potentially raising truncation issues. Thus, I propose to add avalue_cast<ToPO>
to the overload set. If that is acceptable, then the correspondingvalue_cast<ToQP>(qp)
(approximately equivalent to eithervalue_cast<ToPQ::unit,ToPQ::rep>(qp).point_for(ToPQ::point_origin)
orvalue_cast<ToPQ::unit,ToPQ::rep>(qp.point_for(ToPQ::point_origin))
) would be even more valuable, as being more concise and potentially useful. That said, in those cases it is slightly more difficult to guess how severe the overall truncation is, and the two almost equivalent two-step casts may have different truncation behaviours, with neither being always better. That said, for floating-point types, thevalue_cast<ToPQ::unit,ToPQ::rep>
-part is usually considered value-preserving, so that there is no order ambiguity left. Even for integral types, it may be beneficial to offer a one-step cast, which may intelligently choose how to perform the cast best.The text was updated successfully, but these errors were encountered: