mpusz/wg21-papers

Follow up on items from review of #59 and #60

chiphogg opened this issue · 1 comments

chiphogg commented

As we work on the unified paper P3045, we should double check to make sure we don't lose feedback from previous versions.

Numerics paper

From this PR (#60), we have these outstanding pieces of feedback for the numerics paper.

  • 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.

Safety paper

From this PR (#59), we have these outstanding pieces of feedback for the safety paper.

  • 8.8.4: I have a hard time understanding the template parameters in the API. Sometimes kind is the 2nd parameter; sometimes the 3rd.

  • 8.10: What is the "modulo" of two vectors?

  • 8.10: More generally, the "character" feature seems more speculative. It may be better to omit or greatly reduce its presence here. As far as I know, we don't know of anyone actually using it in real code --- is that right? If so, we should at least highlight its speculative and untested nature.

JohelEGP commented

IIRC, some were solved in those PRs.

  • 6.4.3: What is a "canonical unit"? I'm not familiar with this concept.

See https://mpusz.github.io/mp-units/latest/appendix/glossary/#canonical-unit.

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

For reference unit, see https://mpusz.github.io/mp-units/latest/appendix/glossary/#reference-unit.

  • 8.8.4: I have a hard time understanding the template parameters in the API. Sometimes kind is the 2nd parameter; sometimes the 3rd.

See #59 (comment):

Providing a kind is optional for units. For example, you will not provide those for some natural units systems. The typical convention is to put the optional parameters at the end and this was the rationale here. We can refactor if we find it confusing

  • 👍1