docs(ref): document `mp_units.core` #628

JohelEGP · 2024-10-18T20:44:33Z

This is still a WIP:

This is also blocked on #626 and #627,
and a number of minor points which I'll review later.

There are some TBDs, mainly for algorithms which need wording.
These are:

The expression template algorithms.
The quantity specification conversion algorithms.
Magnitude's is-positive-integral-power/is_positive_integral_power,
due to the fact that power_v is an unspecified implementation detail.
The canonical unit, common scaled unit, get quantity spec, and collapse common unit algorithms.
The formatting functions for dimensions and units.

Additionally, some things might be missing with regards to magnitude.
Like implementation defined limits,
or what else can we expect or require from an implementation.

Work left: The quantity types.

mpusz · 2024-10-19T04:56:14Z

This is great! Thanks!

Regarding magnitudes, please note that they are meant to be implementation-defined. Only a few user-facing API things are public (construction helpers (mag, mag_ratio, and mag_power), concept, operators, magnitude<...> where ... is implementation-defined).

mpusz

This is huge!!! Lots of great work! Thank you!!!

docs/api_reference/src/quantities.tex

mpusz · 2024-10-19T12:51:01Z

docs/api_reference/src/quantities.tex

+template<typename T>
+concept quantity_like = @\seebelownc@;


We probably should be consistent and use either PascalCase everywhere or refactor all the concepts to standard_case somehow. You already have some concepts in PascalCase above.

Yeah, I should be using what the master branch uses, at least for the public API.
Whenever you see a snake_case concept, that's just something I did at first.
As I start documenting their surroundings, I'll be changing them back to PascalCase.

mpusz · 2024-10-19T12:53:58Z

docs/api_reference/src/quantities.tex

+
+\begin{itemdecl}
+template<typename T>
+concept @\defexposconceptnc{tag-type}@ = type_is_empty(^T) && type_is_final(^T);  // \expos


Why not in terms of is_empty and is_final?

mpusz · 2024-10-19T20:11:35Z

docs/api_reference/src/quantities.tex

How can we specify that some public identifiers should not be exported from the std module?

Reading https://wg21.link/std.modules, it seems like there's no way.

I will ask LWG members

Dropping in mid-stream here -- is there a problem with marking them as exposition only? That basically says -- we're going to act like this thing exists in the standard, but we might implement it differently or call it something different.

exposition-only is not a solution, as I wrote in the LWG reflector.

mpusz · 2024-10-19T20:17:56Z

docs/api_reference/src/quantities.tex

+\label{term.quantity.type}
+A \defnadj{quantity}{type}
+is a type \tcode{\placeholder{Q}}
+that is a specialization of \tcode{quantity} or \tcode{quantity_point}.


There are some users that derive from quantity already. We support this in mp-units with derived_from. Should we remove this support?

Also, I would not account quantity_point to a quantity type. One can do quantity equations on quantity types, which is not true for quantity points.

Putting them into the same basket makes it also harder to communicate.

mpusz · 2024-10-19T20:19:34Z

docs/api_reference/src/quantities.tex

+
+\begin{itemdecl}
+template<typename T>
+concept @\deflibconcept{Quantity}@ = @\unspecnc@;


Why this is unspecified?

It's not done, but is needed by their uses (the use of \libconcept requires a corresponding \deflibconcept).

mpusz · 2024-10-19T20:22:02Z

docs/api_reference/src/quantities.tex

+
+\begin{itemdecl}
+template<typename T>
+concept @\deflibconcept{point_origin}@ = @\unspecnc@;


Why this is unspecified?

mpusz · 2024-10-19T20:23:39Z

docs/api_reference/src/quantities.tex

+A \defnadj{quantity point}{type} is a specialization of \tcode{quantity_point}.
+Let \tcode{\placeholder{Q}} be a quantity point type.
+\tcode{\placeholdernc{Q}::point_origin} represents
+the origin point of a position vector\irefiev{102-03-15}


"position vector" is only one of many quantities specified in ISQ. Please do not use this name here. It is even hard to talk about position vectors for masses or voltage.

It sounds like you think this refers to the quantity.
This refers to yet another definition for the term.
The context is seen in "Area" here: https://www.electropedia.org/iev/iev.nsf/display?openform&ievref=102-03-15.

Yes, I thought so. But it seems a bit ambiguous. Maybe we can find some alternative spelling?

They only have that term for that definition.

There may be a more inclusive definition for the point origin.

Perhaps we could use the definition of point space.
Something like Q::point_origin represents the point whose vector is the neutral element for addition.

...which doesn't work for relative point origins.

mpusz · 2024-10-23T18:45:24Z

Could you please not squash or rebase the branch?

It is impossible to track what changes between commits this way. I need to start reviewing all 2500 lines from scratch as I do not know what has changed.

Maybe provide something for merge and open another PR with additional changes?

Co-authored-by: Mateusz Pusz <[email protected]>

mpusz · 2024-10-24T05:31:45Z

I try to review in LatTeX as it is easier to provide comments that way, and I also need to learn the syntax.

docs/api_reference/src/quantities.tex

mpusz · 2024-10-25T09:28:06Z

docs/api_reference/src/quantities.tex

+template<@\exposconceptnc{DerivedQuantitySpecExpr}@... Expr>
+struct @\exposidnc{derived-quantity-spec-impl}@ :
+    @\exposidnc{quantity-spec-interface}@,
+    @\exposidnc{expr-fractions}@<struct dimensionless, Expr...> {


For this, I had a "chicken and egg problem". This is why I used is_dimensionless instead. Did you manage to workaround this issue and use dimensionless directly here?

No, I had no idea.

But the C++ standard specification is not code.
Implementors are expected to make it work,
just like how we use names introduced later without a forward declaration.

But I suppose there'd be less friction
if we avoided that for this implementation detail.

I don't see where a complete type for the OneType is needed
in the mp-units implementation of expr_fractions.

I am not sure what you mean. It is used here:

mp-units/src/core/include/mp-units/framework/expression_template.h

Line 310 in 4eca0db

if constexpr (size == 2 && OneType<type_list_front<List>>::value)

Well, yes, that's called OneType.
I mean the actual type representing the neutral element.
In these cases, one, dimension_one, and dimensionless.

I never provided those in my implementation. It was your design change 😉

This reference documentation doesn't need the OneType to be complete.
Even if it did, maybe it's OK:

But the C++ standard specification is not code.
Implementors are expected to make it work,
just like how we use names introduced later without a forward declaration.

I also don't see where you need a complete type in mp-units.
So maybe it was a problem in the past, but it wouldn't be anymore.

mpusz · 2024-10-25T09:33:51Z

docs/api_reference/src/quantities.tex

+concept @\defexposconceptnc{PowerVBase}@ = (^T == ^int) || ^T == ^std::intmax_t || @\libconcept{MagConstant}@<T>;
+
+template<typename T>
+concept @\defexposconceptnc{MagnitudeSpecExpr}@ = @\exposconceptnc{PowerVBase}@<T> || @\unspecnc@;


What is the second argument of the conjunction here?

It's power_v in mp-units.
It's not in a detail:: namespace,
but it seems to be the indirection used for the prime factorization
(a reason users should use mag and not magnitude, IIUC).
This ties to what I mention in the opening comment:

Additionally, some things might be missing with regards to magnitude.
Like implementation defined limits,
or what else can we expect or require from an implementation.

mpusz · 2024-10-25T09:44:08Z

docs/api_reference/src/quantities.tex

+constexpr bool @\exposidnc{is-per-of-units}@<per<Ts...>> = (... && (@\libconcept{Unit}@<Ts> || @\exposidnc{is-power-of-unit}@<Ts>));
+
+template<typename T>
+concept @\defexposconceptnc{DerivedUnitExpr}@ = @\libconcept{Unit}@<T> || @\exposidnc{is-power-of-unit}@<T> || @\exposidnc{is-per-of-units}@<T>;


I am wondering if we should provide those in the synopsis (for all derived entities). After the discussion on the LWG reflector, it seems we can't make it invisible in a module, but people say that stating that instantiating derived class templates by a user is IFNDR is fine.

With the above, we do not officially need to check for the correctness of this expression. I did those mostly to check my own implementation, but now, I am considering removing that for compile-time performance reasons.

Please note that the checks are not exhaustive because we do not check if Ts... are in proper order.

Do you think it makes sense to keep them to improve the understanding of the library at the cost of many more lines in the spec? We will probably need to describe how to instantiate those types in expr-XXX functions anyway.

In general, I've been wondering whether even the library should name these directly.

Preferably, they'd be named trough an indirection
that either requires the argument to be correct (e.g., in order, simplified)
or makes them correct and also simplifies them.

For example, your recent fix with commit 9c7d3b0
would be simpler if there was an alias template scalar_unit_t
that performed those simplifications.

One problem with the former approach of requiring correct arguments
is the lack of portability when naming those templates.
For example, magnitude<4> isn't the same as mag<4>'s in mp-units.
And mp-units prime factorization is an implementation detail,
so the answer for other implementations isn't guaranteed to be the same.

The derived_XXX, per, power, magnitude, and power_v class templates are instantiated by the framework only. The framework does it correctly, and we have tests for that. We might not need to provide constraints that check if arguments are of the specified type.

I do not want to provide any indirection here, as a user simply should not do it. IFNDR is a good solution, and we should probably mention this in our wording for such types.

Regarding magnitudes, there is no framework to instantiate them. That is why we provide a mag factory to properly calculate and provide the arguments.

From the above, I assume you are OK with removing those containing concepts?

Yes, that'd be great.

mpusz · 2024-10-25T12:04:02Z

docs/api_reference/src/quantities.tex

+constexpr bool space_before_unit_symbol = true;
+
+template<>
+inline constexpr bool @\libspec{space_before_unit_symbol}{one}@<one> = false;


one is not declared before this point. Maybe this specialization should be put after one definition?

See above's

But the C++ standard specification is not code.
Implementors are expected to make it work,
just like how we use names introduced later without a forward declaration.

mpusz · 2024-10-25T12:19:02Z

docs/api_reference/src/quantities.tex

+\end{itemdescr}
+
+\begin{itemdecl}
+consteval bool @\exposidnc{is-convertible-to-base-subobject-of}@(  // \expos


Can we use is-derived-from-specialization-of here? "convertible" may mean more than inheritance here, and the std::derived_from concept already requires public inheritance, so we do not have to mention convertibility in the name.

Definitely.
I was going to do that,
after finishing the quantity types,
when moving away from reflection.

mpusz · 2024-10-25T12:21:12Z

docs/api_reference/src/quantities.tex

+
+  friend consteval @\exposidnc{ratio}@ operator*(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs);
+
+  friend consteval @\exposidnc{ratio}@ operator/(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs) { return lhs* @\exposidnc{ratio}@{rhs.den, rhs.num}; }


Suggested change

friend consteval @\exposidnc{ratio}@ operator/(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs) { return lhs* @\exposidnc{ratio}@{rhs.den, rhs.num}; }

friend consteval @\exposidnc{ratio}@ operator/(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs) { return lhs * @\exposidnc{ratio}@{rhs.den, rhs.num}; }

docs/api_reference/src/quantities.tex

mpusz · 2024-10-25T14:43:01Z

docs/api_reference/src/quantities.tex

+  requires(sizeof...(Den) <= 1 && @\exposidnc{valid-ratio}@(Num, Den...) && @\exposidnc{positive-ratio}@(Num, Den...) &&
+           !@\exposidnc{ratio-one}@(Num, Den...))


Do you plan also to provide valid-ratio, positive-ratio, and ratio-one.

Or better.
This is part of:

This is also blocked on [...]
and a number of minor points which I'll review later.

Co-authored-by: Mateusz Pusz <[email protected]>

docs/api_reference/src/quantities.tex

mpusz · 2024-10-25T21:01:48Z

docs/api_reference/src/quantities.tex

+  }
+};
+
+struct @\exposidnc{quantity-spec-interface}@ : @\exposidnc{quantity-spec-interface-base}@ {


quantity-spec-interface-base is not needed here. I did it only for older compilers where quantity-spec-interface is a template, which would complicate implementing QuantitySpec and result in ambiguity when operators would be called with a different type.

Here, quantity-spec-interface is not a template, so it may contain all of the implementation, and the QuantitySpec concept may use it in its definition.

Co-authored-by: Mateusz Pusz <[email protected]>

mpusz · 2024-10-25T21:03:36Z

docs/api_reference/src/quantities.tex

+constexpr bool @\exposidnc{is-per-of-units}@<per<Ts...>> = (... && (@\libconcept{Unit}@<Ts> || @\exposidnc{is-power-of-unit}@<Ts>));
+
+template<typename T>
+concept @\defexposconceptnc{DerivedUnitExpr}@ = @\libconcept{Unit}@<T> || @\exposidnc{is-power-of-unit}@<T> || @\exposidnc{is-per-of-units}@<T>;


mpusz · 2024-10-26T06:37:37Z

docs/api_reference/src/quantities.tex

+If the first argument is a base quantity dimension,
+then \tcode{Q} is that base quantity\irefiev{112-01-08}.
+If an argument is a quantity calculus\irefiev{112-01-30} \placeholder{C},
+then $\tcode{Q} = \placeholder{C}$ (a quantity equation\irefiev{112-01-31}).


I am not sure it Q = C statement is correct. If C = 1 / time, then what Q should be? It might be frequency, activity, bit rate, etc. Maybe it is better to state that Q is implicitly convertible from C (with C being its recipe)?

Yeah.
It might be better to avoid using equations.
Those don't account for other properties of the involved quantities.

mpusz · 2024-10-26T06:41:47Z

docs/api_reference/src/quantities.tex

+then \tcode{Q} is of its kind\irefiev{112-01-04}.
+
+\pnum
+\tcode{set} is the set of the numerical value of \tcode{Q}.


Today, it is not a set, and I am not sure it will ever be modeled as such. Each quantity has an exact character in ISQ. In engineering, it might be different. For example, it is common to represent acceleration as a directed scalar (minute means slowing down), which is not equivalent to norm(acceleration).

It's this set: https://www.electropedia.org/iev/iev.nsf/display?openform&ievref=102-01-02.
I prefer a defined term than "character".

mpusz · 2024-10-26T06:43:12Z

docs/api_reference/src/quantities.tex

+\pnum
+\tcode{set} is the set of the numerical value of \tcode{Q}.
+If not specified, then it defaults to \tcode{scalar} for the first signature,
+and to that of the quantity argument that comes before the \tcode{set} otherwise.


I do not understand this statement.

Did you mean that the character is derived from the provided quantity for other signatures (if not set explicitly)?

Also, we should probably state what happens when a user provides a character that conflicts with the character of the provided quantity. For now, it is possible, but I believe that when I finally have time to finish my work on vectors, tensors, and complexes, then the second and fourth signatures will not get a character at all (always derived from the calculus).

mpusz · 2024-10-26T06:43:51Z

docs/api_reference/src/quantities.tex

+\tcode{set} is the set of the numerical value of \tcode{Q}.
+If not specified, then it defaults to \tcode{scalar} for the first signature,
+and to that of the quantity argument that comes before the \tcode{set} otherwise.
+\tcode{is_kind} specifies \tcode{Q} to start a new hierarchy tree of a kind.


mpusz · 2024-10-26T17:24:02Z

docs/api_reference/src/quantities.tex

 \end{itemdescr}

-\rSec1[qty.traits]{Traits}
+\rSec3[qty.set.traits]{Set}


Set might never be true (as we use only one character for a quantity type), and even if for some reason it will be true, still, I think it is not the best name here. I would prefer "character" to be consistent with enum and other places where use this term.

The term "character" was taken from this ISO quote: https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/character_of_a_quantity/#characters-dont-apply-to-dimensions-and-units

That's not in the 2022 edition.
Although it still exists at https://www.electropedia.org/iev/iev.nsf/display?openform&ievref=112-01-11.

mpusz · 2024-10-26T17:26:28Z

docs/api_reference/src/quantities.tex

+template<typename T>
+concept @\defexposconceptnc{Scalable}@ =
+  @\exposconceptnc{CastableNumber}@<T> ||
+  (@\exposconceptnc{CastableNumber}@<@\exposidnc{actual-value-type-t}@<T>> &&
+   @\exposconceptnc{ScalableNumber}@<T, std::common_type_t<@\exposidnc{actual-value-type-t}@<T>, std::intmax_t>>);


It would be good if you could look into this concept and possibly improve it.

docs/api_reference/src/quantities.tex

mpusz · 2024-10-26T18:19:11Z

docs/api_reference/src/quantities.tex

+\label{term.quantity.type}
+A \defnadj{quantity}{type}
+is a type \tcode{\placeholder{Q}}
+that is a specialization of \tcode{quantity} or \tcode{quantity_point}.


Also, I would not account quantity_point to a quantity type. One can do quantity equations on quantity types, which is not true for quantity points.

Putting them into the same basket makes it also harder to communicate.

mpusz · 2024-10-26T18:23:40Z

docs/api_reference/src/quantities.tex

+  using namespace si;
+
+  if constexpr (is_same_v<Period, std::chrono::nanoseconds::period>)
+    return nano<second>;
+  else if constexpr (is_same_v<Period, std::chrono::microseconds::period>)
+    return micro<second>;
+  else if constexpr (is_same_v<Period, std::chrono::milliseconds::period>)
+    return milli<second>;
+  else if constexpr (is_same_v<Period, std::chrono::seconds::period>)
+    return second;
+  else if constexpr (is_same_v<Period, std::chrono::minutes::period>)
+    return minute;
+  else if constexpr (is_same_v<Period, std::chrono::hours::period>)
+    return hour;
+  else if constexpr (is_same_v<Period, std::chrono::days::period>)
+    return day;
+  else if constexpr (is_same_v<Period, std::chrono::weeks::period>)
+    return mag<7> * day;
+  else
+    return mag_ratio<Period::num, Period::den> * second;


We can probably do it with prose. Also, it should be part of the SI paper, not P3045.

Very well.
It's already done,
and is part of mp-units' reference documentation.

docs/api_reference/src/quantities.tex

mpusz · 2024-10-26T19:08:19Z

docs/api_reference/src/quantities.tex

+template<@\exposconceptnc{DerivedQuantitySpecExpr}@... Expr>
+struct @\exposidnc{derived-quantity-spec-impl}@ :
+    @\exposidnc{quantity-spec-interface}@,
+    @\exposidnc{expr-fractions}@<struct dimensionless, Expr...> {


I never provided those in my implementation. It was your design change 😉

docs/api_reference/src/quantities.tex

Co-authored-by: Mateusz Pusz <[email protected]>

mpusz requested changes Oct 19, 2024

View reviewed changes

JohelEGP force-pushed the ref_docs branch 5 times, most recently from 05ab0a8 to 8bf5db5 Compare October 23, 2024 16:15

This comment was marked as outdated.

Sign in to view

JohelEGP and others added 6 commits October 23, 2024 17:57

docs(ref): document mp_units.core

644b8d1

docs(ref): document mp_units.core

600a69b

Co-authored-by: Mateusz Pusz <[email protected]>

docs(ref): document mp_units.core

e819430

Co-authored-by: Mateusz Pusz <[email protected]>

docs(ref): document mp_units.core

9a9c343

Co-authored-by: Mateusz Pusz <[email protected]>

docs(ref): document mp_units.core

543254a

Co-authored-by: Mateusz Pusz <[email protected]>

docs(ref): document mp_units.core

d454ccc

Co-authored-by: Mateusz Pusz <[email protected]>

JohelEGP force-pushed the ref_docs branch from 8bf5db5 to d454ccc Compare October 23, 2024 22:12

docs(ref): fill [qty.ref]

60dd2cb

mpusz requested changes Oct 25, 2024

View reviewed changes

JohelEGP and others added 2 commits October 25, 2024 14:28

[mp.units.core.syn] Update pi's UCN

d9248b1

Co-authored-by: Mateusz Pusz <[email protected]>

[qty.unit.types] Update Magnitude * Unit

824f0c1

Co-authored-by: Mateusz Pusz <[email protected]>

mpusz requested changes Oct 25, 2024

View reviewed changes

JohelEGP and others added 8 commits October 25, 2024 18:43

[qty.dim.types] Fix derived_dimension example

8bce9c6

Co-authored-by: Mateusz Pusz <[email protected]>

[qty.spec.concepts] Update _QuantityKindSpec_

58487d6

Co-authored-by: Mateusz Pusz <[email protected]>

Merge branch 'master' into ref_docs

0cab71d

[mp.units.core.syn] Add \u03C0

1f6be11

[qty.spec.types] Improve description of kind_of

17585ce

[qty.unit.types] Fix named_unit description of "kind" parameter

9b35ad4

[qty.unit.types] Improve named_unit example comment

ae58e6c

Co-authored-by: Mateusz Pusz <[email protected]>

[qty.unit.types] Further improve named_unit example comments

14c0ee6

JohelEGP added 8 commits October 26, 2024 12:27

[qty.unit.types] Mark derived_unit as final

f542ffb

[qty] Avoid idiom in detailed specifications

24842ca

[qty.ratio] Implement common_ratio in terms of std::

ac09cec

[qty.spec] Update for removal of _DerivedQuantitySpecExpr_

399dcd0

[qty.unit] Update for removal of _DerivedUnitExpr_

2f8c2b1

[qty.mag] Update for removal of _MagnitudeSpecExpr_

aa5aa63

[qty.spec] Update for removal of _QuantitySpecWithNoSpecifiers_

9ecd87e

[qty.mag] Update for parameter renames

49cb247

mpusz requested changes Oct 26, 2024

View reviewed changes

JohelEGP added 3 commits October 26, 2024 14:24

[qty.dim] Update for removal of _DerivedDimensionExpr_

0248136

Merge branch 'master' into ref_docs

04eab10

[qty.ratio] Fix "Equivalent to:" formatting

71bfcf8

mpusz requested changes Oct 26, 2024

View reviewed changes

JohelEGP and others added 4 commits October 26, 2024 18:33

[qty.spec.types] Improve the kind of quantity hierarchy function

b94ec34

[qty.ref] Avoid adjacent itemdecl codeblock environments

1917e12

[qty.val.traits] Do not use std::chrono::duration_values<Rep>::one()

2b23001

[mp.units.core.syn] Fix derived_quantity_spec's template parameter

df90897

Co-authored-by: Mateusz Pusz <[email protected]>


		friend consteval @\exposidnc{ratio}@ operator*(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs);

		friend consteval @\exposidnc{ratio}@ operator/(@\exposidnc{ratio}@ lhs, @\exposidnc{ratio}@ rhs) { return lhs* @\exposidnc{ratio}@{rhs.den, rhs.num}; }

		requires(sizeof...(Den) <= 1 && @\exposidnc{valid-ratio}@(Num, Den...) && @\exposidnc{positive-ratio}@(Num, Den...) &&
		!@\exposidnc{ratio-one}@(Num, Den...))

docs(ref): document mp_units.core #628

Are you sure you want to change the base?

docs(ref): document mp_units.core #628

Conversation

JohelEGP commented Oct 18, 2024 • edited Loading

mpusz commented Oct 19, 2024

mpusz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpusz commented Oct 23, 2024

This comment was marked as outdated.

mpusz commented Oct 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mpusz Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JohelEGP Oct 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

docs(ref): document `mp_units.core` #628

docs(ref): document `mp_units.core` #628

JohelEGP commented Oct 18, 2024 •

edited

Loading

mpusz Oct 25, 2024 •

edited

Loading

JohelEGP Oct 26, 2024 •

edited

Loading