Scalar concept should be renamed

[kwikius]

The 'units::Scalar' concept definition has nothing to do with any external definition of scalar and is very misleading,
https://github.com/mpusz/units/blob/master/src/include/units/quantity.h#L63
should be renamed to RegularNotQuantity or something similar especially since Vector is an allowed rep type
https://github.com/mpusz/units/blob/master/example/linear_algebra.cpp#L205

[mpusz]

I agree! As I mentioned in one of our previous discussions let's find a good name for it first :-)

[kwikius]

First figure out the semantic
What is currently Scalar concept is confused.
You unnecessarily try to stretch it too many ways so will never find a semantic good fit
#88

Unless you change your mind on that one ... Good Luck

[mpusz]

Scalar semantics is the minimum semantics of the representation type as described here: https://mpusz.github.io/units/use_cases/custom_representation_types.html#a-scalar-concept. As I said several times I am not married to that name and will be happy to change it.

Please note that it is being used both as a quantity representation type:

https://github.com/mpusz/units/blob/84c8a0632e71aeb136ddfb74f140f73103be2a6b/src/include/units/quantity.h#L63-L64

and as a value (not a quantity) in operators, i.e.:

https://github.com/mpusz/units/blob/84c8a0632e71aeb136ddfb74f140f73103be2a6b/src/include/units/quantity.h#L325-L327

[mpusz]

We could name it as units::Value or units::Representation, although the second name would look strange in the operator case.

[JohelEGP]

units::Representation as an exposition-only concept feels right to me.

We could name it as units::Value or units::Representation, although the second name would look strange in the operator case.

Maybe name it units::QuantityRep.

[kwikius]

Scalar semantics is the minimum semantics of the representation type as described here: https://mpusz.github.io/units/use_cases/custom_representation_types.html#a-scalar-concept. As I said several times I am not married to that name and will be happy to change it.

Please note that it is being used both as a quantity representation type:

https://github.com/mpusz/units/blob/84c8a0632e71aeb136ddfb74f140f73103be2a6b/src/include/units/quantity.h#L63-L64

and as a value (not a quantity) in operators, i.e.:

https://github.com/mpusz/units/blob/84c8a0632e71aeb136ddfb74f140f73103be2a6b/src/include/units/quantity.h#L325-L327

Theses two uses can be different concepts as shown here
b09c4af

[yasamoka]

One vote for units::Value.

[JohelEGP]

Consider #29 (comment) and its two following comments. Here's my current view:
@kwikius opens with

should be renamed to RegularNotQuantity

and later mentions (#114 (comment))

Theses two uses can be different concepts [...]

If quantity is to work with any algebraic structure, the Scalar in the declaration of quantity is nothing but a std::regular that's not a quantity. In other words, it's currently overconstrained. quantity doesn't support arbitrary algebraic structures with this use of Scalar. The other ones in the operators * and / make sense.

Does it make sense to use quantity without the dimensional analysis aspects? Like instantiating it with an ordinal number, which doesn't have * and / (although it can have them, but not with the meaning of Scalar or field). This looks like it is solved by quantity_point, maybe. I don't know arbitrary use cases and only have some knowledge of algebraic structures thanks to Wikipedia. It might make sense for some. Do note that https://en.wikipedia.org/wiki/Algebraic_structure mentions

The examples here are by no means a complete list, but they are meant to be a representative list and include the most common structures.

Perhaps it's possible to come up with ones that do make sense.

[mpusz]

Does it make sense to use quantity without the dimensional analysis aspects? Like instantiating it with an ordinal number, which doesn't have * and /

I decided to require * and / because we do not have to multiply or divide 2 quantities explicitly to use those operations. It is enough to:

length<metre> q(1q_km);

I do not think there is a sense of having quantities without unit conversions?

This is why I assumed that even though + and - are optional, * and / are inherent for quantities and should always be valid.

[JohelEGP]

I agree. The above is hypothetical, and the fact is that such relaxation hasn't been formally requested by an user for their use case. Now then, this issue is about naming, but I mixed other concerns.

[JohelEGP]

My preference right now is the adjective Scalable. What do you think? I think it's divorced enough from Scalar, yet retains the property needed of it. Better yet would be ScalableNumber, since quantity has a number and reference (Unit here).

[mpusz]

I like Scalable or even better scalable when we move to standard_case. ScalableNumber may collide with some use cases. For example https://mpusz.github.io/units/use_cases/linear_algebra.html#quantities-of-linear-algebra-types. Is a matrix a number?

BTW, why no one refers to the official ISO terms provided in our own documentation: https://mpusz.github.io/units/glossary.html#term-quantity. 😝

[mpusz]

However, Scalable term does not imply "not a quantity" :-(

Maybe we have to go with something like QuantityValue, QuantityNumber, QuantityRep.

[mpusz]

After a second thought, I am leaning towards ScalableNumber. This LA example should not stop us :-( Especially that I am not sure if this example (Quantities of LA) has a lot of sense.

[JohelEGP]

I do agree with @kwikius opinion that it should me matrix<length> and not length<matrix>. But I also prefer the output {1, 2, 3} m over {1 m, 2 m, 3 m}. matrix<length> can provide that, though, by having a grammar to defer format specification to the underlying type.

[JohelEGP]

Is a matrix a number?

NOTE 5 A quantity as defined here is a scalar. However, a vector or a tensor, the components of which are quantities, is also considered to be a quantity.

No, it's a quantity.

[mpusz]

NOTE 5 is about vector<length> and yes it is a quantity.

I referred more to the length<vector> case. vector in such a case should satisfy ScalableNumber. But anyway, let's stay with ScalableNumber for now and get rid of this Scalar thing. We can always revise it later too and probably the ISO Committee will try to bikeshed it too... ;-)

[JohelEGP]

Oh, but a vector<int> is a number, and it is scalable ("may be added, subtracted and scaled (i.e. multiplied by a real number)"), so ScalableNumber is a perfect fit.

[mpusz]

Thanks @JohelEGP! I am doing this change right now.

[JohelEGP]

BTW, why no one refers to the official ISO terms provided in our own documentation: https://mpusz.github.io/units/glossary.html#term-quantity. stuck_out_tongue_closed_eyes

It's just that I first came up to the BIMP when working on my first Quantity concept, have since kept it around in a bookmark, and know that an ISO publication is based on it, similar to how the C++ standard working draft is kind-of independent work of the C++ committee which is then published as an ISO standard.

[mpusz]

Sure, no worries :-) Thanks again!