Comments (9)
@mpusz, here you have pointed out that
quantity
takesRep
as a template parameter and maybe it could be some vector representation there.
Option 1 will not allow it, because division is not defined (mathematically speaking) for vectors. This is the first reason, why I would prefer Option 2.
The second reason to prefer Option 2 is that it can potentially provide a way to have non-additive quantities and stuff like that. E.g. it would make sense to prohibit adding absolute temperatures to one another using a restrictive Rep
for quantity
.
from mp-units.
This looks super interesting! 😃
I think it should turn into a PR in order to prototype something and see how it looks, feels, and works with the current code.
from mp-units.
@i-ky Thanks for your feedback! Regarding "second reason" we will probably solve the temperature problem with a dedicated affine space support. There will be no need to restrict Rep
type for it.
from mp-units.
I guess by "temperature problem" you mean conversions between unit that have different zeros. I had a different thing in mind.
Imagine we have two temperatures (could be air temperatures in different places or on different days). What would adding them up mean? Does the sum of two temperatures have physical meaning? I think no. However, it makes sense to multiply temperature by Bolzmann constant and number of particles to get heat energy, which can be added together. Or you can multiply temperature by duration of time during which it was constant, add these numbers (in K*s
) together and divide by total time to get time-average temperature.
Your library provides conversions between different units. Maybe someone will be able to come up with a clever fool-proof type system for thermodynamics or other domains.
from mp-units.
Even more "illogically", it seems that it's sometimes appropriate to "subtract" temperatures:
eg Spec Heat Capacity = m * C * dt
I think these "illogical" exceptions are probably not the concern of a unit library?
from mp-units.
The current approach seems like the right one. By constraining an operator on the representation's operator, units::quantity
can work with any algebraic strucutre. Maybe it is the algorithms that should be constrained on algebraic structure concepts. I'm wondering how to fit dimensional analysis into those without having an explosion of concepts.
from mp-units.
Perhaps one can fit dimensional analysis into those like this:
export template <class T>
concept quantity_field = std::regular<T> && requires(const T& c, T& l) {
// zero<T>, one<T>, +c, -c, l+=c, l-=c, c+c, c-c
{ c * c } -> std::regular;
{ c / c } -> std::regular;
{ c * c / c } -> std::common_with<T>;
};
export template <class T>
concept field = quantity_field<T> && requires(const T& c, T& l) {
{ l *= c } -> std::same_as<T&>;
{ l /= c } -> std::same_as<T&>;
{ c * c } -> std::common_with<T>;
{ c / c } -> std::common_with<T>;
};
from mp-units.
My first try was to reuse http://wg21.link/P01813 but those concepts were overconstrained for our needs. After that, I went with Scalar
concepts, and even though this is a really bad name (please help me find a better one) it seems to work nicely here.
It does not mean the Scalar
concept is perfect though so if you would like to refine it please, feel encouraged to do so.
from mp-units.
The current approach seems like the right one. By constraining an operator on the representation's operator,
units::quantity
can work with any algebraic strucutre.
Things have changed since.
We have quantity
and quantity_point
,
documented to model a vector space and point space, respectively (https://mpusz.github.io/mp-units/2.0/users_guide/framework_basics/the_affine_space/).
So now we know that we require the number to model those (and not just any algebraic structure).
We further support operations on a scalar quantity and modulo.
I have been working on my own number concepts for quite some time now.
I have included them in some of the code fragments I share here.
I once shared the specification at https://cpplang.slack.com/archives/CBGC8H3T7/p1640214020006000.
I recently improved naming based on hsutter/cppfront#231 (comment)
E.g., negatable
-> negative
representing negative (IEV 102-01-14).
And I concurrently improved the hierarchy based on the discussion at #468.
E.g., I split relative_quantity
, which required division,
into vector_space
(which doesn't require division)
and f_vector_space
(which does require division; search for "F-vector" at https://en.wikipedia.org/wiki/Vector_space).
In case you're interested in how I constrained quantities before,
expand the "Cpp1 quantity" at hsutter/cppfront#658 (comment).
This is how I'm constraining the numbers now: https://godbolt.org/z/W4anGEsss.
- The number of
vector
(analogous ofmp_units::quantity
) is constrained withvector_space
,
representing a vector space (IEV 102-03-01). - The number of
point
(analogous ofmp_units::quantity_point
) is constrained withpoint_space
,
representing a point space (IEV 102-03-02). - The increment and decrement operators require
number_line
,
which aren't subsumed byvector_space
orpoint_space
.
It's the best name I could come up with, based on https://en.wikipedia.org/wiki/Number_line. - Addition and subtraction require
vector_space_for
.
A more appropriately name might bevector_for_point_space
.
Note thatvector_space
subsumespoint_space
.
We accept anything that behaves like a vector for the point space number.
E.g., given the vector spaceint
, all integer types behave like a vector for its point space operations.
This might be more evident in the interface ofpoint
. - The unary minus is unconstrained because
vector_space
subsumesnegative
. - Multiplication requires
scalar_for
to represent a scalar for a vector space. - Division requires
field_for
to represent a scalar for an F-vector. - Modulo requires
modulus_for
to represent the modulus of an integer (or whatever else models it).
There might be room for improving this hierarchy of number concepts:
- Vector space is defined with a given scalar.
But in the type system, we have a multitude of scalars.
E.g., given the F-vector spaceint
, all integer types behave like a scalar for its multiplication and division.
Vector space also has vector binary operations that result in vectors.
Again, all integer types behave like vectors with each other.
How de we name all these concepts?
Being verbose for clarity, I'm thinking of:vector_space
for the base case of a vector space with its "obvious" scalar.vector_space_with_scalar
when we accept scalar types for the number (e.g., implementingquantity::operator*
).vector_space_with_vector
when we accept vector types for the number (e.g., implementingquantity::operator+
).
- Given the previous item,
I can removefield_for
and constrain division withscalar_for_f_vector_space
.
That can be implemented in terms off_vector_space_with_scalar
.
Note thatfield_for
is minimal.
It doesn't require that the non-field argument is a vector space.
That is expected to be part of another, possibly more constrained, requirement. - The previous two points might apply to other concepts; definitely to
point_space
.
Anyways, I think using these concepts is an improvement over the status-quo.
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
- Metric Prefixes for Degrees Celsius HOT 15
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.