Closed chiphogg closed 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.
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.
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.
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:
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.
@chiphogg, could you please submit issues for those, as your comments will "disappear" when I merge this PR.
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.
4.6: 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).6.4.1: I don't understand the meaning of the equality operator for dimensions, nor its implementation. Does it not break transitivity, which is a critically important property for an equality operator? If B and C both derive from A, then each would compare equal with A, but not with each other. Do we even want equality of dimensions? Wouldn't we be better off by providing separately named functions for different kinds of equivalence?
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.
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?
7.5.1: Multiplication of vectors is mathematically defined using geometric algebra. The product is the "geometric product". It produces, essentially, a complex number (the sum of a real part and a bivector part, the latter of which encodes information about the plane spanned by the vectors). This is part of my worry with the system of characters: there's not Just One System in mathematics, and we may exclude or make awkward certain important use cases.
7.5.2: If we do go this route, I expect we'll want more characters than just scalar, vector, and tensor. 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.