Comments (15)
That's already prevented, as is standard.
from mp-units.
Thanks for raising this issue. I was not aware that some software already uses prefixes for degrees Celsius.
ISO 80000-5: Thermodynamics explicitly states:
Prefixes are not allowed in combination with the unit °C.
So now we have a problem 😉 We can either be standard conformant or friendly to an established engineering practice. @chiphogg and @bernedom, do you have any ideas on how to proceed? Do you use prefixes for degree Celsius in your libraries?
from mp-units.
As a workaround, you can provide such a unit by yourself:
inline constexpr struct milli_degree_celsius final : named_unit<symbol_text{u8"m℃", "m`C"}, mag_ratio<1, 1000> * si::degree_Celsius> {} milli_degree_celsius;
inline constexpr auto mdeg_C = milli_degree_celsius;
See a full example here: https://godbolt.org/z/qzT3r1TG1.
from mp-units.
I find the explicit prohibition surprising. It makes me wonder what the rationale was. Is it just because they don't know whether to write "m°C" or "°mC"? 😅
We provide prefixes for Celsius and Fahrenheit in Au. It's pretty useful, and has never caused any problems as far as I'm aware.
from mp-units.
I don't know the rationale here, but it is officially prohibited by an international standard that we try to follow in our library. I think we should keep it as forbidden and discuss it at the nearest C++ Committee meeting in Wrocław.
from mp-units.
As a workaround, you can provide such a unit by yourself:
inline constexpr struct milli_degree_celsius final : named_unit<symbol_text{u8"m℃", "m`C"}, mag_ratio<1, 1000> * si::degree_Celsius> {} milli_degree_celsius; inline constexpr auto mdeg_C = milli_degree_celsius;See a full example here: https://godbolt.org/z/qzT3r1TG1.
Thank you for the example, I made an attempt but I was not working "low" enough and was running into the unit_can_be_prefixed
trait.
ISO 80000-5: Thermodynamics explicitly states:
Prefixes are not allowed in combination with the unit °C.
awesome, thanks! I really like having references like this in the documentation for the SDK I am writing.
from mp-units.
I've just provided a short info in the documentation on how to work around this limitation if needed.
from mp-units.
From the new docs:
some projects are not aware of those limitations
Maybe, but we don't really know that they're not aware, because we haven't asked them. Just as we haven't asked to find the rationale for this explicit prohibition.
Maybe they're looking at alternative credible sources, such as this NIST page, which explicitly declares,
Prefix symbols may be used with the unit symbol ºC and prefix names may be used with the unit name “degree Celsius.” For example, 12 mºC (12 millidegrees Celsius) is acceptable.
Or maybe they've weighed that unexplained prohibition against the obvious usefulness of these prefixes, and decided to take this approach:
(Not saying it is a stupid decision, since we don't know the reasons --- just taking an excuse to post a Nick Fury gif. 🙂)
Personally, I don't see any value in prohibiting applying any prefix to any unit. It's clear enough what it means. If end users find it useful enough to create a named unit which they call milli-degrees-celsius, it's not merely obnoxious to force them to reproduce the numerical value of that prefix, but it creates a new opportunity for error where none needs to exist.
Wouldn't it be satisfying to simply remove all of the unit_can_be_prefixed
machinery from the library, both simplifying the code and making the library more useful? 🙂
from mp-units.
Wouldn't it be satisfying to simply remove all of the unit_can_be_prefixed machinery from the library, both simplifying the code and making the library more useful? 🙂
Sure, we can consider doing this.
from mp-units.
I guess if we end up keeping the prohibition, then for consistency's sake with the standard, we would also need to prevent prefixing any prefixed unit --- so, micro<kilo<grams>>
and micro<kilograms>
(not sure if I spelled it right for mp-units) should both be prevented.
(Note: not proposing that we do this, just something that occurred to me just now. I personally still think "just let users apply any prefix they ask for" is likely best.)
from mp-units.
Yes, the standard explicitly states that we are not allowed to prefix an already prefixed unit. This is not allowed in mp-units as well and I think that we should keep it.
from mp-units.
The question is if we should remove unit_can_be_prefixed
trait, simplify the framework, and allow the user to prefix every unit.
from mp-units.
Even if we remove it, I still wouldn't like to provide predefined symbols for the prefixed versions of degree Celsius in the library. Users will need to define them by themselves.
from mp-units.
BTW, it is really strange that NIST explicitly names millidegrees Celsius while ISO 80000 explicitly forbids it.
from mp-units.
I agree with basically everything you've just said.
- If we already prevent prefixing prefixed units, we should keep doing that.
- No chance of predefining prefixed units for Celsius or any other explicitly-unprefixable unit.
- The conflict between NIST and ISO 80000 is indeed surprising.
Maybe omitting predefined prefixed units is how we honor ISO 80000, while letting users explicitly form them if desired is how we honor NIST. 🙂
from mp-units.
Related Issues (20)
- Can't compile with localization disabled HOT 1
- Can't compile with exceptions disabled HOT 1
- Linker error with base units for "numerical_value_in()" HOT 4
- Clarify concepts and casting rules of quantity kinds and types HOT 6
- I miss `value_cast<ToQ>` and potentially `value_cast<ToQP>` HOT 11
- Version bump HOT 7
- Allow configuring GSL library use HOT 2
- Configuration not propagated to compiler defines HOT 12
- std::vector<Q> doesn't satisfy Range concept HOT 2
- CLion and VSCode not working with v2.2.0 HOT 3
- Add type template parameter to conversion functions
- Provide `unit_interface`, `point_origin_interface`, and possibly more
- Inconsistent cmake_minimum_required HOT 2
- Arithmetics on `QuantityLike` and `QuantityPointLike` values HOT 1
- Implement simple vector and tensor types HOT 14
- Provide support for `import std;`
- cmake configure failure HOT 3
- AttributeError: 'CMake' object has no attribute 'ctest' HOT 2
- Can't compile with fmt v11.0.2 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mp-units.