mpusz / wg21-papers

ISO C++ Committee papers by Mateusz Pusz
https://mpusz.github.io/wg21-papers
4 stars 7 forks source link

Update "quantity as numeric type" text for R1 #60

Closed chiphogg closed 10 months ago

chiphogg commented 10 months ago

The only actual edit I've made was to add a line in the common unit computation, which makes it easier to understand.

I've also collected a variety of feedback about other sections on the paper. This feedback was harder to translate cleanly into edits, but I wanted to find some home for it. Additionally, even if I could make edits, it may not be wise to do so, because we want to minimize changes before the committee discusses it next week. So I'll add this feedback to the PR summary.

JohelEGP commented 10 months ago
  • 6.4.3: What is a "canonical unit"? I'm not familiar with this concept.

It's not in the glossary. I suppose it's a generalization of coherent derived unit so that units like 10 L and 10 dm³ are equal in their "canonical" form.

  • 7.4: What does this mean? What is the "reference unit" of a unit? I'm not familiar with this concept.

Probably a redundancy. Quantities have a number and a reference. The reference can be a unit of measurement, which is always the case in mp-units.

mpusz commented 10 months ago

What are some concrete use cases for kind_of<...>? I have a hard time seeing the motivation --- both for this feature, and for the rules at the end (e.g., arithmetic with a kind and non-kind produces a non-kind).

kind_of probably will be rarely used explicitly by the user. It is used implicitly every time we write 42 * m and will be visible in the quantity type. Some other use cases could be:

void foo(QuantityOf<kind_of<isq::energy>> auto q);

if someone would like to state that any energy is fine here. However, all quantities should be implicitly convertible to the root of the tree, so probably the usage of kind_of is too puristic here.

Another use case could be for natural units where it is much harder to specify that we want to create a quantity of a kind.

mpusz commented 10 months ago

If B and C both derive from A, then each would compare equal with A, but not with each other.

That is a good point. We need to fix it. Thanks!

Do we even want equality of dimensions? Wouldn't we be better off by providing separately named functions for different kinds of equivalence?

There are no kinds of equivalence for dimensions. Either we talk about the same dimension or not. As we have values for those, I thought that the equality operator is of good use here.

mpusz commented 10 months ago

6.4.3: What is a "canonical unit"? I'm not familiar with this concept. 7.4: What does this mean? What is the "reference unit" of a unit? I'm not familiar with this concept.

Good point, we should provide a definition somewhere, and possibly also rename it if you know a better name. By the "canonical unit" I mean a scaled unit that consists of some reference unit (not necessarily created of base units as we use gram rather than kilogram here) and a magnitude. This allows us to compare various units for equality or compare their magnitudes to find the conversion ratio.

See here:

https://github.com/mpusz/mp-units/blob/ebc5757835764b78c9b4e9804ac0c95f6237730d/src/core/include/mp-units/unit.h#L262-L283

mpusz commented 10 months ago

7.5: Subjectively, the chapter feels awfully big for something so speculative. Are we sure we want to go into this much detail before we have accumulated much more (any?) real world experience?

I could either say nothing or explain as it is implemented now in detail as this is not common knowledge. I thought it might be better to get some early feedback from the Committee on this as well.

7.5.1: Multiplication of vectors is mathematically defined using geometric algebra.

I was not aware of that 😢

7.5.2: If we do go this route, I expect we'll want more characters than just scalar, vector, and tensor.

ISO 80000 specifies (in many places) only those three abstractions, which is why I recommend scoping on them first and extending only if we really need to.

The current setup would allow adding the result of a cross-product of two vectors to another vector, but this seems like a missed opportunity to prevent errors.

That is not true, as those quantities will not be of the same kind.

mpusz commented 10 months ago

@chiphogg, could you please submit issues for those, as your comments will "disappear" when I merge this PR.