Open PeterSommerlad opened 8 years ago
mmha
commented
7 years ago This is probably the best place to write this down right now (we should create a new github repository for that).
One thing we haven't considered during Liaw is potential support for currencies. They are an interesting use case because they only require limited precision, but well defined rounding, and their conversion factors can change during runtime.
johnmcfarlane
commented
7 years ago Requirements for currencies is subtlety different to units. The constant scaling factor is normally a power of ten. It isn't always the power you'd expect: sometimes it's tenth of a penny, say. Rounding like you say sometimes requires one off cases. (This is assessed by the numeric TS free functions.) But most significantly, conversion isn't constant.
On Thu, May 25, 2017, 7:21 PM Morris Hafner notifications@github.com wrote:
This is probably the best place to write this down right now (we should create a new github repository for that).
One thing we haven't considered during Liaw is potential support for currencies. They are an interesting use case because they only require limited precision, but well defined rounding, and their conversion factors can change during runtime.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nholthaus/units/issues/8#issuecomment-304173533, or mute the thread https://github.com/notifications/unsubscribe-auth/AAszN150xlVfWKWI4xsv5D2AJsqu2yt_ks5r9jcVgaJpZM4IVXni .
mmha
commented
7 years ago We already don't have a scaling factor that is a power of ten (Imperial units and the conversion from/to SI) in every case. Once you try to deal with natural units, you also have irrational numbers, which should not be approximated with std::ratio, because you will overflow the integer pair once you try to do math with them.
(This is assessed by the numeric TS free functions.)
I have found P0105R0 which addresses rounding. It says:
The unmotivated modes all_away_zero [...] are conditionally supported.
Which is AFAIK the rounding mode used to convert from the national currencies to the Euro (I don't write financial software, but there does not seem to be a general convention/regulation regarding rounding, which surprises me).
Yes, the non constant conversion factor is the most important difference. I would just like to see a discussion if and how we could enable the user to use the conversion framework and have non-constant conversion factors with user defined types.
EvanBalster
commented
6 years ago Hey, Peter —
I'm super interested in getting involved in the std::units effort. Any news since 2016?
Nic, myself and Steven Watanabe have been experimenting with methods to allow arbitrary sets of dimensions to be defined and used together with the units library. See here for more details and a fork with the feature: https://github.com/nholthaus/units/issues/88
I think there are other, closely related features like vector spaces and complex analysis that relate closely to this topic and would be interesting to discuss in the context of the units library.
JohelEGP
commented
5 years ago It'd be great if you could share more on this so that we could help.
I've been thinking on how units could undesirable for standardization. To start with, the current design introduces its own time units, when the standard already has std::chrono::duration. A redesign that takes it into account is in order.
There's much that needs to go if you're going to show units as is to the committee. Reducing the scope of a proposal to some bare essentials while still maintaining its value and extensibility (program-defined units and dimensional analysis support in the case of units) increases its chances of being accepted by removing features that potentially hold it back.
Take a look at std::chrono::duration and back at units::length. When was the last time you saw units::megameter_t being used? Let's offer only commonly used aliases, like std::chrono does.
There is value to units' users in offering all the exotic units (as seen from all the requests #205 #181 #157 #151 #147), but not for the standard, which aims to be more generally useful and broadly applicable. One argument against is that some units' definition might might change with time, albeit insignificantly for most application, as our measuring tools improve [citation needed].
A minimal scope I've thought of is the following:
std::chrono::duration per SI base quantity, like units::length, units::mass, etc.std::chrono does.unit for the non-base quantities that would result from using the dimensional analysis functions.There are some design questions that could be directed to LEWG and SG6, as we've come a long way since the introduction of std::chrono::duration:
The rest of units could be proposed in sections marked as optional, so as to not intervene with the acceptance of a core proposal.
Hi I am trying to start specification of a std::units library and just crossed your implementation. I would like to discuss your design goals and, for example, learn why you rely on std::ratio and provide dimensions for "dimensionless" things like radians. (I found you because of your questions why there is no standard conversion from std::ratio values/types to floating points, I believe that is an oversight that is now doable with variable templates at compile time, when it wasn't when ratio was first implemented and specified).
So far, I took a look at boost::units which is unusable because of its compile errors on misuse and also because it is quite oldish C++, my current option to start with is PhysUnit-CT-Cpp11 that I am adopting to C++14. You can reach me at peter.sommerlad@hsr.ch
Thanks Peter.