search

mpusz / wg21-papers

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

refactor(security): improve figure in 7.8 #51

Closed JohelEGP closed 10 months ago

JohelEGP commented 10 months ago
mpusz commented 10 months ago

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.

mpusz commented 10 months ago

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?

mpusz commented 10 months ago

I used _ because I refer to explicit types and names in the library. Do you think I should not do this in those diagrams?

JohelEGP commented 10 months ago

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.

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.

mpusz commented 10 months ago

OK, I will change it as suggested.

JohelEGP commented 10 months ago

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.

mpusz commented 10 months ago

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?

JohelEGP commented 10 months ago

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.

mpusz commented 10 months ago

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.

mpusz commented 10 months ago

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.

JohelEGP commented 10 months ago

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:

mpusz commented 10 months ago

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.

mpusz commented 10 months ago

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.

JohelEGP commented 10 months ago

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.

mpusz commented 10 months ago

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.

mpusz commented 10 months ago

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:

JohelEGP commented 10 months ago

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.

JohelEGP commented 10 months ago

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.

mpusz commented 10 months ago

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

mpusz commented 10 months ago

Resolved with https://github.com/mpusz/wg21-papers/commit/d0b6b26bb3e1c98124217be3c17e279c090cb3fa.