specifying units for the ISO standard about units

[mmha]

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]

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 ***@***.***> 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 <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAszN150xlVfWKWI4xsv5D2AJsqu2yt_ks5r9jcVgaJpZM4IVXni> .

[mmha]

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]

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: #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]

Code cleanliness and a lot of criticism from WG21 that it's not "modern" enough to act as a reference implementation for a future std library. I probably can't use 3.0 either for what it's worth.

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 sure are many ways of converting a unit to and from other units, dimensionless and arithmetic types. This might be overwhelming to an user.

yes. part of the problem of the evolution of the library and maintaining support for old compilers. I think this can be solved in documentation? My recommendation is to always take the implicit-conversion approach (for ease and readability) unless there's a good reason not to.

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:

• Offer similar templates to std::chrono::duration per SI base quantity, like units::length, units::mass, etc.
• Offer only commonly used convenient aliases to these templates, like std::chrono does.
• Have an opt-in trait for registering these templates as base quantities. With this, the dimensional analysis functions can work out the rest.
• We'd need a generic 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:

• Do we hand wave the requirements for Rep or do we use concepts? I have some concepts which fit current stuff and should fit what SG6 is working on.
• With fingers crossed for https://wg21.link/P1021 being accepted, the convenient aliases could be template aliases.

The rest of units could be proposed in sections marked as optional, so as to not intervene with the acceptance of a core proposal.