refactor(security): improve figure in 7.8
JohelEGP opened this issue · 20 comments
- Parenthesize alternative terms to reduce confusion.
- Replace
_(an underscore) with
Do you mean like (height, depth, altitude) or height (depth, altitude)? I am not sure why height in this case should be favored. All of those names are aliases for the same quantity.
However, with the current implementation, the type in mp-units will be isq::height even when we use the alias names. Maybe it should be fixed? But this would prevent the simplification of expression templates.
So right now, isq::height / isq::altitude results in dimensionless, but after the change, no simplification would be done.
Is for better or for worse?
I used _ because I refer to explicit types and names in the library. Do you think I should not do this in those diagrams?
Do you mean like
(height, depth, altitude)orheight (depth, altitude)? I am not sure whyheightin this case should be favored. All of those names are aliases for the same quantity.
The second one.
You're right, they have equal standing.
I used
_because I refer to explicit types and names in the library. Do you think I should not do this in those diagrams?
The diagram is prefaced as talking about ISO 80000.
So I do find it a bit off that it uses _ like the code.
OK, I will change it as suggested.
Parenthesize alternative terms to reduce confusion.
I think it was one of out coauthors of P2980 who was confused by this, expressed during a meeting.
I started to make all the changes in all three graphs but stumbled on https://mpusz.github.io/wg21-papers/papers/2982R0_std_quantity_as_a_numeric_type.html#hierarchies-of-derived-quantities.
Do you think that mass * acceleration of free fall * height is more readable than mass * acceleration_of_free_fall * height?
That looks like a violation of ISO 80000-1 7.1.4's:
Descriptive terms or names of quantities shall not be arranged in the form of an equation. Names of
quantities or multi-letter abbreviated terms, for example, presented in italics or with subscripts, shall
not be used in the place of symbols.
You could use actual formulas, and I doubt the figure would lose much value that way, if at all.
With the formulas, I would need to introduce the symbols first, and we do not have a place for it both in papers and our docs. This is why I decided to use quantity names rather than their symbols. But using spaces instead of _ makes it read really bad.
Actually in mp-units as we do not have unicode symbols for quantities, our symbol is a typename ;-) and that is why it is being used in an equation.
With the formulas, I would need to introduce the symbols first, and we do not have a place for it both in papers and our docs.
Maybe you can add a separate rectangle called legend.
Some fixes:
- Energy doesn't have a formula (I suppose you took it from the code).
- Kinetic energy is missing the factor
$1/2$ . - If you took the formulas from the code,
the others might be wrong
(those with formulas might be different, and
those without formulas might actually have one).
Energy doesn't have a formula (I suppose you took it from the code).
Yes, but it needs one for an initial definition to at least define the dimension. That is why I just use base quantities as a more generic thing.
Kinetic energy is missing the factor 1/2.
Yes, but those are recipes for the library types and not proper physical equations. This is also why I was using _ in names.
A long time ago, we decided not to encode factors in quantity equations (i.e. radius being 1/2 diameter) as this is highly misleading for the user if the library will do the scaling by itself.
A long time ago, we decided not to encode factors in quantity equations (i.e. radius being 1/2 diameter) as this is highly misleading for the user if the library will do the scaling by itself.
So these are not really formulas, are they?
Won't readers who know their quantities be surprised by the seemingly wrong formulation?
Energy doesn't have a formula (I suppose you took it from the code).
Yes, but it needs one for an initial definition to at least define the dimension. That is why I just use base quantities as a more generic thing.
Makes sense.
ISO 80000 does implicitly define the dimension through the unit.
But in code, ISQ doesn't depend on SI.
Won't readers who know their quantities be surprised by the seemingly wrong formulation?
I don't think so. We are not trying to obtain a correct value here but to specify what is the type of quantity and its dimension. If I would wrote the code like:
Dimension auto kinetic_energy_dim = isq::dim_mass * pow<2>(isq::dim_length / isq::dim_time);No one would be confused buy that, right? No one expects the value 1/2 to be included in such calculation. The same applies to quantities:
QuantitySpec auto kinetic_energy = isq::mass * pow<2>(isq::speed);This is what we want to achieve and present here. A recipe for the quantity being specified by a box in the graph. We are not providing an equation to calculate it in the code. Otherwise, I would have to introduce plenty of strange math symbols like integrals, sums, etc. and doing this would probably not help either in the graph.
This is actually why I think I should stick with _ in the names. I can provide the parentheses you asked for, though.
ISO 80000 does implicitly define the dimension through the unit.
But in code, ISQ doesn't depend on SI.
Right, ISO 80000 contradics itself a bit in specs:
- They say that the System of Quantites is only about quantities and leaves units aside.
- They say the specs define ISQ which is System of Quantites
- They say that the SI specified by BIPM bases on ISQ (so those ISO standards)
- Then in tables they always provide SI units
According to https://www.iso.org/en/contents/news/2022/05/metrology-in-digital-era-1.html,
the SI brochure defines the SI.
It certainly has all the specially named units.
This is actually why I think I should stick with
_in the names. I can provide the parentheses you asked for, though.
Let's do this.
The less confused readers, the better.
the SI brochure defines the SI.
It certainly has all the specially named units.
Sure, the SI Brochure defines SI, which is an International System of Units that is based on ISQ. I never said otherwise.
What I said is that ISQ is not supposed to mention units because they serve as a reference for a multitude of systems (e.g. CGS) but for some reason, all of the tables in ISO80000 provide SI units (so the units of one particular system of units that depends on ISQ).