quantity: add definite constraint on q* "scalar" fixes https://github… #116

kwikius · 2020-05-28T16:19:12Z

quantity: add definite constraint on q* "scalar" fixes #88.

So the is_arithmetic constraint is too strong as is, rather should be a numeric concept ( allowing UDT number types as well), but showing that a multiply function needs strong constraints to avaoid ambiguity.
How to decide what to define in your librray?
Generally is the result in your domain e.g quantity * numeric -> quantity. but quantity * vector -> vector so that is the domain of vector. And behold it works ; -)

… kwikius!)

mpusz · 2020-05-28T18:22:42Z

src/include/units/quantity.h

@@ -324,7 +324,7 @@ template<typename D, typename U1, typename Rep1, typename U2, typename Rep2>

 template<typename D, typename U, typename Rep, Scalar Value>
 [[nodiscard]] constexpr Quantity AUTO operator*(const quantity<D, U, Rep>& q, const Value& v)
-  requires std::regular_invocable<std::multiplies<>, Rep, Value>
+  requires std::regular_invocable<std::multiplies<>, Rep, Value> && std::is_arithmetic_v<Value>


is_arithmetic cannot be used here because it limits values only to built-in arithmetic types and not to all types that behave as such. Besides, not all arithmetic operations are needed in this case so this heavily overconstrains the function template.

mpusz · 2020-05-28T18:24:52Z

numeric concept will never happen (I and a few other folks were there already and failed miserably 😞).

Add a DimensionlessQuantity concept - multiplication by itself does not affect its dimension. Add an Arithmetic concept - the built in arithmetic types are models. Make Arithmetic models of DimensionlessQuantity. quantity: Constrain the ambiguous multiply ops to multiplication by DimensionlessQuantity.

kwikius · 2020-05-31T08:28:37Z

numeric concept will never happen (I and a few other folks were there already and failed miserably disappointed).

So just call it units::DimensionlessQuantity and stay low ;-)

Besides, not arithmetic operations are needed in this case so this heavily overconstrains the function template.

So you need to add a test case that shows how that 'overconstraint' causes a problem, becasue currently (EDIT :) all tests are passing , at least locally for me.

Have a Nice Day ;-)

mpusz · 2020-05-31T19:40:33Z

src/include/units/quantity.h

@@ -322,18 +322,18 @@ template<typename D, typename U1, typename Rep1, typename U2, typename Rep2>
  return ret(ret(lhs).count() - ret(rhs).count());
 }

-template<typename D, typename U, typename Rep, Scalar Value>
+template<typename D, typename U, typename Rep, DimensionlessQuantity Value>


Did you mean Arithmetic here? I do not think that in 2m * 2 a 2 is a dimensionless quantity... It is just a regular value/multiplier/ratio or however you want to call it (if not a scalar).

Did you mean Arithmetic here?

No I didnt. T : model of DimensionlessQuantity requires only
T x ;
Dimensionless y = x * x;
(note: eliding division for now)
Usually the following is true, e.g for arithmetic
T x ;
x = x * x;
( but not necessarily which allows dimensionless ratios such as radian and steradian)

I do not think that in 2m * 2 a 2 is a dimensionless quantity...

If you are asking : is the 2 in the above a DimensionlessQuantity?, Yes it is a dimensionless quantity , plugging the above requirement to an integer
int x = 2;
int y = x * x; // works fine

Scalar is a different concept to DimensionlessQuantity. A Scalar has magnitude but not direction
https://www.britannica.com/science/scalar

c++ arithmetic type is a model of Scalar and a model of DimensionlessQuantity
units::quantity with a Scalar Rep type is a model of Scalar but not a model of DimensionlessQuantity.

You could examine the rep type of the units::quantity to find if the quantity is a Scalar. If the Rep type is a scalar, then the units::quantity is a scalar, but If the Rep type is a vector or a matrix then clearly the quantity isn't a Scalar

mpusz · 2020-05-31T19:41:46Z

src/include/units/concepts.h

@@ -289,4 +289,21 @@ concept Scalar =
  std::regular<T> &&
  (detail::constructible_from_integral<T> || detail::not_constructible_from_integral<T>);

+ template <typename T> 
+ concept Arithmetic = std::is_arithmetic_v<T>;


As I wrote many times already we cannot constrain the library to fundamental types only. There are a lot of type-safe wrappers around fundamental types that have to work nicely here as well.

As I wrote many times already we cannot constrain the library to fundamental types only. There are a lot of type-safe wrappers around fundamental types that have to work nicely here as well.

There are 3 UDT math types I can find in current standard library with binary math operators

std::complex
std::chrono::duration
std::valarray

In each of those types binary operator functions are constrained in both their arguments ( Take a close look at how they are implemented rather than just the documentation). There is no precedent for your statement about unconstrained arguments in the standard library.

Types of https://www.boost.org/doc/libs/release/libs/safe_numerics/ and those being worked on by the WG21's Numerics SG should work as well. Like how std::chrono::duration's rep isn't limited to fundamental types.

Types of https://www.boost.org/doc/libs/release/libs/safe_numerics/ and those being worked on by the WG21's Numerics SG should work as well. Like how std::chrono::duration's rep isn't limited to fundamental types.

Sure.
We seem to be back to the Numeric concept at this point

https://www.boost.org/doc/libs/1_73_0/libs/safe_numerics/doc/html/numeric.html

So Here is an examination of how to do DimensionlessQuantity in a structural way, but allowing customisation ( e.g for the angle case)
Bear in mind I dont use Concepts much so it can no doubt be done better.

https://godbolt.org/z/Hxfj9K

Anyway it seems to show that it can be made to work if the will is there ;-)

Linked here (#27 (comment)) is QuantityRatio, an interesting test case for DimensionlessQuantity

mpusz · 2020-05-31T19:44:16Z

So you need to add a test case that shows how that 'overconstraint' causes a problem, becasue currently tests are passing , at least loocally for me.

Sorry, I missed all in my answer. Fixed it now.

Add a DimensionlessQuantity concept - multiplication by itself does not affect its dimension. Add an Arithmetic concept - the built in arithmetic types are models. Make Arithmetic models of DimensionlessQuantity. quantity: Constrain the ambiguous multiply ops to multiplication by DimensionlessQuantity.

international volume : Add barrel volume unit for quantity_ratio example

…wikius/units into kwikius_scalar_vector_multiply

…ing fail

… is causing fail" This reverts commit 92347ea.

This reverts commit f8c74e0.

…t fixes fail, locally

kwikius and others added 4 commits May 28, 2020 17:07

quantity: add definite constraint on q* "scalar" fixes #88

7089e2b

math.h function signatures refactored to use Quantity concept (thanks…

a9627c6

… kwikius!)

CHANGELOG updated

ed9f51c

Specialize common_type to satisfy comparison concepts (resolves #113)

86b9177

mpusz requested changes May 28, 2020

View reviewed changes

mpusz and others added 2 commits May 28, 2020 20:45

Compilation on gcc-9 fixed

10f93b5

mpusz requested changes May 31, 2020

View reviewed changes

kwikius added 15 commits June 2, 2020 09:28

DimensionlessQuantity concept : make this structural for gcc10

0f6efb7

quantity: add definite constraint on q* "scalar" fixes #88

c52f4ac

DimensionlessQuantity concept : make this structural for gcc10

ebf0d76

examples : add quantity_ratio for dimensionless quantity

3deff69

international volume : Add barrel volume unit for quantity_ratio example

Merge branch 'kwikius_scalar_vector_multiply' of https://github.com/k…

a9552cd

…wikius/units into kwikius_scalar_vector_multiply

DimensionlessQuantity : back out structural part, see if that is caus…

92347ea

…ing fail

back out Scalar to DimensonedQuantity mod

f8c74e0

Revert "DimensionlessQuantity : back out structural part, see if that…

c179497

… is causing fail" This reverts commit 92347ea.

Revert "back out Scalar to DimensonedQuantity mod"

2b0ee1d

This reverts commit f8c74e0.

linear_algebra example : avoid trivial conversion in ctor. See if tha…

2abb001

…t fixes fail, locally

redo backoit structural concept with new error message

bc77de1

linear_alg malfunction : dark poke vector ctors

f12120d

linear alg example : elide auntity of non_scalar for now

c5a4e7f

concepts : clean up DimensionlessQuantity concept

bb3108f

kwikius closed this Aug 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

quantity: add definite constraint on q* "scalar" fixes https://github… #116

quantity: add definite constraint on q* "scalar" fixes https://github… #116

kwikius commented May 28, 2020

mpusz May 28, 2020 •

edited

Loading

mpusz commented May 28, 2020

kwikius commented May 31, 2020 •

edited

Loading

mpusz May 31, 2020

kwikius May 31, 2020

mpusz May 31, 2020

kwikius May 31, 2020

JohelEGP Jun 1, 2020

kwikius Jun 1, 2020

kwikius Jun 2, 2020

mpusz commented May 31, 2020

quantity: add definite constraint on q* "scalar" fixes https://github… #116

quantity: add definite constraint on q* "scalar" fixes https://github… #116

Conversation

kwikius commented May 28, 2020

mpusz May 28, 2020 • edited Loading

Choose a reason for hiding this comment

mpusz commented May 28, 2020

kwikius commented May 31, 2020 • edited Loading

mpusz May 31, 2020

Choose a reason for hiding this comment

kwikius May 31, 2020

Choose a reason for hiding this comment

mpusz May 31, 2020

Choose a reason for hiding this comment

kwikius May 31, 2020

Choose a reason for hiding this comment

JohelEGP Jun 1, 2020

Choose a reason for hiding this comment

kwikius Jun 1, 2020

Choose a reason for hiding this comment

kwikius Jun 2, 2020

Choose a reason for hiding this comment

mpusz commented May 31, 2020

mpusz May 28, 2020 •

edited

Loading

kwikius commented May 31, 2020 •

edited

Loading