From 86d0af388e2548adcae9df6a7a2d770d4efc520a Mon Sep 17 00:00:00 2001 From: github-actions Date: Tue, 17 Jun 2025 14:21:09 +0000 Subject: [PATCH] Deployed 1d9a7c28 to HEAD with MkDocs 1.6.1 and mike 2.1.3 --- .../index.html | 132 ++++++++++++------ HEAD/blog/absolute-quantities.jpeg | Bin 0 -> 111040 bytes HEAD/blog/archive/2025/index.html | 2 +- HEAD/blog/category/metrology/index.html | 2 +- HEAD/blog/index.html | 2 +- HEAD/feed_json_updated.json | 2 +- HEAD/feed_rss_created.xml | 2 +- HEAD/feed_rss_updated.xml | 2 +- HEAD/search/search_index.json | 2 +- 9 files changed, 99 insertions(+), 47 deletions(-) create mode 100644 HEAD/blog/absolute-quantities.jpeg diff --git a/HEAD/blog/2025/06/16/introducing-absolute-quantities/index.html b/HEAD/blog/2025/06/16/introducing-absolute-quantities/index.html index b59d6e29..0754a74a 100644 --- a/HEAD/blog/2025/06/16/introducing-absolute-quantities/index.html +++ b/HEAD/blog/2025/06/16/introducing-absolute-quantities/index.html @@ -2399,7 +2399,7 @@ You're not viewing the latest version. - 7 min read + 8 min read @@ -2489,6 +2489,15 @@ You're not viewing the latest version. + + +
  • + + + Motivating example + + +
    • @@ -2614,7 +2623,7 @@ in many equations in source code where it would be a good fit otherwise.

    (e.g., temperatures in degrees Celsius, tared mass measurements, altitudes above some reference point, etc.) and do it really well. Constrained affine space arithmetic (e.g., preventing accidental addition of points) also improves the safety of our programs. -This is why it is a very valuable abstraction and should be used even more often than now.

    +This is why it is a valuable abstraction and should be used more even often than now.

    To improve the user experience and open the doors for new features in the future, we are considering adding a third abstraction for absolute quantities. In terms of properties, an absolute quantity will lie between points and deltas.

    @@ -2661,7 +2670,7 @@ an absolute quantity will lie between points and deltas.

    Relative to origin Absolute & relative -Absolute (implicit only) +Measured against nothing/void @@ -2687,23 +2696,22 @@ an absolute quantity will lie between points and deltas.

    As we can see above, absolute quantities have only two limitations, and both are connected to the offset units' usage. They can't use those because they must remain absolute instead of being measured relative to some custom origin.

    -

    It is also vital to notice that there will be no way to provide a custom origin for -absolute quantities, even if it is defined in terms of absolute_point_origin. Those -quantities are meant to model abstractions with well-established and unambiguous zero -origins. If we allow passing absolute point origins, we could define two quantities -of the same type measured according to different not-related origins, which would be -too confusing.

    -

    The above also allows us to print them, as we do not need any special text to describe -their origin.

    +

    Absolute quantities could be considered delta quantities that represent a whole +-- the entire entity being measured. This is why we can represent a system mass by adding +absolute masses of all system elements or a system energy by adding absolute +temperatures of all the system elements.

    +

    As those are more related to deltas than points, it is impossible to specify their origin +points. This also allows us to print them, as we do not need any special text to describe +their origin as they are always measured against nothing/void.

    Interfaces refactoring

    As I mentioned in my previous post, we are seriously considering removing quantity_point class template and replacing it with a quantity_spec point wrapper. For example, quantity_point<isq::altitude[m]> will become quantity<point<isq::altitude[m]>>.

    I initially planned quantity<isq::mass> to be the same as quantity<delta<isq::mass>>, -but it turns out that deltas probably should not be the default. It is consistent with how we -write physical expressions on paper, right? Delta symbol (∆) is always "verbose" -in our equations, it would be nice for the C++ code to do the same. So, deltas will always +but it turns out that deltas probably should not be the default. It is consistent with how +we write physical expressions on paper, right? Delta symbol (∆) is always "verbose" +in physical equations, it would be nice for the C++ code to do the same. So, deltas will always need to be explicit.

    And this brings us to absolute quantities. They should actually be the default we are looking for. This is what we write as quantities in most of the physical equations. This is why we @@ -2732,16 +2740,15 @@ will not need any specifier to denote them.

    Affine space arithmetic is well-defined. However, we are adding a new type to the library that lands between points and deltas. This is why we must agree on the arithmetic for all possible combinations.

    -

    Let's try to define them here, assuming that points and absolute values share -a common origin.

    -
    -

    Note

    -

    If points and absolute values do not share a common absolute point origin -the operation should fail to compile.

    -

    Addition

    -

    In case of addition, a more constrained type is preserved (except for adding two points, -which is undefined):

    +

    Absolute quantities are deltas against nothing so adding them to a point yields another point.

    +

    Adding a delta to them yields a delta, as a delta may represent only a part of something and +a whole, and a part is not a whole. The delta may also be negative and greater +than the absolute quantity, which may yield a negative value. This is why delta is a good +result here.

    +

    Only adding whole non-negative entities of the system yields a system being expressed as +an entire non-negative entity. This is why adding absolute quantities results in an absolute +quantity.

    @@ -2762,20 +2769,23 @@ which is undefined):

    - + - +
    Absolute Point AbsoluteAbsoluteDelta
    Delta PointAbsoluteDelta Delta

    Subtraction

    -

    Subtraction is more tricky. To verify the logic below, it might be helpful to ask whether -a result may be negative when two arguments are non-negative. If the answer is true, -the result should be a delta quantity.

    +

    Similarly, during subtraction, regular affine space arithmetics for deltas apply. +Subtracting an absolute quantity from a point yields a point, and trying to do the opposite +does not make physical sense.

    +

    Subtracting two non-negative absolute quantities may yield a negative value if we subtract +a larger one from the smaller one, so the result should be a delta. A similar result +may be obtained by subtracting a delta from absolute quantity or absolute quantity from a delta.

    @@ -2794,9 +2804,9 @@ the result should be a delta quantity.

    + - @@ -2806,29 +2816,71 @@ the result should be a delta quantity.

    Absolute Delta DeltaAbsolute
    Delta
    +
    +

    Info

    +

    Based on the above assumptions, one of the lines of the below code can't compile:

    +
    quantity temp1 = 270 * K;
+quantity temp2 = point<K>(300); 
+quantity temp3 = temp2 - temp1;             // Point
+// quantity temp4 = temp1 - temp2;          // Compile-time error
+quantity temp5 = temp1 - temp2.absolute();  // Delta
+
    +
    +

    Motivating example

    +

    Let's consider a room with a table and two glasses filled with fluid on top of it. +Let's also assume that we want to stack one on top of the other and treat them as a system +we observe.

    +

    Absolute quantities

    +
    // absolute quantities
+quantity<isq::height[cm]> glass1_height = 20 * cm;
+quantity<isq::height[cm]> glass2_height = 15 * cm;
+
+// delta quantities
+quantity<delta<isq::height>[cm]> fluid_level = 16 * cm;
+
+// point quantities
+inline constexpr struct floor_level final : absolute_point_origin<isq::height> floor_level;
+quantity<point<isq::height[cm], floor_level>> table_top = floor_level + 1 * m;
+// quantity<point<isq::height[cm]>> glass1_top(glass1_height); // point against nothing (no length)
+
+// absolute results
+quantity system_height = glass1_height + glass2_height;
+
+// delta results
+quantity empty_height_res = glass1_height - fluid_level;
+quantity glass2_height_res = system_height - glass1_height;    // could result in an absolute quantity
+assert(glass2_height_res == glass2_height);
+quantity height_diff_res = glass2_height - glass1_height;      // but this one should definitely return delta
+
+// point results
+quantity<point<isq::height[cm], floor_level>> glass1_top = table_top + glass1_height;
+quantity point1 = glass1_top - glass1_height;
+assert(point1 == table_top);
+// quantity point2 = glass1_height - glass1_top;               // no sense - does not compile
+

    New opportunities

    The new syntax simplifies API as one quantity class template will now serve all quantity variations (possibly even more in the future). It also allows us to model quantities that were impossible to express before without some workarounds.

    For example, we can now correctly calculate Carnot engine efficiency with any of the following:

    -
    quantity temp_cold = 300. * K;
-quantity temp_hot = 500. * K;
-quantity carnot_eff_1 = 1. - temp_cold / temp_hot;
-quantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot;
+
    quantity temp_cold = 300. * K;
+quantity temp_hot = 500. * K;
+quantity carnot_eff_1 = 1. - temp_cold / temp_hot;
+quantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot;
 
    
 
    In the above code, we can easily create absolute or delta values of temperatures and do
 arithmetics on them. Previously, we had to create deltas from both points artificially
 with:
    
-
    quantity temp_cold = point<K>(300.);
-quantity temp_hot = point<K>(500.);
-quantity carnot_eff_1 = 1. - temp_cold.quantity_from_zero() / temp_hot.quantity_from_zero();
-quantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot.quantity_from_zero();
+
    quantity temp_cold = point<K>(300.);
+quantity temp_hot = point<K>(500.);
+quantity carnot_eff_1 = 1. - temp_cold.quantity_from_zero() / temp_hot.quantity_from_zero();
+quantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot.quantity_from_zero();
 
    
 
    It worked but was far from being physically pure and pretty.
    
 
    Summary
    
-
    We believe that adding absolute quantities will be a major improvement in the library that
-will allow us to more correctly model physical equations making them terser and easier to
-understand at the same time.
    
+
    We believe that adding absolute quantities will be a significant improvement in the library
+that will allow us to model physical equations in a terser, more correct, easier to
+write, understand, and maintain way.
    
 
    We plan to deliver the features mentioned in this post as a part of mp-units V3.
    
 
    Please share your feedback.
    
 
diff --git a/HEAD/blog/absolute-quantities.jpeg b/HEAD/blog/absolute-quantities.jpeg
new file mode 100644
index 0000000000000000000000000000000000000000..7825448163183dc02c501421bec57ba4558eab91
GIT binary patch
literal 111040
zcmex=LlgQ9&YuAcH^y1H&o?i`j+DU;zdO
z8xg1~cZjN7R8^%#c~+&RnJHEV7AeUVNycfqriN)Lx+dmnDY}WKNvXOPmWhce#;N9M
z=0+9_3=F((P~$Wq#w8YGSgMy;T%1}|l9``Z%)r3FBLvmp2-c94Uxchd801R5jKty$
zy`=n#RFDP+iDaYVjPL85vlXV!vG|rHY9u;k=>Y}??vu$$`9+J86LZqjiZc?8OwCfk
zT4tCoPR&cqO)YLr3Gj2zNC6oZq2S}4W&P05Ye%BRzAuKp_n7n&I1_GU%+l#^Gi=aR
zxV0_0ATh-OuF=!OB?zj~#ls@Bv4|)Bhw@C_>35ff=pD>>=VrcJ_(R|!$LekR-l!U#
zjRG9O8XXx>B|KdmL%?S5d7cJ!0N
z<|8Xs$uo+sZ}<7F)31~9Kz=q(ji1sZ4#r+8`CGEw_0$w`htKaKkDc28NaZGHe}QwN
zVk&MwZc}g4dTq(cIOF7%`~2Eg{(QZqtyUNLX0twvczW{D*^@YJ^bD^*n|=N6i#U(E%-9e_}Ip&ug`=PPV)@cFSW<1aj!^5-0IgKrw8ozn*Mx+@UCBbRchZZBr7CW$Qw-d&z0X38Gd`*3kG>x*46KWb#RFnI@7#c_(pc6{%^sc~g-
z-?zPDcjml_^!6=&{WS1fvS_va$JdXdo;&CmY}_A*Q{ydjYrY`q>0j#HRwxziX%Bwz
zk~QILQ(9>ADyb_B{F4fCYUE9Nx+^x4`TU-k&-;|qlpZg8Xi_G5>-ncUNwv3P7eA=O
zsqxPFf74!CRUQ#>`7LHuKGPVHP(sO-`+Xj&P6)peZYo)5dtq7-7LKF^7kyb>(A$y
zp1mBW#*;d2`W)|F5?r1JM){w(v;Roq+`mHZhxVMAxZx{Twrnp>jfUz6)`;t#Ih-kV
zGUr}cn&E%hxbG*fa5amQ-Le#?#wY#r+0T14ZutB+^!#Z__ba~&6K0y7_BwX1
zi%)3V`UX{;8Z!?F9$|~RV378A@qe{7kN-L++`TuiU}fKXE~j?J)X8sgYD});dEt6g
z&?>#nH1pr?46Y+vgf_j(4)VIG?3H(W%7O%(8Xe`PvVYTXK6ondg4*ftQ~3VcEd5bE
z)#mJ{D7-mm{-v1*e8RwP}M)Ucm)vucfzpKQrj|T(rb#W9jNY
zoNe!Biu45kwP)JqCEdo6oyxUHyH|z%G4s8NSEl3CsP$6m`n{kl1wTz=AL^g*W`4;k
zbFS4eiDi-9)9Ftxnxx{?*eq=jaHT=V=&oGSyjwqyy_BteaZ#fB-O^2xE6UTu&&uG`
z`0VFKtE7V#^ICr=Ry>q9-x4PB(cbEW)V|=_mls(3`LE;D*tXcOky+Vd`NNw@?}fAK
zHy@gQq+*rbzH{e%|9w*N3fqEHqpI{TOCiq>xi4mC)SG^EdAL|Q|E;R&G`UvJGo_nd
z0;b~BD8ij6euLZUtRmYVr8yA>4l3%u=j|}Kne#?3*=fW2?VE6F46AgnJ3UeN!odyu
z`ilL}d@M3~Eg|B=C+!jFrvLxKnyolB9#Zq)ByKBW$~Sl4{^ZO!J?B8hro4zpA%E-6
zDXVqQOTwv9rd#|XTZf6}qvT1~3TI7M%N4YFzJR&)##e_6DJS%_^l)n2KC>Y3jp9k3
ztv-1hjSdGVo7`2;4CmX^Wx$&qSJS9pfm5U3VxJ2ePBdI*h-Fq?gkzH!;^A5M)c`YjiT
zOj?$h-YU_M_dWiSm9fw^_Bk@UPx8Ee@~y-lcinM=>u#Jx*Tbpz>qSlfgqc^@%-nq1
zBDo>t#XiXyN$&kIIBi_snAzmPc_<lAOHSoQ;M90PL^z7&ul}>w%$*D`
zw|G?TEMD2ZD}$IW;2)0mjf
z>yo=~-5(t$G>xu)F3^T<-LX
zn4X$fQtVh&T9m5bUyz#T=&9i1=;Nd7no^#Tnpa|EU}UOmV5Vzm9%5))bGhmNw!MMFUn0U$;`}6Oi$G>$V<;G&P>lsEGaEYt?(&M%}G-RS&(K6
z3JiUc`gr;vEqZX%vNH3EOA_;vQ$1ah4fPE2!LEu=Pt8j$N-W7Qs*v%`OfJd?1#^5*
zYH>k+UU6npPHMcPr@o<{K?$1b_{_Yt{KiEopzd0QCS0cil1>FjPX$kqrxXH;^2<{5
zKvt)hr4|)u=I4PNkcH@6HZ4X9ljPE(oQhZ~_#9zABqTuHNl4!mn#vVFpKvfba(MQC
z5sLzsleX&pp+StUK`cov<}1yE@|1KjTopwFS3%NxG1N(ayZA!Rud_HXEmit^-}(bb
z&-+Y0!0k4%B4d$FjMk+u>lqky_(17_fq_8-n&7Z>+u?D}z`&q=50vOGwYV%~v`|@;
zUSXP?k(im+9Lc6>(8Q){(8R*KfSHMriAmU)fq^03-G{m0hslBqpn(a7cmrNGPOUbN
zw(q=*j6AFi24RNW2Apinp)72|OrgPsat1OW4wtYfA^|w(7Zv0eC4%z2p}K)8NS;|(
z4j~`x?4sZd$`6ToCB+Is!Hx>fjs|k#yhbL521X`^mPV$ArcvU&My5zygA!DGg$)Ej
z=5h#gg(ntgWag!pd
z$xZRD))S<-vXs)#Mixt4ZJ0ML_WPfE`--kLCT`}rP~X+ApRG0FkEtt5-Fe@fL&D!b
zT1>LEp57?gx9-bv=huD)$1?o($O@d_!EyOU%d1|Qy#dva|G#W#eHAC})$qzkaOEad
zud7DIm+o<$3+6xH-D9-o%v-}#t0P@@>TI$Mx%YL$$;zxa!DB`~M_t4k=gyZ}zo`C-
zAa9$<6~SrFmunRD!wxi^mPjppVQv(Y1&P_M55|+wvNjfIgxXa~NXvU_m(*j>bdz`o4()e|c$Jg8GmhUGP_&(hc
zcKuh`yMP&Kv6)J`@0v7wfyfDa*S=Zupd6|cSJV;uZMZ!R=L8N=_tUvvwXV3BWX0EOA
zS&|TTbBl{XJV=2&ON2p~LCAuj1p#e-(AuQDyj(9AR*LE+=jZAdWM}3V6zeA!<>oEcHa#7U#_co&nejQ
zssbyyXoto+B`I8)$^!qfSG*)?aEs&4x@&7-y3nvLJ6?s2k~VZnr5pXN8WPki;_
zT*7Umi%G|={^mFyI5q9ekwa&^WR85EdAeWC)1v3?b(e@+Z%h7MZ(L}#>E8LJ7wn2p
zMFh-s>iqO*QM<~tug3EC+$Cqv*z)9T=EjQ0Zd<-h&$SGGB{BP!hfnU_Im!GJr4DuR
ztd+SLWWgRkWr?^(q}?P|nYr)Rm3?qI`ccT}_{*m9B&H@=Str4-KQ$G!r&(;(x_-y;
zYKc+5-`jUpHy&xqJoIky2&pN4IyZ7vuM&Gz>$@ct@8ydOm0tyGtz1=aG`TB-RqbxI
z(N;VXs^WE6?M<)&Y`Mbdpu7;x64GB^waOdYokslW&vOFO6A|i$DGeTO2K>
zKgan-h04a6G8bDJmesFGoAAhGbNZWmg)tJ-uaz8rvC`-L!N;*n*J~uy&WKXI_NeB+
zt&fA0&_YukQ&EGT9v&y&^Za5z!MEs-vcZM@6WG1?ol~6rr0#C(hLG6w-+S)<`lc3i
z`N7BS8{^}8jO8-VO3zIF&XzPs`In&2RNf2W_tbo38)m&;$>nf}X}4CYdB!u>AD=F{
zmd{D`A@Dc}4S7qKqJ7P2G;vM$^!*nXqc957baVt$P^T3SVCnL7z`xgW{5Dc@W^p71T&N}Br!NMI2!Q7
z%W_r&W=6*UD3uxa<_zogx7NQaSXy>d@%tGUG4=~T401p^d~xdzz=nJ~TqQ(G)Si!p09qOC4L
z&a<$JE%S)GjtGnGg89qi?fL7t^Nl#W(6>2
zSaJXP^|bK|gL`B6sinO8CoD*~*28Y;e924RilbzXC$ry$3pt!J3^p@9ERnw4$#X!s
z@apmEDcSdUrimsnr+#M?`0jG_*@QKm;U~{9PnC{X(r>lRO6%&V9>Do%NpO+5X5&bRY`_&CSZ_|Z0t
zj91T^Osb7I0$e}5;JKhz>G0;cnrP`y>F0Lq?sG)U95Y-INDGramvTqGkeZxAD_$dU00lGeQh$|0{=AM{|TK<<>46?&r-N7r$6~#
z8WZHsn{9OWm&TMckr6)fyn5L?JkNTs;`(`c>)NilR|J@yc7{1^|FlWFCU40(lYP&w
zoJ@Rjm#4sgLAGJ?X&1j^f$J;+q(Hvioz-X)4R2p
zey?8ExW-%h|E2bldFM3m&M-^qR@u48>g939|EszyxJns#gmdGbT5%_>lC0gcWG}a(
zw|vXo$IW(Wid|CC%a7+Rx0>}NsVwMdBq>?i-G_Z`Ky#okUZ}U_c(<)XSdTF-&
zdv(U9{pB~N7&l9J%nq1WJuT(Xg~Rc#|BdFn5EtKD@wRkEycHXVwv72~H?Ij?8`ir`
zvNP_~`nBV^QSxWy<9U}veyc^i`^VN2^6Q|y`KsGj-h^rG_uPBtHPhQ;et*_TZWS`k
z6zvrEU7YbMM^1AV=jU@(ipMxFO1|nhaLcsLV9~DW(!G`(`zrUE<-EOYcG2(j1*0{x
zmj^A$i1S(UYTY^I{XS-ew;Ejo`cAc-`yYIGhx2BYckES*w){HIC0l(g$kgx+hkQ%J
zr05?TZ&_YD`TS`oOI=|7muFci?w+rHyjk{bfphS`TZffZZm8Z8*3sH-KjmJzj8BD3
z*3Vh}ud_tU%h!6goD*<3KGTE$>NL5AImHVt7Bc5w_EosB)%nSHy$XK6?|b&A-pZZ8
z9lihFD|PjmDL*W0ifykcUV3-!bFiRZ=;1rBK5B;F3tU)HJb_#P>&a5H*S(i=`zm91
zNm=~AFUh##(us@LKE3Yxs(10sWZ~I!CRC&*SF#-WIB$NB)#ntRe=}q!Kk5%#njEaW
zBd=J@RchP!YW}lJjQ&Uco7VfVz2bI3^9q&LOocgOo))UBBqnN>muvDNk;<&1SgzxKl6M2e&qx6Ss~S1
zx5
zh5hayZB3?D-3m4QGWC*0yw0xvrM-cMS)HL7IoeJsS*At~
zJq71VR+&f0mAm{t#4*F^i0|XsU3}*qT>YgR3L<+ZH@@J%dO~gL%J1^!Y&%Z9pY!`g
z+O4OS4=!CwI=uYKHi=p4v(*B;il$%P9IdtFZ@hlpv!uo9X*|DfN}dsvHC(|M#PKYI
zXJ)eYs~as>ws45O-{%$G5%GmhY{BcQ*oVhmuI<(j4O9IvkLL-$(Cq{D>%(G?b@COi
z3=?{?bIytsxvlO~C#}0saAI<8O;p53){kC0a*8BYu9FX+saBHqRhIvL?1$&((eb-J
zY1AH{N*T}v|;
zPyL{Ge&N$S&w6=Nw}b`9&Ofo4sx3-_#W*Jlbb3$5i
zW_n0*$->N%;*ya3?9{yC#)Zjci8+zt*#=GG=?36dRg-ueeC&#yX+e{?zd@6@HxnbX
zA!vAjGoj6cF_oExiIJ7Tpqz~xI>^N-z{s*7gC)%%g^7`o4Xmi`Zw@=7fgz|KK+?ma
z;G=4*IEUw6c(iclHqEoA-rjaNXDQ3P=3-L+gHeEbYwtQ+y2FO~d
z+Zef784NN}J5}NaqM%L_moT48W_qS`YEg-ff@fZ`o}r_GJxGFC*a9Y@5K>fHT#}li
z;BKN2l9`(tT#}eukeQbb>Q|W;9|Ug%KVI^lR>i4ikbICt`+{~KJfbDQ6KSwoEk=t
z=iSRbKTkjA`|FoYiSPa;zt0{2n*7mR(O;$ErksG*ROh$1&!)+3h)$`RsJ+)^cKt(+
zgq_+t%d1w*e0OHOXi+Wm-VJA}Qdk#@nDL#l*yHiSKQPmKo~#L1WX&?GD+Q|M+Jz?P
zZEdGsvHw>PnJTFLNdB1ef{*#B8mBgwbXkY+240N4xxC$Zh;A5^YqxI78X`BEAhd3dLKd+5xVN5>ni-_5;sVB71@7i=&8
zye4IOMyl?pljNi+t<0ydm9=WfY+b%G)x1PulSpp%LahgKChgPK8=gvf-lKL&cb@Hp
zpG!XJZ0a_4R;>8{_wa(XeXpm=OrE-+sh;nar;FdA>fL8tsstC+F-3I0>$qI1=O6J~
ztm;+R=FOR0qAJhld0oCY^_rl`$w}hXFO-;Bw_IHKd5yWE;@R0wQkfUJxLoCK?EIjz
zY>!W80jG25p;-m<8@~VfUAY`m88tCZHE3d-h&GUgsC}MT|M_J2_V3^8pC=Y3O9nWf
zPwaVt(lL6UAMEw=30qCosYesSzUg1_d~@0lwR&T3Fc1UPX5axv9s@2|w}qL*pm8dU
z!^p_e*kRDvYM=rWF<@+yfc9$glZy-VKod*JsYNBAu|b1axGJW$K&YzZM38hbib8!@
z#(`#GcN0*Kfn{K5E`sDKPzmGgXsDN5RDyeyGPx+nm~snp3=}{CqQD|)Aa20H#+Kg5
z!^py9z>QpNB30hp(6Pi+t+gLz)LC|}OK^O1k;7$PvO|&Lk0;-h{BN6fFXh^r-zq3o
zBgT4BlK%$d>g#7SZnpL>RQ&u+&Bgqq|AsA-4~B>>PW*LSv2h>Yiyg|%hxSwj?D*B%
zw5rtJV1KIUk7b|#7pbKMRVUUk@?R-g=(o-8hN0yuoA+twPAYWhUPx%=zo~oN>Ep30
z0q=gMYDKq4DJ^*s6KJo>e}q9oKDFptu+Jl(dlT<#2(T23ur8>~y>&h(uE(|8H
zj}nblkfHSeCMyIjuoztigLbFTeMayU9!lx@qATOC_!57~qqd%I9T
zEpxT1X}Obh{L)pQe~9k7@S;bEwNf&R@pMb5t&G;Oe`hAUYAvdC?%(U$mKRK7E!?HddM4HNVB3XFipv+ScYVUva6;lJ+tsVO
zht_7zJR@D|e#f(6`Hwg1g`wj0bFZp8`(+&M*>+ZRs+eK*%u_$O>v;OBWH`fRn0|VN
z-#9YwboM-@_rWruDgLjQUHh#lXg2L6mrYYb?&6=@GmrIu<<`@)J!;OF>MynJ`I8^c
ztbdQL>(D!Ik@EZ5vhG*ko%U4bwB5LCTHK`Q@g{5g*>r;@wk-xtEOVe09`Err;jI4^
zXX-gPEAd!)wxL&eNvO4qsDUu3GT{>Df#nHMeP<|XAPy4d78U@Fz$0feLq%{#XJHnW
zfa`!}BL&a^g@U^Yw5BsPFb7w32B4bG!obkb1Xk10vC<_}-)*Tdyv#Mjv1p%-+X0z1
zrMDNmWt40Q6rbz6wwHIx)|u0qbwb`cX9@P3iW}uPt@4)D4*|kZ;5&+vJ$Ub4|(8ro!q*
zYr&BvE3I8`iC;KhbHU4dTh!STH70TS%eT);Pnc>hm9;D9GRKv^WBHR9Q`RZ%-Rjgi
z`?t-7h!usJrlCzYr`WJ=e=aH_DyYV{+0f%=_Mh9FCtW|6T?`4jC*|GHQqg8}`jS*e
zLZ;2tQ)23m=GuMM&yW?H;Qwt!jpwE3La*y3k1aKQ6!3hK-l3wVrt{0!&7NTTH7!8S
zYl`ak6h6Zzg{Qni$b!oPKroSFw%prssMKR$C|e-)r6f
zKU#k0gi{@c(pOk)s?LY6|Gg{65=oYV{V!^bNcx7
z-a8sJrd@Sa{Tg}C?p$N$@|LI{C%uf*ZY{9ecrm2H&17Z7d5x#*nm_J}pWV={dFGAu
zwrqvuU|4+@YtY0PX&?kDfWZ?t90qKRjQ>$b6R}om$a7n7u0L+NR2ZA$b6+pr{`syM
z>ty)-QENTMHgJBERb}Bpsq)HUH5VfzOSVBKk@cM;OqT&un<)wP9Vnl=n}F*yXONHO
zS!@if3@jFyEih>_f|*08PJNB=YLv$yI_mM2>LQ{)H`
z-f`uh>*IcH&!);RZNIL*lA0!Y_q7hI?yFBl--4O#Oimx!Azpv$=iFq0L;HD7?#~ts
zYHF#OzubJ@GsiFD2M@4FXkT>C>e^PF*CY2e;u}LV^QVYS>t0IUQm{XGaoaZeqAT4D
z7a40xO<(Ojd3o0Kdrq=HC(k*@@pF>d+7S8P5{9cOi+lfZ-dy)s-?Ytaarh6z5>KAv
z!Ct}L?T&}$rwiz_Fs(9-UbXezUgJwu%zfwfu|(OO-*(DFMl#mKx9gkU-nXZ3b#$36
zU+YqyRdeJ}^yf5cMlm8t#S?39+nAC
z;F~)Dd+xt~c5g-3L}+w%
zU*yx-c;8TV=85_LjtOl1u6X;{%}Sqd>#o^R=I#qyE%g150RNuWQ$fa;j;rOYKDsb>vDvmW*Cu@P-?=@;poz8Dpoygv
zT5s{qmgxI=LHGIl+X0U_93-NU>n$Eu27^>e>n#-nB~X>dEG!MLw;YR$ON&xd6g*uZ
zRTp&Ogpq-Tfgz&mGBh+au!L1zNt8N+i0YG2owfhjgyM{QyPw2**%&ApWE#IYv|Ls1
zq@wMot{ahu9%?SPjaXea>+HH}=@#B22J)Y!msp6s4m&nIS9bNL%1@^RFFlFB#%dG9
zA0&Tlp6JrLee+j_i$#VOt`aZm7nlfkrp04KO~}$
zM|->fa)X;;?@m?6K3;p$KkljNbHmfOCdb|B>u_-{WeRnR^CL$8bzNgd)7%am&R74-Lx`vnPu#-pW}Lz
z=aNIuRxU`tyF`7@LVwGxf)V21Rbt%wQ@$U}>?oU2W*ZsnRMy@(J+sQ=!-GXa(rL3w
zPTljCd(M}cgeQkX6=zVV%hBLJ?QxErl
zSKPEoaQp81Pgi>ibQ}{_ZA_MMnJQJ5RQIi6!|xX<%Zx8}vOnCr{h9L;i5<(z86Wab
z;Zc;`6r!oxne&t{DA2uRpW2#jj-~gi*2MSPpWJiVQBWxQsX)MM!=tB)#FRMi*Z7p$
zC%;jQKcWzroxgE)TettAYp(Hg75*%gJ9?mh(Z)J1wV7X^Wa`h5)%|*N4_wwb6b3f;v;K!)2&}W#4>x(%f)lKHG
zIt5=}44N4|T|gC!GicdHiGeGmcCs_DF|b--vB0d&1ZEP>+6mK`9Pr{Mv>897jud$A
zijk3_V8MRpn9%1I@e3B0NZW1`yZ(KDIQ!mNYZkWaylIVFDYaYaN4r#Jh|=379p$-u
zr9{36dsXS{Znt><<$uG@9}B;KD!Qk#Cy4ok-vzCEzjVXS|NQcOjX~9{?oDx5&R=wP
zneD9jdRoy!k1aD#&-Gu<#w=W}?sDaM{fo#IANK2WFMIjP#OBR+=Hu-vF8Me}n!06W
zhHTieFs$#*lB>2aHs1LwbK^^SR7^-u{`-XiwtvbvGg{{7pSrEkYnmX##C%#|!uqyJ20c?YGNMnNw8ZR11!N(psnGJbS
z#up7_5OS=B{NlVurbuIg2HHr9nRpCk45SPs48&MO?j{+mY2(s0$i8K{)
zoq;~WC>BE{7KQ4sK__!g%We*=3fJJ%nX7*z<=)OeZr|_B5lxtP&@kQ7z#Q3heM1cc
zH3Jm`B^Cv*1@?<{uE(?-jhWov)R&$;XWgmI_K$PbW-T`P=qAWzj9k4jvNEtVF)=K3
zIoP#bez_2H^XAK+PR_sW*PL{I_aztaIUf)Hm^st#^<;PHz1t7xK6QGdD8bY->HXF%
z&wjk|6ju@A!T7<(q33a7=m^
zrXt<0tJBn{w5$4}h>mzl*Z1je3oMu4oc8(WjUNvtN-Y$4(jPJJMIrCagN~=0UY(V=
zz_FbBYvJ7n!->-)_jBaiJ=+~ORd?Z?m{Q)UXS$Y(S#O=>aO6YQpSk&6uS5+>Q@(Dw
zwlE;2+SI3}Wvy|>GRNNx5v&^*8nYXyHeIg_o47^V>|n9}(UY~@_vhOk|6k`(Qg3zp
z_`}VXXSc8mnAUcz>htDJ=e<{EoY&Q~V|&@&mv6L;#h)yxs&Sbp;2QWnE%dA4yQu~@
z!d7k$vny}?B4^60#I;f_<-3@5tjn3*_s_gIwAZ>xsno`m^?k+n$IOqjws%PxtgXDY
z?dGB|z58dSxQ-@?a!xHbebJGpcKuPo*A@Tw)@FUWt`auU!}y^VIiFZ}##3
z_A!Q{`Ca9YG6gPjUw?BktM;eq$E80c`X6q&J!0S%I%N!3zPP6|kc%z6RBz|}$zhcDqjXaPr?+eFM$-rXZfBO=EBG}bq~-2o<~N@&@30lD{r7pb
zXVm09Uv4FQjy5}SgMq;`5V{(ez@Fe#BSTXQV>5GIV?$$0T@!Q56kSV8<3wFc1EW;K
zq!bfVvt&aC1_stzsBy&Z31;R%(SWum7`$^Cbx$zUbh8_SH_R~8@V;Eg6~q%&sU3GqW;=5xhbVX#0!&{D&JDbd0RaY36PNB@
zFzNp*$sHTQe`TEXUBmf7Cfl|4*|YSe_f%i)jNT%JYNBI6fFV@lV!jjc9gqH{Eo)n0
zv*qK#W7j_z%e&rRW@>oJYx18nT*4?ClU)Ksp!zny+9fX1es$s_nFOxW|30_weW|f&
z$zlJ4DyK!fmhN>
zD;}1tBOCemddSB8x*>W=MlDR$?(_n-ZTAas>C?*Go_x-V<)iFgZ|)?9$^yNUTRM1;n+U6Y)LZ`b^|#XZ7Z;*#_(5`K
zQhi2+b$meNo^vU810Kn8&)cz}nN?mOHmhNI!da~_KUDjI{ez(q;l-YjEFJb#!*PM_
zt$)YW*O_hizg=+a3=9kmmq1xzNk&St
zRY_(^PHM4hZc=JW3aEz%SBcmllAM&8ms6CQ172ERoRL|Oot&Rrke`>DSK^*i8MtJ!ZR
z+b?TcQT+M9GVsO?$m9b910!f35a=8ONb!L+6rlSZAVI*$3km|n)}N)=w*F+Nq!uR^
zWfp+;6jYcwL-qqHfcMKNloo^LFcXVPGSf1XGZS+ZGV@AOb8<4%Q}dEj6-rW*GxG9t
z^3y8|L4(3H*#d;RF)70(6}0&xwJ56~u_!S&wIsEucwtcrR8TL!0JPaAGe57;9kTBx
zHASI3vm`^o(UXCJxeS_yh}cTR>;(!q>|2Slz(J#*Rgg;DULs=Z25TYH1GMn^c5pd}dK<
zVQFe{3CNrjV@qRm^CVMUGYiXPU6V9R3tdZN6AN8a3lqZ>1EW+kb3+pxdzP9pb_c~G
zWjIiNMC3Q(Lzv*6r6B*cY38>stoBi7nI+g6_5RY3*t?>$^X4CdzG+nadlfKV{upp+_%_
zZ{B~p>A>M%OcNj9lr!G-HF@Tu8t0ZxJH+(o`aTW}_^~l$`hWKH5XarQSeEjwiQ{P(VC>;7T;B(Y+v?U5To4Brku6Xp~x)SS?z
z8azMHCARPM%Qw}}4C2$7D{CKL-KVcS@0EY$`|SIcelvc&I+e{-u(!KPpL>JZ+~*~8
z9D>>lV-B*cn>YJX&c9vyH^rw)Y&dB8^W+7|sQ!$HO!7=Es(*KVnzHYHQ^|#cV)LiH
zm@KO~d*zLaS*2Tk*Bvo9VfU#2NWzQto$sFNB)z(S*r#d^M{Bvv29`_yQ}?ew$x{5W
zjd9Ba>4UAW|FHfz%S(bl&Rp<3SM`7lH^-lR(+_~INT3i9^+|9rLz2TA1
z))7&|E%a5X|Npw_dJ7fHJFJ*L2`|g?oqwvq+MP#kf=DW-TtL{)K!Yv+Vx}2B=`Frv
zy{YDt|6SK5ZZq{Bn7(;A(|zaMefzjlo@|;f*Au|7Qp->5^CRQHX{|P!QV*XhG7~*q|3A?9axSKO
zpE=9Jy+xwyyRTU5IopP;O(?XuE5jeRV2R_o=~+BY$$l%j@@iZ5Cbx?%R@YFkXxMDd
zkyvicXS?$Bhix|8cbCt-X0_p2djDhBo1uo`*^y>kI{Tg!RxGeLzPRJW?3`Vm?}TK$
zlUuj47&%?{(Vyz@?fHEDH7z%6c-BllryB7w)H5}Gwd4B#T4&ztAGjkT{rgG7t8cGv
zPWmkWc}n=-j(MutYczBJsqOxzvF4abqr=2wtpA^+8MCDAo%{2-)i2MN_opaYu6`X7
zD!$~9Waz4()eoa~-{hIRaMRJ<&X(Kn+VrrheowF#8r@HYy!n^V{L$!ss?q&apl!aR
z`>FCvM)y;V?xz~vPsKvsF5%JrRHOT;M)y;}r;HiFD+!nw8AkV0jqazyzMm?`ph-Lf
zwx22tr>a0&WWdO>Ad@BCAeG>Ls?3xb&PByM-MW(&l!^aT;NzAl
z6^V(DWVx&>bl$$IF^ox&;c9|^#X+}TW&tCG)BkuM1)y!HG92AdHM*f{bVJqXhALKe
zgV7CDqZ_J5H&l&os3N$5cyvS6=!PoL;9~6PhN{sGRihiKMmJQ6^BRqAs2bf+HM*gS
z@jnabe8M(^(G69j8>$Rxc+wCpH&hu$QMRFKxAnyIHx>SE?wf^7oA&Lri{9w)&BH*3
zWny4nZGLRtX=-k$TJohpFu7JOaPnDA|G)y}%lluJI)qM>Tp8eNmsRjk`-k%JPgQUC
z#~l?6<~tp__SVuJ`wqy~8+7;Ob9a3RTvQ;PEO4(lv15D5>cu;}w&ZYBzw5qsa^0~b
zR|~|oelAd3;43_DtI+57yHm=Kcg?s~y!Aj|pS{dv=gV6juG5>$cllW~&pE%IRq`xr
zCv3Xtwyh@q+3$&g_cmDZHF1A_za~|;-z>6d&D{%j3g&N`Bpr5rOv}AG`$@;l6T1SI
ze%{cwWbL&g&Mdi-m4}ZSshdBMzNZ{}Y+3ikXAHXA?K~N;UDiD%64e>E&NgZKs^@aA
zZ+%))tG(~{f`SK&+9c%#~O-b>5+8N3|suaZKwja|ke-aZPCH4$mz%6CW*J
zKk=yEj*_oJC$DUEbC`0Z@bwAfyv-&x|CU@b`g+x*Kz9Ci+jk5*9!0+~=d|a{7OFAb
z)4NJIuTr*8LXOSKoB!sgyhVz)-R5n$EI!v(`b2)`z5UB9Zz$Vn72AH_C-3%{<*xFv
zDStoyKcBR}ure`Tr@X7>`C`Lu#r_K~W_u}$#bs4&7CrHbvs$-u-G}4F)_d*hPL|K>*~IUYRc`26H-qi&Y19buu%Fu2Y|H
ztZX@H^tCAKyV|e6w=$kZWv+0(eePYk?ews__J=odJl;5UNyPge#=m#{wn)8l5N+QR
zx$*y1fdZgQ8yOfG85kG>1sPZ%mpC#o1PUS8pasAGZ!a&vKVa*6T_@CZtXN=ZtHN{CC#sVhp$s>+H>DCsGwYG`WfXiF*R8|!Ns
zscUI#fec|}=iuPt>Qk2-2aa-Y!zT&Vq|7!Vqs=wWnp1pV60_iVrF0wWEE00bYv3_
zOk`Io6ftU?xR68HY2!iBpoX!XqN1l2cOC(lau%ic3n%$}1|Xnp;}i+B-VCCQY6)b=ve9GiNPYykzOJeA&aSFc^aar4&0M~|O8efIpt%U2&ieg5+G+xH(o
ze}VkP$iNKt6^H=&ih%*mUxExwj7%&n%q;96e=#zZgA@p|uqqm|2{{I`Cl(4T88vc<
zI89u*@gS$NanJ|Rq@s&lVk#yNRX>8f2KE_o9%~}YXK;@p{B?_ghnbOqNsw8P!JgsT
zho48XzpR^hE^%G5qh)XQ;^g0}K4=-=Xfk}ymL?x{{nEb|YpVBu-MW5h(V`yvLx;A#
zxS78@IMVE9t3%ye@63NY!hPj?Wxm?6m2JC}w>|i6P`+u@@!5r8hH>ZGXSC;=>^^HQ
z61d>#y^MRAhHe@cSYZt2%Egt7MRFHA@ILE(*1IKl(F>M)wHbFZjxuJNH6+hEa&;Hi
z?a7T1vzB{3Tyw4~O*o+_LA=r4Sx3%}h-mP0fr2EQ_X1Y7pM*ZtgX0@${uG+qA4_NF5jZ
zRLff+&VA*2^;#j_lwaZ877wnoY`0#xaZdQ!pxyCPu64>>)!z7N*2&q6=k1K2w;=TA
zs=FtCo(&KD95(%ecj1$ot#hj^OqaQzj{M%-94O!MqMozo^;tX9m(KmO=8KkYUwEE%
z#U}n~o0rSXx?I0I^16K0vU$&@hP4`5ER#oMvt0r^psCyeaYmxQr
zkQ=L96-7S#nr=Mha%k~UuPdjvcr$291h*=eEMei(64EMP(VNkeqNd5QJV+`@`KX>|
zW`@8eO+$Z^TL}`2MYaSmCG`YdbZC1tS>%H+
zp#vAIh6tmdNE<`&Mi0#gL6Xv3t}>TzO{}`i_#oiWoGqpvCpwm|_~~kLrTcs4M!_A+
z7=!G+5|(WfR7rleS|PMz*VTzZr<@x7jw&qYn$*BmAi@>s!OAp;m1&L!qoLnXrYS)Z
zj9#oF4>TEOEIq2L%b=#Y&MvCf^xs>CwAjCwBOh&9cl=bg)%Lz){)Hd;XM}BGekwYZ
z|DNdj{O_(VU7Z>tI~L6ih`1Bj6&1gh!Ca)J&~J%-S)=54n`bK;f1kRr^L>c>uTwX3
z+=D_zPP&^Kb#=vUnP9Z!FKf8c8sE^f86D{t_sQGuj$c}`{BLNn6yx7pf3=tYXP6fH
z`6_=Jo9**ox2|2<_hL==`LA2oE-euau@m#ny}0Fm+5C+98ZEQmTcTxrv={Xs>(Q#w
zd9&r)-xI$=Po2NqmnggHKSS0xenW0orfE$rXQfvxSz=i1r8#B6r5){EQI7vAmacrp
zu&B#xUILfKlBI(N!dXDbQ7fAt-2;7eip6_k}Bq
z7S3MkvQ5u=&bOWa8RX8#_&i=)HtXSk2KTJT%j0+pyo5b(>FA}}>&7l2=mn>c2B$aD%i7P>5OQ1u`qAm?ajRhASI31TRS-=oyyG*L;@2wn<>?__uCj<4P
zYFT{6@2yr^?RsrZS6h^_2e
z-L>kY&AmmJ{)IG6H}zqfG_A|QTy6?il%`>qX6Ay+ttl6{Jzd$BFip60DM*rMuQq@1
z@2xw{y^dV@_i$ZR+m|!$kTlxs5VmdV<&SF`qi%)Qug&#-WHj%%E4yPDYk2d!t_|A7
z0^kT+)Wx8wnW@153cDqXCN+qJ1ecga}L*7k)YPxXSs#yI~*^<&np1qs?+%!htwCqjIvsJ4;hhE4oJW#XM>1$nZ
zRAOD!;+p-sY4i7#e6jrLe%7xe=!{)fiPCQA3y16lzRT;T#q?!I9zPv9-Fb4be{s})
z&UuGt)s*yDE_aXhPwujwoZPkAV)gvPq3Uv51@7EiekjB?lh@*sVDy|6-@sW@S7~i=
z=5l-KwU-B($!ui{k~B~BM+@@gzG5i*+A6_q4#IrFWr2t%N^r;igTBTfP5%q;;7
z8Vdp)cuj5dW~<*_$Z-agLXT#|)n1N#v^`qVD5CCfw&Qo#l*8Xw
zNAd5{Qi&;37uhmp>rAIhK^GlZO?L%dGWSYIzw>=n=D$trV!p5P{I_ZAi}WiSv^4j9
z^|A^v`uj@2Xvy6y=HTv8mSm0ZFkrC|~z!Bw$DWb2#;jYVAzTwWSWj3jr3
zsV)Dv=GvXT+QPyA8N#yXE!@Ln4oaYcYkFNpS1&F9bm*RE_go_E}x-D`u^
z9$D7Nbe5)k=;`eV$_A4fxV)mg95hy>|6aCCl;uA|$+hAeJKhyX-M?dc
z*2iMq^r+uk&z-U`JqSvoA-6;Grav{U&<)!aKjoT`dFR>K_2;rytv9XuSXUf6wJxic
zZM%$k*W#M}nrlttw5ERg)3(V!cxg^?G5`Eo5w2FHKUXHoT+jaDv-qQs#m{WLH^otJ
z?4nNZk(o6sKR9YX=d8oCN|I-}$vm1bv2Odu!?Gtge!6OTG>-Y{s&b~yZO>g@-%U9m
zmAQQ0mdmm1oWdb)%c{E83LFSB)mXT)k@-rf_Lb6%W6`b3L6@XbdX@(TbtNdi^cDH+
zyTH-YZ^;6dB}*4vW&|~RoC3W)9k@VA_1IRkIaj8f6q=){>B?XeymHZ8kA<$_1nc&t
z``Xl%;%k{yqok&0O0QMyG5Pv?%i$n>P+Il8v^Z*#S8vtjXpUKWTT?#hK75hXU`ieYs;9DxvG$n}f%A(oc9_#^{ni&#XZbB0)=gjGIdDFWt
z?0%8eu=d(9pGoq2L1k!Uz~5Kbn%`aVE_&qarLlC)DK3pg4MG!l1znDQH;du?u2q@e
zUp+lvwPOBj?Yy>H&!f)z_f~?4h0L1%*A}jP_BtS}JK6ZfT2S$M|I?|Ry->!!vh?l3
zO26MMK~Fmn6-sx2k+cWJHo14^WY`>$RNsILt3|FvtG|9kDM>KUh#*I(jGjJoH)
zGv-~-&DQLNJ%1MMjo2+$e5X`$!Nso2Gda98GmiQjaC)(7EEUyr5D9d3IMg>KD2QRn
z(j^NxmcERbHT~D-=%O#Coh$z{tTsI#aBpVQ-z?=I%V&#BC$88EPM)sW8Grq+ZCm
zxT$8V*H1g=sH{Dq+E4%9T(f@Vg>9DAtv}DIC@tF=e@}j`ndr0K`tK&ncTAlAbj|LA
zJ=ad_pN=#?-8C!!p4rL|Gj%MNyIC%5H~G8kd`Yn$7T
zl!U~+bhzxXlH=Ko>=h3ct2(Zn4V2oFb|A>yt5i8aiG9VY@D;0Fl68-Yv`w3ES>RN`
zvhT~ek_1<39-HmJDzaq?hZm@Us;a6ha=?p!udXT+qqoDN3E;$fYay#eaOR;2d?F7$
zy&aB
z%+lW*)*9CRJ`|i>HI{XidK`r$)8o(*wpEvF$(3$FliALm8|QmD9SB)3cXiG0&N8_z
zx^7py;}Vv$iBA2tzG|N4_t1#$Sq#r6{(Ea=c2;}-v`Lcl%P(AIym0mPzP1&8ZQHf)s;uCx1oKLRJ}7k_kS?FN;+SB>f`!=?Ym1}6VLb#30W{N&Xa`4XdED%tB6{SvNw
z=~{AO{*>@#+iY&;`FeYLJ2Xw|iUOr%1`%+D7U;mLs;kQ2YJPW(Zt&m8wKuE6#8&=W
zbKTatDvf(ih})97t%7TMolVy+p67pUlXkefy>V@JRJ`DvZ&n#rTwAo($g)O?UP{mv
z0U0C`zzA)(HfU-rn!#lin)yp=^Q~2PYA;8ePxi4n{rRdYhEpZw&_
zRQj_u?5llQHs7+>$&+@0(=zL`HF5gyd5u_~?Rx*N%U)2^f7+(}%WL!A{LEGk^ypRJ1vs`U=
zUG`YF`Mg3^$CdMeQd`m$m?o}t<@Iqb7ZqGNZ;|OD!)XsRdG$0*gxoR@O%{3R<0O@9
z^JQ5VgCVpKUb2iy$}37kU`pFukIV)x4Ur(mWs{~{3I;W43l^|*MLGH{F@zSvSGuoF
zeJQ@yP?$@qb>T~B8SD>F)sb4NtD=ScAr0E^t4^#)U3h3(Yfx5b$E?|l*4#MgAF8&@
zL+eoV?-0u+87sGid3dh8blne_hQYAI#6cFw#>_v?R>Fh
zIoFv5pw{6s`@747j_%`bYn|3+Q+1~oxuUhsc6ZI|=ERr~T5zH>Rg-`+Me)4n7u_WQ3>S1#GT
zSiShermT0p+x|0zhsgZ4DoTTe>Fembn%#ynN@
z<=TF;c)_GDjRg}xZiC?^i@F#z7IiUn#qY}I4*Aazc6B!-Lqvz$I#;FJJ)hNarT-eJ
zQ0KaO@!#j#Y?ZKeeRXNSu5H<;Z26|-+h45AQI@Rz@@Qh1~^-ZOj$Om
zflFh_0`{_1+vQ8H&VRUSyM4(uQQm}NsrA1OXlwaRUAd}$o#;$;uLl!v3vTSw(w_L~
z%Ezw02Q^!JdIitl<-aG@X8LT+UH&;&0{dqzUzj@M^3zqU+!IolW>|
z=B`+=e~*1s>aNdW`r$%Ssk{DMyrpoQhcrD%hlIr
zbY7ddGHl{Y-BXAnUPyToxIL1&P}ud_+68Ary4S{cl&qN6HX%G^@#TJ-xJzn!2Ji7&ZI9
zXFi*Os0ZrS-ub?2;@{6vUyNV*X-V3B^#Ktal79Jn14B0bebu$qE&akR&cBzgd(>YI
zH(pS`5;CSybJqE8XKzh?Wz;PHyP}gpj9cz^MN8_$Tw^b8IsU!W@jt`0(9i$Yt+4-f
z>XN)5e{!|6y=j@)@u#9kU*!Hi^=7UADeWu$hblM!=uYZ#^!90hW&lP|;@4Qz#RjSr
zob{a}s+RxSw)SL|)Zwf4S51qrm@O+_e{GSe^4Ar;DOsYc7yo_s>sr8CU-|c@+1`(g
z=N%8szqGb%W&VZGjj=kRV)2?9)*k2f4ZuCF;}*PeZ{N!2a+~CTdcG!@pDK@c;R!=J0b3C{T?k;+R{0ttL>Ly$_4Hd}03Pv3$@kcsdEPf}%P)?ZnNm|T
zr6%1;=JnWLwiwi(l$dbRDkM7y)JD(nnI*qBN|28=p#6PVkMq)0<0{t`t?@kxTuV8g
ztydR4t-MxftxwaUsF|!Or&R-k6;@mbIi)4R9~cm8emcxym3eQg$)j~ACtrB_b*F{t
zS&z!Kd$WA@*}mreb$z{Wq+G81ii<(V3bGXaox{#dT%L1R>swvanQd7Y*`KbFd-ghM
z?s?~s<6b+9FI+Xev?W?{@5#j9SJ$)O6`ja_Z*7I$TbJ#6*1|!Tg06^&Y?%_o0ICWu
z%fGwq0P2lS{QEiVo%Pj-e?LLZAvIYoNxP3Lk2?_(gZeFxaZQZ3Se-`b?Ros6mYiRmT3sXWe|0
zvP4%do
z)4vZ_%DO*?{++aI7T12=$hFe!WbC7x9^0QXs$WHd8Gw(w|PX__|S
z#J!1Cm*>seoB0Ja{Bi@9{rHlzUst8Ct-5$ouH@bV&C|Xj4}B+f
zm%VKhU9wy|(qN9kT8s0iBfN_<-Z&S3&zkWv?48}qRn1GIZnW<-k+0gC_DVKP=kCHl;H3(^qrb7mL+C|IN*LXL*JmL0uxy*Q=LF|K~u
zK0Tq`x7p4l?aj)+Yx8RNtn5p3eS?qcX24oCuyQ?^VbP>62Uq>OYjnf^28X@bUvf=s
zRej0TR_Ca6vuBG;zT12b6ponP#haDM{=GL+;o7nZ^;K7w>UW&0mW|zhSG1sHRoMQL
z(2JLL^%Z6;n$#dRsY{aq6bwOut_DI~8VgwM%T~nBpK|rt@2&I8zxx)4m@O+VkN^1L
zYEabH;$yUMNhXZf&&su(^{alu{;OEd1ovW@twdEt?@6NglVnoK@
zl{#7Dy108r&GFZs0zX?lE&e|Ib;-r9>Wh`++S3>HPltSEJv8f5YhBdR75XQ#=kedO
zia%6b#6RPTj@FsQ&rF&5v@cso#vXNWjhGOkQXF;Ukh7-LJk2#)ozM;ixUP^W^jl(b
zQh6y;SD=rRl%t=?MTe$lZ&wC$k)-J&0nCMdA-WgR=F6nHb6L&07+uiCApf^2XllE}
zPRY|bZ?7{g70a^wsJ8CyQAN@DThdm|(zMZ9+!%V-F#PEOnX5^yKV`KRE2Ro8=1LUJ
zT=-=L$I-00XJ&0U73iw5Owm#QplZf{(yY0eYdc@XY?BH7(eAZ8&n{}Oz`D%6ez&rno-jXMtsUTEz#8H8Jl#pn
zF-&NI*M_N@F*B`|N>*!VZ7Iz%>{_;_uljE94vW5>v1vYTS1;c)6WVdMC`MDXB=p9s
zjJ~Y2(^AcQy`HNrTJM`v`RPtnpr@BcLgyljtcx9gw$5mub)n^Hwx*Pep55CJS>C8Q
zf3}8{EZe5~&X@h3=vw}}qLbP0t&OOAvF7Q{C1vW1CIodgfx6z1sz&AamJ7yKkN1Z6
zzYp!6_ch9XPj*~et+(u|J#&2{R(&d6q;RU}@2kEg)8B`bE@a>KviL32w%(JUeqFa;
zuBoLR*eH1YOlZ`6SKf~0vrDFKUvm0W*K>L6*ZDpw8f%r-3Tw@t%k2B@#OndW%V_hTj
ztQj%-Yl|o79*Fbxoq4pR=*pYo>b+;*Z_!^XSM}=}|I7mGpr4ofj`i1Xh%7g+`TBL~
z=k~P;e;4IDdw-j`e^+K)Z1YsTmQBb)>4*BZ`3S%KTG2?Yhvx*
zsqQG>s$wGvvib#c$VN
zYoF0Pb(Z9kvw`BPUwi4Zua$XW8Ch;JHTbPp_2t$RUzeY2J$2e7w6MT7^H4&@GsjaW
z=lt0^x1ugM>|Xq|&FfR8d5f=1GF{eJmpt?K>(HkwQ*urmzqeq*#~35)fEO#~zq_1d
zvRQuG=G4Vfum2`4+5Y>`wAX)ARrlXp@=fDIiui)&YspNRIa>A!25wp~*u=J0d-D3A6tnxFaS
z{LNI7w^;YCMfa>n_|sKYO@G?9D8x?)_4TYT%bulw&#Fph3rO|4M{Ca56$cos50vp)
ztLkuQjfWOaL1r$^=ua9JQCUlr)%WNNk~Z_23z
zHI1clvACs>yeLDqDdPrgt@0YmM!y1NOS<
zW}y~S^=CgdJ@R@|nooFq-4Ev&yY*@>&z2-!G~H$tH`A{ww~FIIb+?zMrYp1D-mEXY
zpRTg5E|@=U)5Jp6*;7{?-s`XUGmFtThrcMp?rYZJ@7Zend!sh|y%_0T^mwDKu1WAJ
zF0n4JC~LMvYz_)
zR=jrNFS@ko6xY>B{CBU~D!Nb8PICEswPvsT$}ffnsy?34Qdu>NHs`sit(|LFv}kMh
zcc14U#Ut&!mYn>3>T1c~y8(&6Z-x9*O5JE<_(6Nq#kJE<1ovG%<*)oz8J{U7TyZVdIRP_N9hv+N{DhI(lvh
z+96?lgUKpP_Urm7MONYICds+QzqTZw%6h&cpL@>bU@i9*XA^Q1Rxao{@i1(m=;Ebn
zFZ;4y9-rlDl=fy_?AFVh*gRJs_Wf=@H-2kNu4rwN#JYPCdhPlqyJy7TJpTJw|C?{J
z64%~O(fHK9R4<}T9weSP`S-EuZ;I+GuHB!a@u^j2!yB1P?~-aK#lM$|-|S_5?fN85
zoB3HW6W-WWN<5NuuPTUi&6?r9RDFW2R_z@2b7vktir~*Ppw%xV0<{e){LLM&Ixu|8&~$v
zxMIfqOyrkHo|~Q5iEHBDeWMNgCv7Ti{Jm_=uW5Zsg})Db3j93kY4P){nd0ZJw=bOT
z+}JL!uxeM=zc*KJ7k=Veze4|A|D~Nue;+Sic*4)F`0J`ST6YipeH@x5`f6>TTj+$U
z5FX3bMqG`p`NEueMzii}{#dp(khM}vIoQ@IJ0wx}(1flsO^#)rk}{XNcy$dKU-}%i
z`Lg6FgPO)sJq@M?*4Q%)uYB`wMsp-G?|l6}WXtW?_sXDNAa@1?T0>koNk}*Mf{oT7pro2Y`y%b(~U`kA>2+Y+9e<=X4;cR!Sy0Px>r=*nss~S&w!M_
z**8ix_v}u$JjPn{`;qqI^3``d=R7^9ZKG4UDrV(NVZpObSGBLW?M*54$YtsZ3~}I!
z(#&KCy6EkZlIyWI^Q^~KCl!%iFHNZlHx6kYUTSjrxR*r7y}5aoORA>b%&6yhyr%m?
z*ItHIg?v-11RGL(tC-8h-m@5@Qs$RUH@R-F%LHolXZ-sbxdYPZce0vh9U@d}YVb1P
zUVv{5^HC&zk99h_MahS>qh-wyMAWPp6|%a_x^9euWQ$)
ze`igOtzRb}b^Frs6WS3qEFpKUPN;jeS^95j=E;AnHl6?VOY@J*-d+jz)3Iq?H(Tqb
zo{Ii^>y=6H@2%_o`9I2tezTfU_hRL$J?u|KlXgX(5D9cuY!#WZg&_zuT@dK$zzXgZ
zf6tzO^*_Uv{g-xe*1cR;AO4>q=<4}^TQg7ZkLtLx{`#zrYibX)gWdl##AWM*&Fibb
z#D8h)(vQkk^Et2I`g<|FHDK%SMeFswUZ)$p^3qtza1=CLqy}29breEMENXN(cET>|
zS4}%*
znAd*Zb;r+@dHb&g-TwQ~d!gGJ`I6x0@`}q2es{I2-x+B%@${?YXQsRjKUW=FW|tiB
z^6_(Mo;`Jq{aw^HC3%H4YZL08uGU++xP4CDhrgK{`R4>bm)~O_`z3}&SXqZgs>4m?aty-sjwePsL)(NfMd|79j
z79>W4`T=V!mOq+xxN8&F`9Q&7TNl@?zREmR#pOv8x>6=y>e9^YaQ5^wnZl5?Y+J*5
zgTNnGBG&5K=hS>RHJUoHpx=1oY91wvt04)DF6~*fsw}ia^`G4qJRTeqb#m^vK)2L8
z`%>CvwboTG-|OPXTjm-W@igyw=7-0Azw#go6Av2
zNlFJ;UD~R!%sT24}3elLJtuYOWu0HqLrd;0>)e-ul
zO(fLfxYw>Zj4_j}7kRLn-kRgb8eaBnu4#EO*QZSzO=7lY++Oc>ew*al3~`3wRcBtf
z{hGE|q>3qGpoKTnM~Od
z?s!II%ako`8Y=^?I4y~qX5u?f^MsZ`R>V@o4l69PSuAp)>$+&1{obH6H&-nBeRa8$)iidm_3FXFT}^(=T6k8f
z-!p;b*nhqMmex((sQ+u#@r(6W)?eDD`kx^*UOTw>MMC0TP)@yj>EDAj(vyEb{JQq8
z@jI?t_Kc$DrmFV4)*Sw~Z_CpE4B?UO|Lin_esoMflzIE_t(PWYKV6H<{xg(q|C07x
z?(55dAAMT)Ij=|0pAtGTRJZ?>*45I@Jy9BqCa{VGL5H3KJsr4RRYiEZ@^@u3gEH%X
z2Cw_m7p|)h`_B+^-|N|mT%V`+7MUu~pFOK*)`=UenJ@k`eEd*1b((gt+kb}s$zRrH
z)_9z&maSdy7(RVzz}6R9pT4YHR?G()1<(b}AL^=t=KfSg7{H6Rj(K0&xK;S~wzZx9
zqMa+}-<|bj?Z%7##e!LuRl(P0n|nQ+c%$vG-|Tmn6PKUC>*dZ{U|*5Bk^dgoq$hP>{$@_(pHrK?exa@JZU3)HGgt86nKkV~
z-J9V2wnTfc$G_cPJbHKh{j60MtFJc;n+6vit=f3wdG%D85Z6
zIC0hz^_3A_0h(tlmoRNHVD$EO(~w~F?qXPaRB@uIg3RR`!4A)6+PZhSE$_+>l9XJ|
zH>D-GHK5TgYTXe7*09c^t3`&9zOyg6cC?%3gl4##CNC|vJ-2m($Bn4aDe3&tmWy*t}D>jDfRyIvOyXvvpJdukDJ3ebJo5`!uGpnF$UW5CNSq8p-
zipzgGlrDOh)V)+CvpH;uR|nsg_X~ElS*-e0YMOF2(rQ*ATj=EXA*CvyN>g&)-^KMS
z;+JNhsV|MRau-;CX{(z3uJuz^?)(yHs8@fze{Fu|{8vYdzq9{UsLft*ng4`##viug
zJC~>bjZLdReKgajzC1GF*`ulY9W!&XqyOHzeTn~E-PX?B18aLVH)^hT>;8VuYV}=f
z?%=7SIicFlpSpHgg=bs1E&`2dd3rmricASGSk$E<5a{X3tTg-GtOJm$bNjR3%Ql$i
zf7So8F01XzxzMw2neQrB^rqx!m@Z%ZpW*n)UttmUQ!`&2|Euy>JE~sDc;4~E%nPAk
zUxw)VGp*P6dX;YQN@LN4LtPpR96^~|12mA<lIA$*SN>GeMc}THE1k^Y!npc)0xZ_bf^8Vx`ybFGc@-6}^71>;8M9sYDs(t!qo~t-4YB%Sx<7u=Zf&t_^=rhfT3B2&-FTUv%H=%#woZ
z%HMmxE_1O<47&55VXb{spZz}V)eCmb-j@7CB(DF?{H40{e{J-xurJA;ymFJp>5HAW
zR_s_S{qgs=Rs5IsTI3|^o|?q9?rN4}=!|d|9~Gk+f3NRm@z(HvKXP$6%Q)frkG;a!^+ZJ2!J)v_%*E?VvuQ8~%nzEf9=tUH_bR!BW(
z)~uUFS=;Yr?a!I3U1_b{#XZZdch`f^BQLbJI5UJUStn^duPe;?iACRrQcHv0=;Ar<
zG3VB*39k0idUI~^Cd=++cQx(4hFtk9vvCD))x{g1p6-|u=xXE&T1Har#cMWg!trK5
zw#6b}ml&n4oR}rD^1_vklU7|>wIC!b%OOkBqk?I!58HH;HoKn7#cml)mb}jQmQGqI
zo3%^$N^oe(tE`i&E|r=*;#sYJZ&@&?IeF#G_qXbQgZ^s!75`p!_R@~lx~U5b>dWKR
zgCE)Tsi{2wt5Tc2@Us2YuIFm@FO_!b8o%SZTf$O}YQxW=3q&b1e_7`(+7QO1-B4l-7?mw}n4-U5uOh!uY(b
ztExytl%}yOv)H6AFNT27l+ZQgTG
ztMYK;T3wm{3`^ygrZz`ang6MkUz+Xz$gTLso3(Z?R=>Wq`E3=~zP+rao9C2@Oi7yn
zs`VJQ1O+;9gC-&aG&Nn-Sc2tv6SCT$n(nsz>0A73;e+e4$*X40nJRNv%jIR@*-JZ?
zlrG$GdFk&hCo(_%z13#7%=i5LMfcwa7Jq-S{r6SXS)e+p?x{PwW6;U(S`sqM~xz~lZut|$ewXe8sbrTX6>GfNZl_Dq=#j9(`k;w|0We4qk
z;PQ%ccHo38O<5i!m7uWnC_~Vr29@|-8d>a)j;3sTIXr%@V45yz@<8j%8a0jEL9EMJ
zR_+W_=JwvUl+*9i%a}54qf4x-+3d554tPEY-m%6(Xu{I$=#1;vT{v`8YrbAB
zylJ?rC~DIb@34U2;G~aUmsSa6N$<82sSHeCbhR>S#`R>`EU`I;t6HKAS8KoM7UbD(
zx;$s=WRU}*Kk}wlU%9d~Bx%~RRb{IUuSLbJ-x}$C^sDHJ%hsIlW^?}tS6}0OCG73h
zS5s}SYp*;bdycpC;iGe2=biPO&${~8Z8`NN@VR%P#?nPiE=xgkeOsn%X$bTeIp{Ca
z=C##Gsxhl%rN+!G$3R^#EiW0(D;NFQmLzoe}>hfXHL{#YQMHC)*PI%f_`*=Xa8P0Q~pm4Bx4<`zmysDqjUP9+}nRIhQH<0
z3)}p5-;34To{MwGPPxCYFY}Min>GBWw0*0>+~(a^Ses%KzU;h3t*Rub*%t_|b0D*h
zK|z<8H21wN{XO^4Grw%%)GH@<
z{{9mE_o3_g`-}Lt>=Maxyb!Xf_EZ~R)6&WB!gA91mfu@><3Gb1(ej}8A!|UnYw?2i
zcU%is*RRZ9n&JGNHT~88SF;vmJkqPbw*A_o{`Xw7UW2k(;NOR_w#+N{C;wX$vOW2`
z`pdu@^{Yiqum4*7Wu5!ZRTg{Q|Jg}xzP~gx%O*zZY}J>An+#JUwKjiUZ4_FzZpMrg
zeY39oN-kM#tbH;tex8BsZO54-c@h>uH3hA1;ZqxY#*M%OO)re1(T-SE^fLM34-cP&b@~0L>%<^6_
zRdQeZ>@_amR&Vz@8E!Epx@AN-au2)braTlVDI-)+4j6^9sqgz1aRb?i^Q
z^KrI6%d6`a_UWIFubvZjcllxMm4@Fsuhu%P%f7C3d1`(8m(_u{w7#vGr{@)tZ`nA=3tE-lo9bB*d
zai?(Rx~uT4{r{w_V&e_wbZlk+)lBEP9xznQ>HNi5So2#$}JD
zHEdMKniww{Z?bcV(T(XMA5DYqdheUs7AG9ishi$rsixatZv*VB1dLYyeU)na@8hztW$F7f=f4VD7c>9vRa@h~UVpW&
z-u!#FrstpX%cLa3vlrIQ_WRwmv*y{G+UymV|2V`ovJY?@2`C2g-K|K4p@
zvVSRRvQH`X!|ZMMOG0OyQ+IwJn!E4C%FmtRuVVx1K3P89c;n^T-&@yCu?gdwcC$CT
z$oNy&*O||R0zF+lxLwsUmN8xQbXDNe)POLQXTQ5{yL$c|`%Akx_q|+K9d5s)erfSl
zvt>nkl`GC#o;Nv^&0OdTYHjL&ShFG9+xuk}^GvqJIrRg?K;OZ!(&Fa7>#s`fXTKxr9`c_d4*N?s$67Yi3%GdHg@S=70}1O1=vfiH1A%!==XK*pVzu)zUe6GcQSureI6Ky6&Z@v~E#=JLldL;Ae#vj-FVk(~f@@Y|Ye;!#br*cL8
z-0!wO7Hh-AR^PEN>(AKvQFo8R`?>CqBd*6;Zgjh)ey9HCvpr4TFH*W=_}9I`(S4am}HVjO6*%@~|clElK=w0;e
za=J2m)taLvnoN^LE?t?u^5*0-?Maine6P%0bmX&Q#qII
z+MTYt5(~nGx?%#m7`$SF9!=q5C=f9`s_GTDRp^ap|(I&Bph)-2bZlGEDFMyI0%h{#z09z5RRXC*vRe
z%Q`#weN<=-T!H
zdb;(PTK~PZp4abw*@85)rQdziBmOh2`IGG)^n2Onoce43OiDCfD*SF*nU(xq_si;S
z{}~EGZTX`AZLFc;gj2~S%P&i<
zIkWDo;L0T{d~eNfE(rYAV0|rd#$}(iuiZEC=k@w;OX`0sv{!1A
z_xz~5S9Qk}zqaM{hV(yLDs`Fvk^S7Hyd`Jl4#~EDohg0)_9uO(jQj#RsyW{b+4w&1Qu)ZFGdGfw&%g{ZEay=tfDx7KD=PWAWVuR}Nc_x$@<
zx5ae9l-ud`Y5y5socywC*X_sNv;W?jb>=_AV)aX_vfKZu7T0PYS+>8TKWh1*b0%BE
zX6{Q2zMA>(YxTxEA79y*^lVkjSS-4-^~TI4XZ19WGVKIq;jbkn@CScKtDU{{%DAyhPo(GV&c^k`Zao7LjUOFexiFZH@}@r|>8
zRKoJL(S|C^Rn50rYQ-H@in}UYzOovWD|y!3^;Oj_U9wu?`&sM10W0(U->s4bG4%c4
z^@8i?MM=l%FSB3UwOf9N_T=W-2V-NW-xa;6-*75kFzNZ<*mQ^bOWIDL3VOkRhWNeV{q-QXJ6<4_+G!XIMf_m
zL!Vr3_-ux6QkI3(<%{Qk#XpR6xHhk^{<1ySrTIrX<{i(@s1RMWyz9)C7uudyTyHGf
zpLKa@FkYFtWKn~-N!p|?aGqpcG})wVWwNXF=1;Sp>7W1Qux`?aKg)K`emuMD!Rnni
zeM(}rtmp3za=o-@*Y9OJo|G)w!~Sfw{&%e(W&aaeU;Z<^>P>&S{E28?{nyZw
zx@QBAzq&eyI)d?Ptwz@9(bX>G&)s36MmNVD(
zB%4Nb-Mga1DIBJ_R#7jt*izd_+0$QXLf0m?##uqj<}I4zE)r9wZE)0R*@Tda)h>pH
zem!*`>$W7#7XoFSd58O+=V$(BkURNh)vWtgDf_*4X8&i9d--M6tm}W8Q-6hbdjIJ7
zru9eXabf6ldE4lt;dAS%zANv15^`gGmtj!ulG{-dJVz~q3zxI5T;May_eN%H$F$wM
zgL@~g)limwRpuD6tMA#pvk?cY)BLsy#)NG>#K4>G!H{*;>sg+e;!!m%pP;0-SjCY#J$z#iy(mf?btSD)WhRd;o-sXOzN
zv?gX*Rb8DqDR|OsKd)&fp0^g|eO1ru+O>g~0v+Cf~K_^U4eXSmW;`tk3@6<>q{h%HO?K!~Xqi
z)r)`cRyh9KwR!mt@8r50e-_Qx{ORkOQx_QI`Q0}@*tp&$|L)q-u;))jPrT^;y)ia+
z<4@P>jXwgPoPVU7)^jN+t;szNGzOO0uq6%RiCK9WXBl+$GPk5n;F)oRaLxz%_=@>zpfVK$dJ*YLJ8M@3owXYl!>t#7(?vHTZ!JNR2I
zYo_L-%{u3qwgh~PZMRg*IBRZ_Hi7S~B&Y?!cyrP0Suq!wo=rBHx!9y3=7K-lq~=RY
zdqwj3*>-jxp1ta&KL4rg8N2LXy6yS3d+wCef+Z{R_Pt!0^n0u5^}D7gm6wVt*qcV@
z?+kfhZyTNbDa5Gf_TtY$4jH?CUzzqdhH+bJN>u(v2RY`<>
z*aiu&Gn-|#L;CMt7x`|*BOCL`NLxv|Y{th+Tfa6Qf9!KviI*>XsrR(GXDTa~CoQ~u
zAZp#WgMNmwiVe9hBh3?Zj&KF6cyfA*knx^1B}=r!_%vs*ZQD6_V(8*!m8HdL83NC@
z22JEswVkRGINz{tYhkX;7dQJ>|NP}XpA`g7UjMyp@}vzKuS&vB|8AAL>K_&VW7^3t
zYj0O8%V_V+nzuS{+11APakiRzB~_)S-4=$z6Aw-P5h8T^MD#oJr?Gd}?n!jGWv}Jk
zopG)%@Mri^nV@~gc~+S9ai1vsqyA~xj1#Z4*H633{-Nvio>m7Nu3M&4dQzQ^$(@>}
z*j2nvYC>Vuy%(pa9o;fJV`=s}t#!Y$P5rg>-b6mv4Y|1~D||&nSl5ZOcYH3+^72Xo
z7w=4uo=v#urrD8~ah7fNy%lZNCM}l_U6x5|kn&Z_Izj9Um`S<3c
z<9`E|#m~Px>nHn1`JipaYtH|QEiG$*B6{*>acOMm!k?`9!4C~yd6v|9EoA)rHFlT1
zYCyxkUz?W+-FTtfe?rUCN~-P3pG8Y2znishS=zpi`x@)^ftKQ*72F{o^+uQfg!Y}~
zACyn7{AlznM^OhICfO@iS_AeK|jJo_|qVSD(y8KLA
zCNE9B`S)T}=B3?|=j_0Z)}XX5hA3muFf`cK34d>Ca{l!7mNI_te=2*%4*QpByP_|D
zn)OWG{$<;qSG(s<`KEjH(!yQ8mo4jlcSStD1Tb!QkYZC~p;Ynt2^+g91L)mqp7GfXR;oO&f}
z`=8D0G~eYVWXoTh?)je~K;!CBYp?h_UH9S-8TWtWW&6FgvHZ;2uj@M7PyPtEFWSE^
zf2}L;&85CwEx}WZ{cncpuANsIs_d4g-muv8!rh5o;a2N;DuV94GoAI;=1?WW7twoB
z6>-N@rFE0#T}96GyxioRDKXJ(4o|<=8-;C*ZrNvhp4vt(by>WzZI|q>^#bdk`b_t1
zbr)>>5$=^3ptbf$g649KO(K2f0h@Z2EhPSEw_Z;ZjNZRd{@h;nxGAo}NqbJm=U$s6
z9PDNH%PQ|D*M+P?ji>vg)UG~|KN|BxIyXLA#b(>!3OS3jfn>|ajgV*KIk|kLg)0{Gm{jzc+XMhJ!K#5MU
z*QEAUuo)1!%IzHi9K7NWEiCD9;6#=
zB<~-UYMJHb{5vG~(vr7Fh>nCa#
zznXSbTKM1O*wB?fU5lp4fBYEhyYVM$et0tLj@OGng-Y#2RS3cI>YI^@}){}`Bx&r<)tXbXu?y7|Ud#(2$
zLN@i>KEKyz`|^9WulnxwHR~VCI$^IH(sOk}T~wQ~H8>Z`o%#2l;p5s`_rH<9!c1rW
zXYlxw5iL^k?f4T>wx$1;T)DRVi74OVe@p&qG3FIi&Hqy)^XsbU>u^*1A3yA)7A>Fk
zw*QcS&QZ`<-c=rWzXd=8#`LF^&bk$_gqZ;^iTBso%Qc;zm64@
z*IZ-WVpm*vZ&CBr>A^`WqQ2y_y$s||nVfLvuh>is@zQGIR2rlC-|ab
z@I|xIZ($2X62d0AIf%yHdFUF+f7D0FDszS9$|bWbrtFep4^V>f^qE-fXfkt&+Kjf1%Yx6E
zt!UI(x?~xntHh!Psmv*#eU^13w<<0O$ZWV1=qhrOi&cb+&C@5V)^L^B)4grw%hwvs
z+nRG$D0tdTzoB&36JjyHVwP#pbb??HzcO6&APr0(K{d>~tSL{#M
zPl^}(TFbRf{`G#TSGxTtw5MG@|Gr-8mG1d>N3$cIcf`z}w$h=#Hf){$sjRs>|GrK2
zS(#HJw!a|cT!m@ejX#T)6(0=`HhR`~f1iESTbx?p&P3PzG+mHptF0_B|`P#Bg%$<(O-b>agJ7mm-$G;IV`ukQ9Q55EMB34t@|mgOIn)HmLZl%Eo|sASD-pViSfp7k$r4E?`gV0=3AkCZ0d-Im_K%*JYcgWcl-_re{lc<*zL%fBrP<
z+4b4WpgHqcPkq^f-M^PD?|*l-di}2KsdG6NbN+oA`%nJR3YYq-tnVMLY@B(0Zk7eF
z-RHHgj7u-1zBn7j{&dyES(}zWU6CsJtN+&~ZLtfW`qgyniu%>2omusl{IAWrksg>;
z=NOnJ|H}W;{ERxsz*p+u-4=*FXI=H5;rPKdUu~}bjs9oHo6dZ;?C?XrWyfaS2?LG8
z`C44tnSb}Xs(;5VYng9bzpv)~eeK?+x~xNWTkpF+FkHEldsgeJ@D)+J9u=SPa(n6R
zn>W>E!d|B=P%HV!^J$N|oG&#xu2M+#(6X8ka9p5n%BcxG7g$w}JuY+aGRR6;G(BVS
z3`?%xymFDN9bGLnmYxY(79u!np2b-ok@A%yi~-LwrOG5XJerZ1lyyOAiNlg>HQ!9X
zWlj~kIBV^}<;LbUp+5xqjHAAFipy%xTBf+TBA_$uxQC5gcAl=nroOF37hDWatnJ{5
zDbhYawbCql*|g&(|HS)}Kd&?`I)7+`(+6ng^e^<1visX$or%A?MCKQo6@RRVx>?u}QYX4IdFdK1rWH(UbWT`z&CClZ
z7xi5ID($w8s~E$|ve3kehT4bjw}Y>Qy;|gEvu5+QMbivIuDJcQb$=dkvTnvJO{*`|WPJ8DPL4vZ$ZqO>{_G2)w9m_4@N0gOuKnNCl55YOh@N?Q|F!m#hCfYP*AyS|
zp8V;mb@A_4n+xiKLv_!;U#*qu@j}=CgjTvuXm#+XuBqowy9XQ9YHlp4+j={~{FHXf
zWohxY-MO~=0^^>^|M2+qdVTGz2bZ4BSl;M8>&5{{exAX1RxfiVs1k%_@0iQRUc3sD
zmOry+UblaI%YSLf=D(L?j&1+XAor!z-??-aJ}`*h;ZqOAgdwoXo|5M9y!bltV0{6
z_wSn8)M{|gcj&iu)0
z_MhQz;0o5A2VNcjt8gvD=GwH4M^CQVP`Tboo@3s#b#v}q+xC9aMjdJ1sN4Izo~+vY
zxZ+LHYnfSxt8QKGO|mTy_~E0K=X6y#q&HCNwY#y<#9e_NS6wEY445^`tL56p8{o|C
zrO9jLcKIN<$`zRtlz&wD%d#MkyfD@K-p@izf}c7)Pq~+?KR5KH##85SJ)56jeE$1t
zmY1bKwOiD0UyIm@_f`hZis`7k=5e_{Q2XB6qiaRpM_4XB>$2kDyG$9Ei&u_53Yvd3
zT=`?A|0C0*&w8&;K6p9xZ&rHMJoDRkuAF{+r|SB=cT0H#ziK)Ey3+3=FJO4tWdDZ^
zvp1MNZ+vmr`&CHuYo0ImKO*{X`l|oY@vPsKeSZ6;_lsYZ9KOAIUw+5sGUuOHd_Rgk
z-&D8t;O5KaS9N6dj{Ghw*ZnB=c~jk1&L7Pyj2~!ys?F}X>*qXE{B`KpD9;@IT($Gg
zwNa1W8N}|oZo9tbnx4Pu;=KBcmtRKydj6;RiQUzMuBs;Gp+6)~&T2|-6E$4*x%Sn!
z$2*^flsR(;i7i>QWn;fF&n013Rcr29ZNv7Fi}3i
zqDRh(By}-(X=WON_EC!*0UaL1FeT_x<5>nh&9y;EGp=fE-zc%XE7u}al5aUzu0@b0
z|68BDDgUk<_T-(gJ<2QiT4R{w+py=~OTGSl3`@wrd)4}Jyrz7|uk9N$?^lGoa{gp3
zo>lp?wZu?^*^N*4#}G{&!6^Q$-L#+
z(YIy4s%sYQ&^9~zVclcj{HfWu5AD8ev&ZZE*{$}v)+R^nHI|1vp3%$9+_~6B5Tb`H@H_5`gmTm1AF@FI;r>a~z8xn{QTr>-l`N6TfF%v>~kmL^YG2FNmoolDP}o21R)
zTWoU6*rD~TnKLY79(6BP53pBUS10`Y*{^Hw7Sy?|;V%At`0IMDbo55;YcD8gZZ1i8sjm$`_%qwc`1h-e&Yv!v(zq8QAT{mF=KzPwr5944+G-t=(^@oZ
zLwncRDPj9Som)QPe^ctVZUqek@+tqD`s1p5;#||2KUr13|61&sR_EyY^Y6u9A?(3T
z*XkcXxE7lA+WzCmNXhkX^ACC7*`IVH>+1ba*K}tmz7DWI9rHDOPd;zY-GC=y+F#f9
z`uy42^=#LR8g<*)6SEeXDob@-kFvZGBsV1>bCT0n&Xw~Pnyx9ce7b{+SEOyGa+YJ@
zWl&4_rO)#HUa6)VjqYe_`l=d&&S_y1>e7U)XW@!+^mgEMWt-I44eGM6GFY4JTz2V7
zPg!QM&(a0S5tob4YD=XCDu4Ft`S-PMt6b(q`TOd>4^6(Y<6YmaJO3WqO?8g3|EM=<
zU9|ii{YxuexBpXpA7?AyE4MYian9E8+3!R9uEyo>k2_Ot(=}W0QqaXH3Em~k1AW*o
z1#k51Vlfw)vHa0w$W({MQA3`iYMMWm90lzOp4;UEn+Q2#ERr-AJUybOd1Fz7P@{Jj
z!vgkTxh2bNz3yC!77RXWHb?7BtH?tS%|lC)S1z0HlO=GI^R=f}CTk@7#zXg2gZ5@^
z=KQHO^>z4Z$LizPydSDv{`X<+kN#8I^DduP+Mb+0AuzgFqO;(>=Bf$u_pW?rZw^hc
z-@Bsi@Wczz=BKpM^QW!44Wje3e9;
z&P&s*KJL{1MC4UUkY?beCHJ;oF7EM)GS}ZKJ#FpU+or_IoU+aDCZp6(Es
zU-5r;YeR1Txw@^}R~p>7+L~2#^=W9;yjI&@7kk~%J@%TbIqCvK^Z8F@&z!v&nmNLv
zef>bW#IdTrESt;t-_#%1uD<+x
zbB#*=m-WZiN%OpX(|B_pIsgu55c7JI3y2iyf
zaI$|^;<_othMN9fj*iPbg|DbBt7^Hn(O}v`kBkMERdQ{Dt&#HyXvQSyLgpm1t|%`S
zRgo=R3_fYo6HS%$vQqoIrfW+b6W7i$5mj0%@p7%KUgEAYt%;sp8=qe4D9ZdScq;5D
zL+D~&(?v&R4nIv{2yPO-wdVHipPO30uDk90;f`KcoWb!cU8k0294>n7dpfx3)9ecu
zpPGO7t+tVq*mnEh%6hHne%@#n`(5#;HvGEuCVbOp8{Y}Pg3YAff4$45F?FT@Pj$Gq
z>I#;Rv4U%sw7!X)yyf!4;OFYs)@|LtRq%k#)n8Ywx(-VDnv|5?e--{Rq;&sJ_PrU0
zc64U-ZP>Y~>eI`bj4!Kdc%Ei)*8Pq9^on!w&(}A4w%V+kSf&-&HUIRopQSa&Y}Ry(
z%vk9a>~Yk3($$U^N3BJYX0#=N7Y>86p{pV9Q8mpQOBS#kRTO#Ul_V@OV|h?ggRn^3
zTu+C#M_o~x4O6(H3>}UK%Y;mo{<1Q9x^BlyS5=G9ncRL+UZE=`ekCry%1Q}8oXsevwKP`vt7-~R<1qNIjtt}KLe-e{y$$tPwo7BbJgtEr9nPV
zN-kLkK9Vl}&!Eey|3^jaKf~t>;iCI`zx;gSuVwB3!z1@U!}A4;{|RZ=|9lw}_saa@
zdBsnQH`^&T|Emi2?@0L1FmLMd{3Un2=Q*D0JN!>b!+yWxM;ZD1>+DNSw#s~x*RneK
z$C)#@eGRX3$Zt2N?`ytQwa!|)?YopGZ?cctlv#-;ZF*TAX@(vWWh;u^G8f9~_U-6k
zdv-ME_#+FZ$7j}YNX;`}{d}TL$9wjU1@_1NrT(b@c-`r#b;#4*rg^Gt!}X+pUoEl=
z=RaB(7`HTh@jS;9eRHx6|1(t0F-@_3Jv(gW)R)zs{1au_zpeUp=|4l3{@R4qA&o1(
zP2zLO{m+oO@_mr$t4#&jg1!-VTUVA!{1ljeInV7^SnSGYYww!B>%X+(*1YU#IWL$=w;
zR&CS$#5L{X{*r9-9WrT~|LxisaqZmZe;fX0i}vwWmFyFi%(D}2Uw!IMSV{VG(E@Xk
zRl2?_Z8`F#pRC!oR(kQ2HP=k{>bD%)e#CHMrGIB#cDL}y#Tl8*%i0vTgp_Bnq^)(?5f~8Le|Oe_^D7VhnC8%N_0TD|$Fb|X
z*gWOF9`_Vi+m*SOH|WB$E1mx~)MkbCO;rB-;McY9VXQm13;w;a%4++c%B^vo1x+hn
z{b%_2?CWvw$L_BFtusVfX50-9F{*v_HF@Xr^NB6N9!pIwhozWw^|pFswyl&r(GRLj
zV?ytoJ8X7w+mfRiBJ1K6#ZF~Ptd7o-WYY)|S(qf{73>+}+BB(4v$bi`v@XsKGnRl?
zDVzeYN;nnh-DT*&x8nX%@4%Bm+x4OaE+19XJPSUzZ`aAbID}Y
zTo5W$m2~n`sCV1xpf&q-!>4|_`rwe=$FIS4FBhlW)lQUux<=dln0BDb&uppFfzC;u
z_n)r1u>ZYgTAkLGpt?_8g%{LH%+7!6ntA`}n%|jrfx%nm>n5tMSmSK{IogaTO7!^B
z;_E`CYxk-ZB*ayR`-rvcCWoI&i(325{i|rMs>HI&!)n{Q+(l+9{8pK_sDG2^E3M1?g)#B<PT7R#YW0~KIij_ACL#M^hC|Nnn
zaof@xOKt{z-6$MtowjoQlE1f$L*CBYnO1V-y4%mJwU2As=JkKN8om7|Z}C?%kF#O_
z89dfn%zm;a;XlJm(WSzFnpQcxn6C|8kUwjF#n&kDXRROlS1yoR>b|P+l}pvhsR_IC
zCtQ=3|1$sB)^+huOgoi9TOh79yvT`vBC31&->VfjJwJ8Ldgg!kn*Sr&zUXlKJ!{fU
z*RI+YxAD&BxTW$f&*wc_`E%8YtY!SB7CBrym0oVt<3AbsChN)DPqUU>U23{;YWj-9
zJ|>TSOgCBH2*_k*o2il?FmJ2z74@~5!kVliQ=}FfYCf9jCo<#0THocS<{}qt4^5gb
zlGMoQs;6<3L1fWnkq4SQldLvu<>H#_ny$QP#YA`MT4VFBOMF2nZ%qBdy_qiiRRgb1H_QLBF3bPE+f_TU
z;))fi@}^NY1HAUzR&BiVVBXQ1AiC!787&j+GfoU5msXU7k|x
zq4~mcW!g#p&%o#3;O)$uXR_M6XNlo!8}S)mUE@9@9oNcfnied(>5hcXI>j&Tp07IZQ05f
zI-kQeyrn^lD}E2v(`!U&i$Lk`zJI!$0MWh
zv`MevYR|v-uTB3Q_SHrv`?oy#_x`o_-{p$`fh_5
z?6=7LXW)Mw;(Y1-0`B|y_3!>|nV(nhe{JRa#kCAEzf0!LUn`$m?|*F-`{GiD=-=7D
z>bA_!t@m2JZ*na|)bHe9bz7vj+pgO7$~=JOKSO4|m;V;Sw*h%e?>Y!~-nO-ms+hai
zK5Fg0DYlB!!=AQ!ZPyK9zS6DAkg0n)WOd2a8Jn)G)>XW5DSFw;X)jmnrmYN%a^ARN
zy6?oJk-t5)BVL=I(YinLXu8^|F0ofJ$FjBvebUrh^7rDZ38%YGdA+!&cI)h?tJyQ_
zoC7$2ybg%*pK98!x9n-6`unpP$MsJ~%u9b?94?fjA9bmaV^ZwNqhW3Svlj21uDsS!
zWY6WE+KXRJUFL*zs|E;t^b@+Kr`Gaa=+D${o%#D#Z$AC$n#-lSPumv@rR3c_+bU}E
zIo0Z#>y{f#%V*V3S`_fTD_SyYa$a&|Z+PDQVyPwB7nZFRp0xN%epN-DmX)?!XU`fT
z^V6YG%ZdYL?Re2Kd$+`u!+s`*qa+PA7Ih^_eC1pjx6riEa6+J~s0*jR$f<%QCRS6p
z@-lcmR!?H|-V)3ld^qUJT2@XkDO0_hnv36(vTiYkB{>uxO?h^4QBzt~q;Rm>tYh199|r$1U7er0U&8rkxXnjh
zsbejE5t%~f&cTig&hHV;zqGr;WY6O#_ER$*mpqnNe;HvD^NatcqePYOlnX2F7{|J9
z`x-cP<%7#*{~7pShA-Z%Pp7w*4|ZMi4?Ddf%Fqs38Y7az@6NW8UZ
z+Gf{to=2W?topPrYOScLw43Mp$c%HE){7QKIc?28xx`?;*Y263Tvu|oRvf6+>}CA2
zY{o1Nk;SPoX3sCpO0=6AbL7+1ZI>@3Tv?`{m3Jm+XSUuU;l-^KM%v=hCBkw-{Qw0Z)#~e|-F1A~
zOq<-U4VywuO*OL41@2svo>W#P@;Tt$a%Qi?MLWwZ4TCH9l&;dcv6A^(p4zHqEoXkN
zF5_=Fd~fsSS=&=?BzvyqS@P~|!PTgkpIepYbmh#ikUD2Q(YE8~a-K_F0j!Z744H>b
z76i8{b{KnU9^i@zV%&4-vlnRL<*!Q*E^p8*bl`cuRp#GvIlPMfESC?iIJlf`3CpQtOM|i)vRt#A)!lx!#@s&|;P$gM;{MTe
zWslCX{|q}#T~&_ym;GnhwdU`YMeDlv&MZIweMRbQr3Ih0%xf+^xpH|nI$-?4j*GQR9
zwdi
zSKjn>3*4*iG1DVeSG{@fl;
zTt(03tqfY?@@-{KN*1rzf@|w$FNn+XW8I_D_ogbmc+nq=;H~dHC;Vq9DbQ9|-B_MJ
z*D=@RjhM#G^NV_}J?(EPjoyo>x>({Dtevst#swY?`BrVu_AMKq
ze6#0E&yk+FpH=k2tqQJl0_K{+Ns~wZ+kC1b?{+zM8j>a{zL1Q
zb#s+C*mK>sW?yP@QsTY)#zwt0_k(pZS6FE*?^f8$8fWZg-IX}cKG1nN!?#J=YxilD
zG|lTCPbSdPKeZ~o~J5|B|&g`3-tPt$owLe{`@+RZ9crWLyc~do~x>qIch>wby
z$d~4pD|~5jw#A8;L9?gGzU(cTx2P|of0nD|mLE52Z=Kq6A$K{8r_ctw)zQ7B^50vX
zJ}-QyWvLWy(`T2@@^Vu8Um=6qX)F8Neid(f)cb|ydPSq`j-zp1tOu4YQa7voQ_p9z
z@jrv!&tDr?bAI^G;O%&Hk^G9Y<@dbwvz)p^-yD4_d6=I$v-w}lqyG&1SgrpFtTidw
z(*5s;=q-V%k~iIz_{s{GAB-yh^UL)=Lk(B!AO7WX+Y0ONGwn_~8Ms+hro-~)!IKYS
zP5v{So)iE5#H!*S!hQ;mt{Hxb`l6olRaERsU3E~Vg74a{
z{}!?G*mv$UeQ9pw)>YW`bZhsC#IVd5jdfa+Ctoz)){|2d{PMAS&(+{1tGA!Mv`zHv
z={&Ab+h4Q79mJV-&JCM8@rB0yV)-|LPWyNF@YjS0xkrinO>ExLwN^&x&h}GF!|%n<7N5Wd8Uj=LsN0!
z_3+|lM~bJ4PAp!gG6rRo?a7yK?+x@E%p$SK@0Yo>jT_1a#QvqZKCt
zy)+q?GkPR-1$t;YEJ%7ZT_n(hw{&ILqNu6aQ|EQbX&$)DY7^2^vAiomRH{GrJ5j7;mq*?{idQ0sH&KwZPN^;~2v@|`Jj$pv4NSqr3mO=blL&PptlxNPi|*>aWj=v~i!
zvwTfvmB|~dxhiO~$4wjZ%g)`?V-PJt8dg*X3uoiBY`_locI~($H-FtJ|=AOqS}eK>zi#{%;wau
zKk?`2{;w;yZsY#w9XFxDXI72w0W8rP?c=4V*b$-
zt(dd1n~q$*72PC#aC%MojvaI4|CHwjOb*)+e7<#U@ZaC7_rEk)DST|7T1%qo?nUh1
zXPAFxoBmJuywJAtte*St9VP!W+|1gUwo89+zx&lG^TRjT+E^#pzkT-kKSTf3;x#v$
zk98*P|MtD|Kg03Yu78Rj@ju$ry8qthmj4WIwn~27x2@`Q%Ki758|42^T3h^|LI0o6
ze})rn(?8eAfAG0!8qNOumfD>9dpma9pL?_*`>xHLUU@%x&vpBM{LR|lYg&B$x6OZs
zJ7)a3@df
zuk5$HTz%Q&a{u2gyZ%kSw)11%qQ(Dgw={pfq}%`Rq|bkbmcs%68Rq9I)S7hX|5I8&
zYkB_he~hy|OaJgpE>67uTkgPrh6C^Ie=1FWJFDRJf|twhoUZ(vryc)K*f+H9O;p0K
zOtZ!R88T;8{rJytg!{YNX2*Z$=H}T?Nm@N?{ipv7Pws!<*i!wE&HUT6S$k{jmu~;N
zCyxJVVbIYPH#XP3KQycOub%$?rAM>t4;}ny{~;^M{@3$tj(?th{~1~vA3cA){x0Lc
z6QTc{=9~JReqaAYzqIs^{eub4T3-8if3RIGcT_$w|L+dds{0;$cK>Gxe=vJW{Ch{y
zfAt@q6$bQ6{#X>){*i4-@yn9OKLw+#Z1;EB1Xt+3-74#q^Y_`LcTTI{6=lUN+3x*5
zak*3Ud5+n!w#)PRel&?O%>uFc62Yf9q
z4ga<_tvstOz2f(DgT!r_GFqA{Ul>Z)y+3TnJn8AQT1St#MfM-p%|A4crSFjHtd}m+
z*(Vi#ubX=B)(ssm28rcsX3n1E<~Dc1;cTf@ZmZZ6w6nBbdrFQ*-rBe}c*m|!2Uk4}
zbo29_JhwwjQtzVmb^8_BNiu(~p1xnPQ(67{{I$+2Z!8r%_bt{}{Ku-6UzhaivOY)8
zm(o0^@;6)W@zL9x+gCoDd}CcmRqXMOiS~V)@@%43&Y%Bvz45M(+WQKgZCZBq$>bls
zrksW^`hzAPTV>z3SkC0m4gNU4>+9+}{*}D0-fqreF2DD6=$pCQSuTDNYhSVTjMvj$
z*F8mUMm_wab#qhy%h(oo?uekt8ER`z^V?Zpjm$goKJdIAEEY5pFZo#B;hvG
z>AFw)DwCtMeBWs=z7&64MNV#_P2RZ!`Rfggw^d!etFz_$MfW-HvhpT*J@$Kdd|yS?
z*LM#hWBxvz^-5`S*V7tn@u{g2-_}jD6Wh4x?mC}qOU|2VZJBN%n`OE5fa%P_;-1gZ
zmO>MYyx)|sn)IsTpVqP6SInNzI=J^*Q~I+tb8cp-N2+ZR|FLSxJtdca_Sg1&`h3Ji
zcoT#+@AAcmDS{!wM)XI<{sF+UuDiy;Z0p_$F9}p
z2bgb<{B-cA$aP;CZXpKtOUu?=sXg)j%B$t9qGe7STVnXM&Hgh4c<@h`KdbnF(QW7I
zr9E{q=|ZC@ynejFE4YNFr!uZ|4lJ`)Gz;7`ch~fSMQ?PnboA<5u5|OvzmtDzS9GnZw4~_z
z+{G?8POM`Oc(?O#N6LSOdAUD>Tm0`ze_HR^?A!qAAx0Uz5PQC=|J34Jb_dV&YY1-m
zC;T(`YVGP9$sgWs{Kxn+wB^IymH!#0W&aF3uXp%)=VQmrhuOEp51X~G@%+zF(^daR
zX`Ajf5&I8gw-Z6aW3d%4gFPzD=}Q
z$S(4YWxdx|wh!y3*gw6b|NBXZ(2sPl!2b+#8~=sMoGp>JN}t7g)JC`TS6g=?*JK&4
z{a#PsO-!23dHK>xzegJdM81j~$b4{F;De^qC9Z;%5=p&Vwxl%(izIb9WiTujnYrYy
zkJF>Bw2ZqB{O6a7%Kh^Fa$wq|#rNG_F-+^~uGRa+Fx@0=(OvId4XSKYq`FHrs+`r>
zXH6~*3tMR(;wdipY5VDbXH##@oF(Wa?5j3qR;I~;%w?t)mwf|xOb+{-91c-jHY4-d
zjLe41zRRT&S23tfHklGE@E~K#BXRZL%YOzJ`_B2#u-Nn8%YUKXMRCWI9|>-MiB!U
zQgf-vxi8O54%KD7Fy1LMH_NJ~eO79aaem;kNpmu{95Gy_9Bk^^wIx;2a2C_$hUJVt
z4V*zsDs43bwO4)UZ+&`QKfGun)BG8~eusE@X}!senSZd3YsW{?SJT<76YA2A$0x>p
zUYfDZPWIA~u#0Ol7OON~`8BKGHDMM38q6Ek)gQCd>pFKWyJAjdb5GiiC3o&E
zebE(Xay4nsrKL@hj1$wgCoTB$pTVQ2KI;01u>O3#`MMu_B<0>cEOK|)w5jnY*C$<}
zPqAUYL+0L?V>{zN!^tV@vwqZTkJuODvt9MgNgTR`~t`D>fgKRVgf)nD6G
zoU>Kv+}`R>`%RxooxRhPcI&y^%ypAPuU-qaH-8-yx6okX`Kn8kt_MszYPPeeGWq9a
zn`gFXUC#R6jh$ws{+aW=AAjiK;O3wW!s08}oXkGa{@eNIRmaJfwwibc>n#_n(md;O
zD==rptMmCERvev^d~4T*A6`%X*d0^|d>j2KhEYE1b7oGiZKUYiV;3sdr3YUzV?G;s
zRsYcQSr50)4VP|vwKsahHifHS^Y<`^tCv^)BtbVm!4_QT=rydtq`IKqw
z>1G_o;dAYI%R}SW7kW~dXPs_3^ytaIS4QsZv@g`KKAgGsUGLRH4<;U1SM^nC!S!Gd
z*L%-bW*WY2b>Et`JJ)Mz+CmYoY0qL;U)#8Btx)P}t=RKDpCiP-?{<8)CQH1!_-x^=
zeJe!F&wB2jGEr{j>fF0+>)ie`gr+AkheS}b_U>5pE!92TGFeP3
z4v6}P@9+29RJp{a@l$_r)Me2=qca5z>-9dWZ7a3)SmOTOaE|`YuglvPzg1m#)Gzfe
z*QMCvXk-6r3{U%PPaX-q@x8>=%7;?PCJhtV!RtMn~%k
z8rO7BDKTgbJZknRw9ClzW$eiC&()nTT^lQzaz|jE
zajeL-O|NG)d#cs6+EiaVVpZiR!Lj4Omv#Rca#pxcvz{nb^X}7)=Wk0Y-Y)(bkbYfM
zXF{v!%4(gki{ew88ehlQZG2RF=HjiAe_us1udaI+>a}6XR{eYDc^uvs*h?MUbwyF-
zZO%2F??LB|E-5;qu+Wc<*-B$0ob1n_I6XJ$^3wOk10;
zr`~E}UW%-2`{S5(P3F&SyRL_|{AZB(^E&K)NO%97@OIU|hyLE2Q-7e>Z`R&dCA%j7
z`?cbmF8@rqpL~l2|0#wi@9X)`Ah3RZ@DZy?wYPWLTWy%9ef9FYyW1bJ>ZdAP_{FK8
z{O`j`*C+M&L?0AZT#k78ZT_E<&?O(^)~ZKulXuXPQRxcw`L4FFr(R%1d{9gMY1com
zkM7^D|K#`gN&k4elH*RR|2mnHzgjrbde$oMoo|e@#WptYOOX$b43AUY7}IDa{H8cA
zZPT+Q;pe^1E;}2l(ljiu3SN@;R
z_RqDci2Kj*yZh&r-yVHup4Y7M*W2azF#7W!?w^j5>&
z^)Kenbysg$Kef2kq}roh^URcGqHDd^8a=x3D5LB5w^cqfRtNbfnp}+N%9LG|79Z8|
zG0fw#r&p$ChgX!BX2X^p3xXRKus!Mt{&pd3!m*%>U4{-vMgCk#nj3V=Y2&g>mjWU#
zdt_d@?AnmIY*wvFR~eJBuhJ5w$)Zk5O0y0vyX~Xt!yz>zD=eyW$0{d@Ok+orJC~hg
zXLLj+|1(VLtepRg;kNL9h8owHCYhJ&e?Q0OcijJ{
z$NKRrS@Tlqiq9e2jH|mc
zHPj}}Xvyl|>v84WSC4Z}jX{f^%~-U?Wv5b;udKM&yXQyY!~05i^OpJF^K3rx!a97FLWJ(8iUaE`?K8E%xc<>P${QW%Yj?~&i6K;d
z*3a`XSD)>_x^8)zYD&$D^LbNW{AUohaY){poiY2_Xe6SGQ_sODE1;ry6nn
z#^kPD*>4R?tm|1bf}(ziy^h?$>iTYBrii6{Wza*TdYk@3d&M7qJt4(+-#ySDc-yc21jzs@at#)ohFOzv|z_1wtJQLpjG*PflV&bM4+wZyj5XIGp!%-S1X*?qO<;;eNctz{Ood@iNUo|PoW
zYwMRKkQK6kJ7B%i_AfyjW7tg3AN!qkB|J^-glVhCPHm~9H@@*o2f6mvWnJBQRmAyl
z_>>#jts*s77wUI#yVYeq40$S^9CrE2a+TVQ}W@Efa
z>yf);esElKa@HyarX5+=az7opXSiv%MnpxK#FU!m{;ZcdZzoAy(Ku$SxqFhxifexv
zlx?+DMOtpBtvVsk#vcB*Y}waz+P-KQ73$yclAa!6sAV$bf@z)60rnVJ!o46nTW
zBf9kO>VVHPYBqlPb$z8Xn@C~AJfTZ=N0%Mr`g6u8du<=jI_>96?Xv^Vd`Zo4bvb8t
z`*xuW-;{od(6ydQT-tL!s;!lqny9kI?M?%A`+0lTYr?^K(*-FVKNYx|pX?JllfE%-hA(xea#Yf;v-Ce`xox-Djf
z4VDMiO|1)EvsX`d!um_=V|;{+&u4vlp?5`zEtq>1mHe+aFq#pZdK0VXWxhTfX1T7V<4m<;v~RcpLd^iEr7VyB6&4|(eA^MqAC9iNmvY4+1_=c>(0)*{<`bg~;*1Fz~QUVeKkas~ryPL}ZT%)C#h96}}6
z%YL-)P`UE%W@tyJKl8QS20PND!mB02*1x$vGd%A4vn$IJB-S{5(4L=m*7jVMalEU<
ziq*=;=FFLUGW6vnbUXv+r0=vou8XheTTd~nE*t1Dzb@1U3jjX`PDHc*?uktht
zJ(AunE>+VsbP!IP!)wA-AgbEO>m@adRYRoBzEtm3o@OS`M0wt@N3%s;xHgKqOw!Z6
zbIH4FrmEV?W9*`-l5X0w!mJkEEK*ayw%%#Uqs@<|@O`b~ZhbuK`P8$ElP}dMFH^p?
zI9JkU*88_5PdM!2FYS2Gbcb_I@a?WI**Uo)3t29n4Dx&G|K`cR7mI(}+V753>^mHPI{1CnDrOy8MljByL;0>R4H>OBiGH}~Qliu(v
zAEZ}%<}T4R$?35c43*5jZJN&)l_fZJmV$rso$&eDcHBEQ>wIfJ>;G=vqNTpaJ!dUj
zy7Bn-y#}-9Rm>CDRGON2MKH8;?X@Kvi@j&1Wt=q>;+mKxka_CH0^YOY4*Ra>{X4tt
z@N@6pBPk5*E7g}~y^7=bckIBmuXnYMew-}r@$U84(BPQAeY@)yM%{lUmGV|(+qKu~
zr;f16m3W0bmSizpD}BGy?AO`3TioUif5
zO8>lkymODT;@^MWk39DJxM@24aWI)xyI*L_`yT@T8FGGz)UR$nV)UQkz(V;G!EJjV
z9Qm
z>!ut2XSkWM`OWcn-x(jtbN^?!u)41P?T`Nqz49L>{s{iDN3;GvL*v_jCYSCp{<9al
z*Ppo5_phsY`Qh`wBu(AE#p?P0Q=6}|+hC9NCODtzEw60>WFKzUnU&>&yacP@A8MczU=+TGT%GM{@YZ$$g-qo{Y9Zy{&4+g
zsP@19=$E(T%EhxE{yF|^=k-PO1@>u&(_v-pzZ*%8AjjGB&{GWlZqA6Ic{jtP4)xgOT+fLU-
zA75Iie$eG~V;+_v~>{R?ILrH-|a{rSB4f0?)B{&@NPRk_gPFQSEU;lEGj
zeyN|h_0f6Om>&sZ(|(%XfmbcQrZfM2br7ae<}aZQ1YKai*ecMe@pkZ&D43d
z$L;>d0)5B-3=2fp|LbhpsZf7`|M#<9^95!8IPI1H%DnYI!$pB`wdH>~_upHz{G?;OE?u*ynOGoDq7$>v!~;NU=?2Dy*8JtFT0$mx^}<4r8+;P-ySZTo?v%s|D$8u=I><83;p=>mznP?av?lzLvLg_46{Roz}0PP3C@;$?_KI(&8
z@3&~t^7y$wE!Ue%M^Bosb$9L+#r4K7N^jM!a0y^{j9M*r^x3p)yem&E_j@Ste8D=a
zfGwVL)}1-)_E2~2Jx@Lc(MNT<*Jp?9OIZ7RiACV7*L!Lo`SH%({i*IF+n!C2e9vU>
z>$R=y?%K4ITV~c5{`Rt&$(pjS&riuKuzh{qhBxy`<_nJ}*D71q`nvDjsyo}3={Bdp
zn!8zl9CP0IS*%tom{_`w|Jba3Cwx5aY!^N2W?p8v_2%){R?YFRc#5a8cfI;!EIvJD
z-rBPT6M8>uyz{LpZ_h2}Dm);PoSL$z+)?A;>}wyBY>!O}67@7qZ3sPDRA+E~y3gf1
z+I1h>#5OPXJ$qAT^Q@>j_5FL?pPk5AJO8PCMRQ!ScAnbWdv|O;+w>JhJejrV*uH5~
zL@ib{zmZW${v7RYM`g)!dj
z(xd63<`Pqa9!(cvn7#7gE1e6x+G4)@rq?>pin+Am&bpHxPs
zWcJFp_XKu&Bs%Qj`XcS?=+)<1^L}~7)i+ag%I?~~T>hUSYTLsfa|;?6v;Q+pwEuPW
z=;Syo&z}?*AE%|7ZAhRpH0t;#>FsGsypEcpdor
z+>vV4JKy=YEnh32>mT(|{zsI!`@h)Zf4}}`xVHG8SnkdL4AYqZ{aW7k{5S_-19)nuipMoR*V^6M|NZ>W@cL@xKBd>fPh*a-Z<_ycsXr~f
z=3ka}^ew@!YV$Tv`lNB#P~zD-m7T961Gh%IuT|;jHW3T53f}Yhb;#A1zgKHZsYQM6
zRh;qbYVDQ0rAh02((4c!U3(Yqikv%!j=y&P*!`ER`1JPZhX(cVer3`ybG`G@LW9U?InrE^fImm
z)%_@~n)-qj{~37JdfuDzb;)_tmCACn{iUH&Y+4FW^R9bxH
zedM?3I?-owHhcdb*05cDG4Fov`iF7$k5|u`Cb=T&q)_FV^)vmi?M?RG_wVQr%V(Om
z-u2z@Haz~a>ywzh{o}aSN4w{5uCdv$iCuasqr3xec4YiCMY%Q4{z!Shy0zu_zsO8;
z-T6N_g{~0EBJ(j=I{hz^gZAg9p
zr~eF!{~1oNpE-F}K<1XTT|Mm2CS2m;RgiXNo75mMD=$;xvg0a2tyu*o2mRP4fX;Eb
z1Ufm?a~7LkR)*X6<9T1>P17#?xias-cJq=SKSi%ZJPfJgdT#Rh(zZ(vluFlIt-ZbR
zrmWzm?~6=ccOAM?>bJl&eE0rC^Rn4qz1Us4YN_{1p$Xf|)7)&X3VGUG5<7WvL3rw#
zc5aHg@uEg|soCOHZiZ8wC&xWs
z62Y-BfSn;+{(&#^n{6xJ?YA!S)4rtC<0>Kg;N;(=?dC3}XMbB1DMoY5n|i8Zd#tay
zf00DKGSjxN-e0zEFE2a5w8#DEtk18ezis<_Yo7KlL&N2KX^C0k{iOw;PTbTfo^@)%
zvo&5{L;HNo4odrMUUn#bZ*SG-xbq8-=&o5D?-&>V(AwWRAWXR-`>KMq67#J+Jvlp9
zYkV{B+G-zE{re#AZlUV%DX+J`tzKbyF4T{;Oiuku&1^S@Pj|xSZM^g3yV@=dw~IR#
zOK-Y2U2xhrQ(4bPd)qy>{x}pKN#aTWXo22IMnz7|gShDP{p38-98jMr6+`06u+3`wH+H@0!E#P}u
zmWoW-!UH;x+fSs;W7(3h6^+ZAgHE}&X3dNj4UAgC8<_MiMkx5mRv%jnTi^Dg7t`iG
z4^{ZG$SX|t^t}ANa`}5hK5Kl|cq)53F4yE#*1lg(Un2DUQkF?-34Li@c_Um!-#6^%
zDx)ikKUdzEcDCE>(fahRb6ae<_RcyKJ*Csw6SOhY;rO%ZrN$;{4SJC>e>c|eO)Rnh
z#616HWR?AU8_`wz-&5TF+W)$`d|A!)b^Gsa-5Gz5lQs26^7na?S1T%Ym_iTx=-qNjE6OL#xlEfSER#3(MvldJq
z%qv$M&8f&b{M$XINhj4gVVvb7?Q1*cZmKw2y!CwW^aTsn$|WnkE1Qy+eA4tnjpb$5@11hxu_v`VMUH<|tKRh9n?FOs&ees{S{q)w$!PHpm;kDj*mHK0a#
z$SmL3GxJo!zE<*olE2g(%$lLRC|+1#ma(UYZzR*RNq))s3m470vvQg8!mGE>etgpY
z`=0#f{|pzyzMfnDr)vN2W7|t5C)VU~%kN!qbH($OpK|{*{Q7eBL)qTHGbWoh^jW$+
zHHvYW$v*Fm;g2h!Q$qee&uwbTn|txhoF9?sYVK2S&s=jUV{J(31^c(VwuZR6-IOzVLA#d^ROaD^8PkN|#Tvt9Y?&E_k
zH<#RAzexYndLuc`d1jKaDSu7E?0<*t<#xWNbm?t!+hf0LCtaD#zXh)=urPYy7yb(G{P8H}%z^M_S#>5CS(m9*zfN-hvwg!<_fMwJsy@Gv+R_tz)T(r+
z?eeA<^%}lb;YG%iJhKWsb}tM3`?%}%p2Cu~>Df&4M2r8d{8irgX8qIfZ6Eiyv2j?;
zdKJMxiqe|Gqfw)TO5ZUAC3M
z?O3DZ0+lyJ+lMS)}AbF
zeH|(G>7l!cx4mrk8fRl*t&YK
zn!4J2&=xy4V=bF$={)ue^8>GlmB&x?KYhIF`Ig_Drrb}qcL+s%s%5R--%=uSIVYLX
zpg{Zlv9K(=Q`Y-WyjU{n`+etymvydPyBosSwC0YFa?hj+ku`@*zN}L}7N-_1oz|uH
z_c2dlWYDrjYkI!U>5-SMm|bZ$?fv!lf^oSfGcC_X?AcZMG*jlu#*=G)O6^V*UaQKQ
zWGS^sW}8OY$}hi*3(Gp#gQK@CmfkGi6=vPf9$6Vsxuo=EY{{fI9e=g8eOjV!De)O-
z*~a~F%sOtn`atiiko=uDbxkbi3*MLR-qi46Yp>9|0?o7uXN`?ZlcVOzZ7{#JCh+mo
zb5VP>CWWlLzcJ+E3p>Hfbw`&f8yw!RwmmOZ;J}&V3_KU}CAvfd4={_K`*Aw>x7d`2
zezHGApFPandFuVjvr*;cHqVdVT6x7Zk|Sr44A;{X)2f%)5j;zQ<
zx~g`Idai7padgq7E{1lC#ifc%mYE%I_G4Qt^3k(bh%3-nJe#>RmtHfM;`OIji3F-nEF=ORAeu@0EE-6#p}HHT!?x)l-+FHUIF}GrwBu
zHZcBY=noD3&rn{s|B1-{zP?PWD_sRw&g4$%cXGA1`4}t9bMI-Z$%iaelMh)AlTCIm
zOPg-0%6C@RY)XLPgX@(a&Ry_aaoU>aEd$qs)~e};J<2jKdH;Q8YIGy$#?HsxXD3c&
z-&(2qXZF+N_i>GnPtU)%fqie~k+;+BqfRy5bM(TN5400x)qx4&)PCrT#c2yNQDQ?ofaLE$&E*9s&pwR4_C2)zpW4pzqE8=h&~2WQ
zeEEuQ!m-7d_Pk&D@Rj?_gLU@L${)q7xLR^$_U-LIt90~2%
zr|`?@W>T&ror7>W&?E|Lu!w{&6-@
zXFva+{oVf=jHW#Kclr0kmluEhX9#|EPvDyU2igA&KW6RBfBZLM;?p1IG5OzfxC(~bY(pZK5s_uf@ieB8G$
z_n3{~`sWMSnD(EoSXUhOv21tI+UGxvK8A0fuk@cGbjh~O?Qg>lCdZ|H`OlE@pP{vI
zo>u68hL*1P3h5R9oOXWr^76{sQ`5cQ>;LnVJf$bN|Ld;_uf)s6jqOUTGh|AI;tuVw
z?-ZR}n4CUQZE5AQ+mrujM1{xaPxbhlZC1)_sD33h*R#-?=Rbqw`jv~_JXMzF`~T3L
z7aKKk_n!RM{}~vS{(OAlpI5Vb_UoC^TKjiKO#iHN{ENuh1g%$>Sza(D+rQIIJ9ucB
zwf&d1yb;M^bE?(MRmsRmHW@2EUK5WSNE?`cW~yh+0gOM$
z?urTC=;^~MvSrF5(8WKximfJHr4q}S%`QKdFnOSPsJpdW@MP83V^QwqF!szQ58{b@GcWdsivr7M7^0~|U7F}Jj()HwA&=rhV
z{@8!mKUreePXD<(pOk!CAJ`eDae!HLeq!FV3tAcnn5O;utDAfCZUaO3WM8kM;%RSo
z?tZaNtD-%+-*0nyn&ffON4t)#R9jr}X{Ue=oTs~Xs{8V&XU9Ue
zRE7t=aF0t)t~>F1^7Z#Un|^v#ypN7*z0r2J({^>wykL_v&v&lNF}1EfbItFKt7O&}
zd8W+UiP_6#wsU`3$9GLx=S26_KGtfs?hKtTHx@BV1V$#ORtLxW>YrwI?Ql`sv;Ekw
z{##p_h32d&ePMO>#g@xYC(KE#STDbS>hifylBXq4jJr>-@l@>Q#N6ec#;mS7o-bI-s?-mk-hE+x!7>%wjc2RO
zTmP`z=
zt|+%15g~P=H!2ycgQEUHMbEZLiOpfv(=7CQn6PxQ$c`leTNX{4)*#lUnaQJ>shJ_M
zW#^Jb6ON}%H@OwXP^w{aE6Tw_-Ye#EW`@MhrOPf|Vp!Cr!LYRdeNfQydkcInZ?)BW
zVd`|_gVqhxp6$9qZOijkG%h{s+U5zmq0%jb+1VyVw6)Or4*`>VIz)ga6t1mA$mt{qp+nO$L9n
z?7o&q_Mg6#}^q3E-200
zQ2t}u{p)Wo@c(JqdhUdM#p65IU02HgSowDU>s#`FMYQKn|6BZ@VNd7%6>tCT
z(*OPblat2Fp!IkEWSPFuirSW%%QyX~{410D8T%JqpZyEgaQwP1
ztKaZ-&JhF`|{^H-z2j5Eas`(YSlmc
z&+icB_w!e-=Dz;%KLgkEiMzt|GqZc$ZvWe@|F1D`TYH#>O
z^zAIR>0+}}Cb}(12seLlp1;@XjJL*_^C#`5-dx>rZ4cK~+r7SK?u(|Y#P3oqm~1
zL3Q}-FukSDo6LH0oY%ztT>o_Cr~AOT{mTC=!C_qcV4XUI{db3lc8k9
zPt#Z0pB9LotWY|Ba)YtKVUOb2kn@|A{1fAB=5JYZ|HP{G3s3yG^!s~u&hqy~*)21R
zqi@|kxciDq&69Md%}JXlJ$tCs>1`~-pnbh}p>Xf&&V?_6v%a4e@$xvYerfOV!*b%y
zo?Aj)SWo<%EgF3=PAt~wsN`j%4JR$uy}NfqLnbWHZ_Cbk$5lO7yy#He#>FmbKfN)`
zj6sv@dQtDhlhsqBtU4dB?$HtxiO>s}q_x;4M(XN>P|a3v=bep}k_?Y__69jMJloB^
z!619;wE&T$}EzV+H^Ra+8A44x5zsGg>6Z5Yy
zfhdjLm-`onitjm?<)9I|ymhsLgJ$Nz%(4s2ng@d3F6H(}T3dCz^<*r&{G0HpTA#G9
z>@ll<tha%m1}#$DNSvx_{S5{x936FH_I0%&>pCtNw-4wj6Qm>3`op
z(>}N6t8Cw)6M1_!+s<;cpJiLHPgnk9@csHd_Fn{J|IIO0ZTx=zpL5oOKT-CNmhbz|
zP*JZK6CwY2zyFnE+csKUm)|GAJbj=ZjPSy!^V
z=1GBV_8C)Nr|8$qXQio3{uvfgWmRk(zFM-l=)17VB(umqzpTxsrn6>5?S2z_G;KxX
z%E(n}Sr?TpJtQtal();$nx&^T?^t%Rmt>i~$jRkKGU;9G_cKkkToV#><;C7FDxztZ
zlx@!xt`AGl+9A68p|}5**BTzDmYbfBs+mw^-gM>5T&+9N5yvGY4!rca_O9;yau3HR
zJzP5_ZY{pG^S!YD?$a%`zLh&NUadSy4IBA#_r4EW*D&;GhyEYGyEIELpmQ>4L_h#%^y{Jxy>6kYTAvfQH1DMU$qBG-zgs
zEC`ZF>WT?^)F3RfW3kAN1uTo^b{TpkX9m9ydNh^&tk1OArnOva8CIK4*{;c@d1#jA
z%@vH9S1$UA@VNhH2&p_RprLD|uhWoqqJ5HB0;u_hOl_3&;3=u1kxU=q~Fm
z7}Ncu+F{!a_v**8GIEcuoGkAD{m|oYwv4{@k}amIwQ9}>cL~h*s%ZHYUb0X2!;|G=
zQp=XEn0W8Dx5a;k<8wk@KIG`vT>PUi@wOP(&i@R@dvoq=+c;~A+?fX~?w6*YG=0(i
z;JAJH;i#Mc8P+w5|GG4v_0G2s=a&9BHUDw&ncw_(-&J0pQmg6WwwL9H)q~Ox*B1Y0
zs1N>=Y5!1gy8S2pSIYm`mjAl+y#Cbj)H@HA8>Y#GFa1$wld&nKo;RfVkde6bmRMiQ
zHv<0|qTZU!Ws>;vGO6PI0!1Td2hKkXd0DZ~r6ZG5mZ^_zc|T&c51@u9E7`fueuB`;-ngv|J<G>D6UHADa_;OjF&Og&tZ|D##sNR2s
z|I*I-&JTOcwk@1^W%I_9L2OL({xbw=cP+JCxq5L{ad+Koo2d8yoTu+QE%8^&*l+Ik
z?C|4v?WZcPyShm&dgJ^kufk=QRWwWje3>+2d44oq|F={BUvtEE`Hvsf>i5;p%{~90
zL0NSD-=g@xEZ1}o{Aci({P**p*URkXPfDx)JGB4Ue+CuPDy|vzUY+ht%K}4Ac3pT?
z6H|08{_FWa+VlF?mdI&8UGtye_53fQjS|mxto*~iwkLjny;A7!V{0A%?Xv&g{(03Y
zyR5Bw_O#}$&UzNASPrRu5-ss$f{U6OX|7TeD@;}2ut{WTTXUzBc&tMq2D=0Z+i~X0I{QqpU
zll|kT{%7ESrroq0&xxVlk7Uc9l{Le7q)((Er
zo*%P*|NZ!dGqI%z5o04Kf?vrkk0xt{>5E;*XsZA&->4CFa9q}X#Ds6
z>c0f0?@F8K*)=&=Iy+HNbjj`DoW-f)q8&|_-mWYQ+%)xgl1|{ZWjEbU>4_<7`)UVI
zS)%FVTDxUI$Wo2lt_RXIj(TpJoU7P#ROIiL84K7hWEOh3GMLONN!Z+AJu6dGb-z$r
z`^LblH{RLUZo0+Fv@7lErCWD)n=^znr&lEhp4EM};B#-|zQAjH+S{M4EUS)rJypeb
z)vHaf%zfVZ-TAX?t+=^z=_;eESt>jE(v}H(&I-_alXCZHV6f&<
zH;d(5(<~;fH?`u^(m3ipC(I~4L~Oe3obd7o);_MPhxt4YtYfW9W2m~mwj$~Ln_WI$
z?iMH4+e`hu%J=MIm08Yq&X{QncYO{?^{YIvZq?gAyUXmZ1|PQa+_mrX6Pfg`bMtqK
zok@AS^3o4`r)cfcGI{G#)4NWMA%!713k2O3aBVa_bY#ZaDvPX`iM#K7(hhk((PVQ=
z+}6pJD_Yo}t@#@q*~g+fhr#ysSsTyCS6a4|z2CWa_0qd8aPj=5$
zn`#!9mdWb3_FNABsC)HE%bw-z+p_thw---3aycaW?(}N8=F*Rxoz|SDv(@{TtM7jv
zV|>cLs&n4jfJU1)@1`FQlHYSA+i3(*7r4%kE#!E*t^(z_k0QC=Jqw#cT3+H
zPg_@V!oMoBIO^D(jVJQ9^8sO|?r_^haf|t44OMR*mReZ
z;-xG1rLHpzHI9nB2{IE1y4V#HV6bR9s5u)G*j1*%$Z9RZ=*6noDzTJlx=5RvW})A0
zFR=zGRz1xJL2s8B&RBZXK37jOCfU$U^LJ*U1J6-C&EJ`2mn6;vcGYRzcHlXx)jwk+i>!aZ%tUw?tK}H@>f0nnY4Aw-MCtlX&Yxfx_a`-L2K12Ud>lG4{rQ6=d>jVFf*nK*-ikJ4k
zpZuTUXi)v37ayxjy1n9maLd1T-#D8+NaGi0;jEeUKH=vl*2I2nImbSGsq5tLJ^qb9
znWIiVzAtrV!i=r4vPW7sC2y~v&OQH8V6;1XShUPl!!4SBe7@d(>U-0|w7Z&b#>e^F
z9dnh+KTnLP+xjq0_2c}`CA%hZ?-!1h6qlZK?~=vzB6_Y$w%g~TxjXfua}!&;Ku*W=e_X!Bqa;`j`dm}
z-Fw&7I9I4OzDsf7lHNVznxZVZN-sK<2TJuoB0j2I2X47o7Od&?vM0
zbwFNvnvS>3C(o0nTdne1qJwe*3s#zzWZV$?6k|MR2zFrlx>Dcn*7Ir==$r5{}~p{I<`apCI7#V>$;xF&bl`1`M;>>
zw!aefUI*sX{r%5y&vc9Y{!i{PN%vUmd;fX#x-%_}yC473C-76(RQJ!TCM=fan|{>3
z>ioZ*^^OsN{j;|3@iSIk{C`l)E=SLYEA8~U0QwjbRod4){vA}+0usq&ZKQ-psBKzCh>qGuCTo7Al+RR;}^{G01!O0Kn9(~K-
z?p?ekW|4uzoOJ^HFI}?NXV%AGXy-3GKIy009L4p~@huJVv&!uoRvZ4&-WvFMOYe_s
z=LL2Po~U?!^ZZi%o9CBSN7Wc_jN7>J*W}>!hkNb!h}uVdl2@{^esla%|7Ot1s)uT9
zE>EdHzUyl12eCQ(KfRehRqkGF^He#;Z(;vlF8!_ipP}Gi=og6(z778wrl^hKrn->7
zTYj_a_|Ns-%>U5jGNWv7Ew_5po7ro3)rE%nGiAR0&!BhmKSRyMw@+_a3O;ZXe(7s?
zeW&k-_x?GL80?xh=h;c#GQY#K-`W2)_bUFhijRG>g7#WHf7mJiDmC$|=;Xo=um0Km
z%#nVjbxn!sTh2qT%U;)g3m@DKlKJSgvX5FI29FD7ZWq7@uCU`>R?UilcF8O{JH%Z%B9l@ANpKXgUq)cd#D|=j8$X#l%onUUskC&2D@!h
ziQ8(ljx}9V+R654V57&`K8>`aPSI+Mw4QC6+N&#d=Wf;p_g9Ba-&_lOE`kZYf>OMN6Ng6>ZcHvsky?>GHK}cPoyIPF{BN=k>U3
zK6a*EGY<6HbKPpOe6m})T`=g>i4C7QF29VqwsYOmC3ek|y&*T=((+;6g5cJ9uMn3i*;_*_bo=c+R|*G}?SkZBw^
zZNaQW)09S2Nt4GuCPz#z`&wM)4OEiK)m*Yn@z6ZYrX_)%y&P8sSI#I56g+Ff6S7+H
z3iq|;Js~G9S&NA;)#b8SdNj>YGb>+hibGcA#EYj+WM&mIF0Y+`Yq}9%Sh&d6l;~N3
zIklR_il2AoOBJ=AjF}f}Xn;8BK^Ph}xs`ca>vGtyblQzq5@G
zU2d9nQOy0)5;420b{F|?Zq`w?P+S|B_|{*leye^)*SDM#H)=I&Hb-kOpYIjCTwt$O
z?JD`rX?mvuC2dzbc^fTX>YJYuz16NXyL;lyI`68$rxR~&KR3Vi+^rSgRLs4m1{&@#
zHcd=>>G#_@?C#dK!lO~S)=$sf@>}H`U^!V(Cd|QTYam1%D1KG>_Sq1%3XQLZ@T=Oe^$ZP
zZ%fa~EX!zqYE!mO>z7#H<7YwUN*lhjgfHpN<4vfT@9A8+T;Zp8=C-#JUj>_9ZeN+z
zS#G&e@Vm4{U2o9JmtR)C+w$}6{O=uwH`|>9R(*~;6MJ5D(!wVp2mTye7&U>yQK}WtYgx#C@@a5v*;){Q+$d%fo_ljT3XsQ;oadgjc0
zOS`W(E82u5FEUCf-DdyyZ*P+4vXg8Zu9bTwmrgnMaDU5lwynuwC%Jdor`*ZhRa%Q{FWWOSWp>5&sJ~q{5PHbZ%O(~f?@bTdlDpGz$+`9;6Q2h;|7Y+y{@GM)t^BW|{|wg^?B`}>
zhpn}}Bob6$c;MINQfW)oU12WjPh{Dz?XfBq3ivtUk=TUC9$RXP^!&e=R$b$9I(#+c
zKZDiA^hCvrxt9~~sH^l;hfQ5K-LNN>uT1~5=~=Cn_pcm^k}@lNo@c-3{xA0b3~@Vh
z(|CVvJzcePz0c+irD-Q#MEq;o@chG%Y2{_|6;G~}yejf~E;B3Rb8y0WGpFaXHnX*S
zI=OdBV_d6v`@)VV>*~2mu6auRS;bnqCTCv9^GWV3zalZrYU&-%Y=QeK-9IZTk1+(A5_ft7pbe_&c{&
z)9&29sb&v7cZ7Uec&GbByq8VumzCySnT4(sV$vtsYVs(}iwP3{vgibx#PmzElH{g*
zx^n5!)P|lT`=(sx`W1Y-E3rza&EUYksnXGkZ-b^Uo5`vdVm@YOhNll`Kdv(4_~k=>i!w_aYC^7TK~-*KW83~t+2Y5^GwygwfOsg2EMf_
zCnFl{uD)DzI$+=7poh6Lv)t!o{$uVs#UEFE*6#D+k85k}H@b#!ln<2uXB
z<gVPx#dff8xOm=7BF7g`8LYpaqygQ&y}$|?o4p`WWMR+&uhNhS_^9nRQJA|C%j>~
z*OlugGlObwDNpV8oA-3HOiKUK2rJzq$-0v3J-1$3)MUWae`;E_#Lc=Fe^$*i%YD%i
zvY=nDLP}4vFwi<_w{Nhk(Mmym+tp0|JaLnc*=xOQtuU>$7S`C;CcS^Dfn0XZkFf7o
z>O#67b{{RABRH>O?KP#T+l{`JO5b?1Pd+kdqtV3ETdQ~qpDj0`f9Xqx!v=56MdETO8*n|mVc-J)bYdC=_&E2
z`qw*e__tK=`J9ByUe}k@A2Lp}Z>-lU|D${@`CnxJss8ncH~d@ldtO?|FDZY`^DfCh
z!k5W%U9EDn*K%AEwep$a&%m!gzVWZ9oR|K@qyFjax{yV;lK(U4%>K0AUn+Hb#`RB&
ze_JvBVg9uEw_}<7x0>pCY1_)#|3#WV4O%<(_@7Vtr}oOfG2nk7KUM!m;+w^vR{r|W
zFfp5v@A({AyC+{dSMI-A?*1=Q>PvH`z(2vCLAA5w-*wsT*XyVcSbpd8)=TU5KcDM2
zEB5?%?R~#Z;_u2&RovFUK~!H_{le0wWqq0^yZhf=-oNSjmvsjh1l|bol{oJeA3fpU
za-ZjWW)(E8ZHbzi#J2TWV#bsfxho&@-$rp}L@yA{($$N!O8&f}n7@2ypYGq4kM7^v
z#qr19`iu6@t2=5mOVvLr{K<-S*ke8C(CvP&iMh3_*LNQ*=e?F9-x||>px8XRMZVR2
zOX69+=K|aIUDdi(9bPYf_<7!T=YKy}Z>+Ike;@mw;qg|RPj8N%_uu*Kb^6<&wad3w
z@xE_dv~kuA$(xI(e%pA=FxvCOe+KW2TIHp^yV&fis`o4>7(YCm8V
z|FN?DA8VL~vO2|9`-budy$M!Fj{jrHI#S1dNxXma
z^H;ulQR^4%-NP>vt@zUGT14E`x7iP673-f~$~IE8Q*NA&b#lhIJ#&4_k(Mh7sX6{
zbS?h(gX`PYZgF0cWzSVUX~yrxpO(D{srCGI>P>~rKglbq>ZwzX+kZK8DZ0Wrg!gRE
z{_kh2-%ptjit5f<%~hsCKbl|Lx%b`vVI8bxe=(xAFiiYl)a?4x40g-*W@pH*Wcu6{
zcl1Al!M+W@*w_kT9eGyBz~y}Pq=
zbw<1BmSpuS&ns3cpW|;db=bjV_RG|?hJSVQzm@(MS6@kH;hz!mGD^dHC%?pRxsZMA
zSN$Va-HBtpvg1tYE5p95CkkN~TXxU+e9U{}v#@`xSD5vZOmAfT26SE8n4Ud4}D=T>{pb6ow$YTE0tX_0wmOogpcNi~)mIz!HU@^Fv4
z`m(BDyr?!?@3H9lAU)r0=iSlQsMihda}
zYZ7x@osy=@w}RlJdCM~w|H$^evc=Z!(YLFrQ=(V3CEi|VZFFPKL~DbH`)3!Q~dAe=!UjmSM=Hz
z9u-@1X6wb0t1ojw$?wYP#W(7C_tbws>-X{Nisn6Oi!QziTc1{Ge^fi-!N=CVBV0`!
zCm0HQ&qmxA&<(UxdiBh}@LSXUdAud^qWg05PWk^Tk^d!q&Aj_*^nJ-!n-{W1Jw2ej
zgI)g8u2XeEegV`9B+8u?xJfk6KUfQ%#=R
z(E3gC{AaZ_x7SI8Pc^%eQ_H)ia~{K|BCWG~XUQFEu*=$;XB9r%(putlLf0|ltL{(3
zA8hJLcq>0uMQQyZ?Y`X2v%;MpZ4G;+^(8E$aO$$d;Yn{}HtjsEc5=aXS0Ba;*IEo#
zyuJPFYD7QVdY4RBnNYphUI+d!tN5DMuYCA#s_U%n^G-bR4%*UrG+?J=bCi+P!h#AD
z_oAPE>7jpbO_vdjo0z*&JJR9krYKe0T8H(fADMGEPx&40Dp}GgVt8l;^9Ru{J4@63
zbe^nspYbZ{Z~b1Me;4Gop6#4bsy0vkeASnKTYBo&ool$ieyzzX?$;4&!LNOcrKWdk
zzk2h+evA0;EA0XCQO~1-s-)8AyuQ9ve{CiItLHAIqW`{{yvnfJTKuoVzG~Kuyte7r
z;uF5Hea^br|9F|%din21i#IXfH;rxPYg_tg>5ZlBvFB!Po$;SxZ{W5~^R}Lu$?@8K
z=De@=QPY$DtrcEmb?Vn;z75**b!sy{d%X63ZLIz3qq*M(O}@4BrgrX;a(cdT<*y^h
z-zenF4P3cAIP3W5!fXBJ+p=o+{GR$I`NmbN$+Hso7vI~=)AD7>XaB1Cxpq&hHNNTF
z-ZqbFToU#=pmNKx$)Pj$gudvoum*+cHDWwJbM=z+lc;do4uSVlo_8hyB0cYdSIwLANt*H=y0V5_xZZq$VBrKUEmF>^a*y7K4tZDpL%
zx8<_dR=dEM&Cj0AiZ%_|DAVkr{&o2YnWGH8{$if1PTYC4=2+!=-+4wR3F=H+btA61
zux(i@&!f#L)_Xebr0B++tDRXl4zA5E`{|lmIO~GB=|bTGZ6h&h$JH0)jD3wFmvYNo
zeR1R4%gBvphT)I$SR+-eUi@e1w4A=jZ~d=pb9d);MwBR}-45A7$r!jC&sv|I|(&7S&&he;rvavHDiaftY>udn3(-o9`_OwB@nh
z6Bv|WK7VP_{ZCg{>ntvhI=LrjyXdo|sf%jGm>=8fJ6U}AJFWhC*MA1B3lDliWd(~L
z{?@5KFZwSuqiO5sO*_AIRQ9tgO{l)KWQV-LvW@SwY}u3-*skJKjN6)EFJW?Ba>+%{
z&8O-#kMXTs{-5FcI{S~`))}+T*=VWqDSP*i<#KnueeCaTw_iN#;gyoL+N<5{+V@V$
zmaLl8cxlZ61K02`D<4^`*IQ)Q=T|)r3dIUTkyxudP3Hr_TP;CZ$PR6ziw|W3iv=)OkFJZPE5$
z=a;5$zB;A;>;8AwioK&eW1jYy%PL>xZhsx@sT#0ja&+!eMc|9_0jEG{jEtu+=O+eHA7WMdeN5^XKudq{q4S1VWaun{ymz@v%lC}
zNeiv&?6YKR*zn!Ss;lw(g$I|99*p1XajxGZh0V=x&jmfvT_3$(x%;_>PjvidBH|ar
z=eXqa-mHn~{mYdmzm>oDsGDc^bG|S6>|A2>pJ8TyRlJGZ*V)e}-kTB=
zydh#=%Ch&O-siuV)Gi22(0jk+{;ZYHA5HPIzO>;q%dE_-9zR3JDM5_?@~kdCW4`b?
zP%PNT?pWhA^NAiQXTyvHJ)Z?8-q>)~$7tfU#X?-%%$H`Y@qDH!b0ue0Rfx|Ksl+LL
zUk)AGlTu>Jy;(nM^7*ez(s_0f=|vVKK72urd6biBqROLnM{caS5pByG
z+qvWWT0x$RK1Ne*4~kBIxYO+BS;p5qXLfu$o8fdl?ahJ;^3Pwp$gZks
zTz%l>;yjC$Q(w&~3T?^SzEgGWU9HfZu2svHhCT0c(qUW4xI%Pqyq{sOtQK@u_pBKkwE!hDO$-Nk6*cFZSOp#
zaaYRK8_#nOU)s31Og8IExdcP_rOV;&=fk>pZkzn^`qGHLA_mj0>0E_{nC?hz=l*25#^UMf4X19m8Hb)q
z)Rg}ADOqxDhsw|Y3|i0DKC^bK&Ca^#v;Fa3%^fc)ug+Umw@~4?_vb%uoAhLhuPwjw
zOzDwNeZ@81BX6uPP4V~U`rx9;q@EcKTq_kS^rtBDr9
z-qHI|{7Lmr^~0*qeEhv8O0CX&5PbFZsVV-;yDseM4|`N~#(j0*$(T>egc?_iOfAyP
zRqb*1RK$;vsGmSrE;jqZy&(HFHn>e+DgW#Jch{W#y(c_v)s4*Z+_6er=7rMTrg{GzEaj5OJGTf3=@M!9qfV+KLQlr;KOyWPb
z+D4^h?aX6qj#&v_p4E6vEBDND5dn$fpuoWS?6Z2N+VVzDlKHagyr8Trv+%?V&t{w{
z^te5J;WFcSj~csDp3jQ6?%T>d=aZJu6RG5lx%2I=3R|+R{&{2ZdD$1-!j(@-ZGvVx
zm##V%kY!eQMXHSHbn$n8(J0ri63c!*k;}BZz$=z4ad7&(S^2jl>%Q9Tu;q0-B2etZ
z&Uv_W*=D{~S!|A1{j`kU?Ejlpvsg#cX;+<
zrLy7s;wjwsa@A+Q$eKQ*y4WMlq^Pm_ob1b`2UppZ?^T}_zE`FpIzKsZx>lC_ma2=-
zn(uWRsDA$ZeI+;Zg=Y)W*k(k};|OU`exJT-0{6f7WEEBKI
z-Vr)U@OV_`+rL_uV?8s!C|Q_X+Bc=AXUn08($(9O^zZPR^n6*cf2~^9)gy0Anl#M?
z{ZuY-1q~-
zL>~NSu(~)WV@vOMudBbyo`hA^Z2TCuDCc40%ScZt<*Z9Sk7cvNZvJ4H=bCuSL!`l;
z>q=ukyXkqQv%4z|ZoJ9%Vmr)Vb+q$eoWHGWrlVSc^?wGfiN{JkrtkX$kdbz9Jk>z2`e}+x&
z_NS)4wb;0HvAd)2pTo1Z@mWTlZv7Q{5&Iz)vX
zTeNk!t|{_fi#!{@EN5GB<=LF&?6VxaXE8pT!M{}VQKL}WJU&;~Ii<@r4=!VA
zxHKzQH%*y&i7iF9XdAgTCnUmL7bzr~lFQ
z(`#?f|CRbT`-a`0x<`AuAKemO8Ex>NVP3`GZ1W|H{+xaB>eeTl7cq_g;>vxlffJ^_
z4t#I@%Y0JsJl?3jBEz%A
z7w;J!w?DPc*?Pa@{3GEZNtLC_D=#@0PYhqU%Tly8YdW9XjX8g{t4_OL$>aK2RwVP?
zCg9C>i)T~MYDbnQzmA@EDd9iEe6OXc4{Kvsbu;eP@3B9&ZPA5N5u01~FC$Mawa)9)
znv!+$_s05Si??yL+x5S$(R{b-$#u_l6~$4;yVYhFoSw(E(DYQ?OQ|)IMlZK_+19il
z|Fo*8JIeUtp`$8Owxk%vG6%Zry>!14mU3y6M`*L=JC0*o*`DS;Grz9qmiuCNTDS3i
zRUX^KEL+9+r@_xZtOX_l%pG~!&m!OO>E8J4n|LSK|Lpaiz#Wa}A9}Ey
ztGW<=X~Om@=EBz=i_iYknp7$)Api5Z)_;b_r~jEAFgz?6`=8;+ht%tPEQLPr^9+~o
z3TG@REYEFI&5Wn34NpgU&79r2Ugm0+d5s;k^jDjY>V4D)%|tc
zMIH7+?O)eJE#}+LsNU3n=J2F@9(#|kSoMbU?W{W~wnxLKT~v8eQ0p4ppWNuZvr~!r
zFppH@V(sshYa`drv){9O`jybK&Zx~97d_71?b~w6QReDN-5*a2%itzMpS-F|nv!R1SN3#Wt$Y-GX|)YY$%0h#?n?_&zpg&Ru|l@i)p|-u
z>K9XKFS@&k(g(wcR;{
zrB{8u$Yu4lZmIT1G?z~KVzKCeN5P%0&MAFUr456RD(rZ3wPuaeOpb>uTR&c!zc-@T
zCx!jptn4#vKYzT+`0Ti1j^MS0IsLn`eg=!)()~GQUi#9I&mOPOYE1R7vUEQa^*Q5n
z;f1ToXH7Qi?^ryQ_4ND<<-PJ*wnqa$XMC>ZwR0>M|94^eTKyTz-)(;#c`sEin1-XVzz#pWOea*b7iQApKES;V%*58-Ovv_Zq
zrF`jTAESxiTkQg#>56?ZnU`mEwNSy9SNg?M?rARjzVw`W{EXph?#-8;JGyEX7P+;Q
z_IAzp>N%+sUs+_k;I?VvEm$mU}$0VhO?)tK6)O{
z3Toc!7SOep^Gczpq}&v-#P^Q*Q7JDX*oAoNO!ew=`nC#vx*@7pSHK#1D$==QKl#M!50)pMzneF8hDol=pSE|4wk(>=JNd$gY%xi*;_Fw!TKsq_
zY#yY|O4%Hxc37_Js=t_1UX65>@O!sK4z*@;=3fYzX!exH>T%bOi`}~=-_D;h%gp(U
zvdHoeca+|$q`fF_d+)hz#y0OGOXk-UM+e$#6<=Rl7{{?IvqZG_{8^s$(#*H#JpQD#
z>qo>C1+EwKi%plcHElmr9PDymQ*za+f&+3(3WGIo_k4|N&{-~1y7F-P#Ixb-@8(BM
z^)u3H@mtROb@}tXPW%j48h!^cIb_~EbtS9bD(0gHC*uRDvNy$n%*{t_$``ooT*|g6
z?CbL8vxa7}S3VYz+j8c?M?Ym{rM@QS@B6k&%4R;Fx@_`&6T^iKZ}YQ0
z?e7+p)LVEsIjb;kxw_nu@R@&tSxk(yp5z`}m(_RetJQ|r_ifz1>a(;budYsK+oV3}
ziJ4la$nQzo`9UF5&%OB1AagBpdtJ?Pi7%fG|7u@d9H_c-Zk6v|E|&E7LUl_nPZP%SHNUcuAp1*qhH!+g4wc{Prziqg=vN
zx2gqfyL#mvF6w#xT@>pv-(#WkpR=iIt!tOZY6tcIyF33E*Ub&hN5sz9tSD9aA{Wy9
zbLF~U5qqre&ht}e?V7d4Z@=G%yp|iE)|O`4-|OLjqP_9rAL(VwF3pNPF3YpV{YSX?
zl6ybq#yW~u{AXA;(egjTP3?;&)oUw`EUTE=W_?uQKf}%J$j2F~OZvqk-Awma*2fz!
z+H_I5HN-t@h1@slZ@bH1+tjwPny21$SK+G^`QN%hJ3sm@l$!q~H1Pe7
z{|siL&-^9D{wZHxJbB0ZhyPsmDPB(aZJC*;+`@SB^Hcegtrg#Pl=N>k$$sQXi3QF`v2egy)-GHQK+PT>EfFS>krl!bzU~
zGhd{ge^{n9-R#zsO)5)TEOtGYfA6MwZQA6>yDH_nJ3sMR{A>Bo(3|eP?*5`FeIGCS
z$GA1jKf?bs?2n1czN?GF%gf3o(=63zeKri0xo*7iONEu!?5E*&t=pt?7s++mPxWxG
z3VGKHImfTx7PeK&Pvt$TR(yS}$FaPFU)i@RCyP8|`1<;_uU7F{W{Z4@
zqt7d@A9mcyb$R|t#(z_vg&)uTd;V`p{`0u`kA6>8nljF{;{mPZSJME@Xw(&~6IjcV_RN7@ZsyduMtM==2rT+y*rAH@&mP~cA_1F~h
zX|CpCSJl;=x~WU1CaSC`&~^^8%sNwa&CC0JSn{;Z1>%}(W$s)(k@mCR{x93c#nUH-
zC)Q8@{4aEN0L!O)V!V-m=!%8deWPUvT*{#fc#hRFEY0Y)ZjMvqDSP`XoyKA@Uo^LHO%tz#o?o%zrsyu2AYG&G74}h$kIrZ9yZH6QS%;U$Pi2av
z+o+VRkmWCo>Y2A_^+~=;nTtger>fLlja~f3bj8QeN~N!&nLTF<`}Tz7aID_sz&*=KYw2-DY`SNb$?Xeqb)zHxgO7rsJ`N3&owpu-&akJ{|x2L{vl$nxo`HD
zTy8y{Ci1MO=i|hHO+1C+i`7GXV&#__EMFR)5H|a{(f3tP-}svs6-88E=Kgir<>xES
znxnRvH(M{{E5Dn6X!;r3mrFx;NhK@uP02VM2NRYx`~KBF{WV`sPY{#^wb
zM!UW~39UE368LQ8;whG$f3D>1*Iat<^o4h#@rt{oe5Tq2gX+Bp^D35C?rU3B+0f@I
zdHjxjtIP_^nHeWN_ta|bn7z5s@1CLe6wA)OS-5WqH+QuY=VcNu~c8LVkWTIaaj)b+Fu5wOU^3{%dnjZj{ifd$~lVt60VNO0M0a
z8A+wT`y{HQ*0Qd++lR<-!+gptbMnFj;bRy3gEC)L{%5ec!uYvI
z&DO}*XKBY9yQVcybrcVMzPCovy4|L0RZBg;`t7w*&V6%!eU98Tv5ZY|hiuj-9z*-`
z>$bh=P9BNd*1I@bCeJBNKL0>lQmofwu9qge-M^~~^Bhkeue&;xn@@bl+j;YQGo1c1
z&EbC^rn5LqOvinp&7&>K$>;dhHa%3Ri|Ka^f0R@EexZp_w$q)yACF&$zrD|ARQ=$Z
z4-B>P&!2u-r}m~>
zziT>s8SC4wUHxIa{eM|~%M9%9_VBat{AY-|W_79ilgO6YrlLRY@p;V&o%(cdzx}zD
zE;rKLUR5%Lc0_a7G9Ip<|M}V^)oG7&j-Jn&BR`|;#8HPO>2iDPrhNU~e5E)Wt?(tHa2?m)AZ|@ZT3U2(HrSouCLFTEu`?Var
z_~jnWo%d)F`}L2@HQ%}(I&%M7gP)c`LFUcxs{}q({`wU-C)jpn@o^g|7Q0!MOW3B&
zGj`yy>5`{|r*^1Lu3o_!aEiuIpO9>WD-1?5T2X@gGeu
zWL90`_0y*gO7RZ6dPAs*YE4PeYZxsOf5pjz~E_
zTVS%Sr$haOH4(SNZ`s^+lmEfO{%hxQqZq3{-#w^
zVDg_~Q{}gB-?JXSuPiV-_+w(6{F);Zc5+YrYIFT!c$MkaFRps;^q#V>$Zk9S#A3bG
z$Mi$LBd0FEtUgix_qyAyiC?w)%Ke=eNgk7QpB8SDg^EC0+^zUho-QK)UDfY!A)vdR;OuNgd{_a1+*VX-ktwG-x
z(d|fsN`7Y
zEKS|WzNoYAs}1+2J<6G7@~Gy~7KJ=};XkXD#GZt$-Ee2;um22+kzOi3R~nvO%U}Lw
zUE#c49^rq*@(=&IuCIRT*fOoNGlRF@==mx?^Q_^$Mf_)Dw-~NEH~Fx;)!pTPOXHu%
zUE8!|_20{J>JJ_FM{oVlux|CA*EhTb+nuj}GCf;uR@0X@c|~`-_La2R2krHv+N_)Q
zn9HyA-s{QGlYV(`=w+ML5wTAS{e-HTeG-3kW!iSU^n1&7=cdMMBnv4J5?sfkWwsC?SKih;=+XH7!XE_y=@$}iYSxnvw
zwf{bSQWwg`+#mRgx0Ii)?&bN7Ykto)vXt2LOp^bje*OC7h*P}MZi@^h3ora*36^wx
z*rxU5+jq13uM>^*zdx4zbJSt2$m&l9c01O*$u3$lapL7qD_h@UJ@tqKU30t?iDenTO
zeCYQ-wfZFc?04+tQHLT;n?trQ
zp7P~AIm(}xWqk07poglwS4Dl`EK}}f?i1f>+`HSC<)oa~E^@5TZPa3`>?p;
zt&f(gqWwM5Fwv96vy9xG1M|L^^{C$Eb+|D^i#~c)0PH^Jm9P9nRiuc+q-6#Ir3Rk^dhT1-1+?SUwzc#
z8B+{;y%o+`$W&iBeN5aY<)8hNu1=9k7x{-Lj(TxUtczRH_SgQ`Rh~sxc%QycygGw*
zb-|9*6Tds=YuKLr&+zr%RtMPwqV`%V4=7(rTX*=7kYS6ZeFyu`YemkkKjib-CE1_Z
zeO=De+SFk6g?$d+{m1`YlW!-iVk!_V7w%g=|KnQKBAJP|8LA(o|7?ud61i45LAF^z
zM&Gvf{Q4i)TG(Yj->9vgbz&dMKaL;X-nGZ3KhMv8AA|fa!F8*S`5Y*|D*eU&Z~gO_<3}oH{?VA;aa(2c)ReHe
z1&mbog~8;+0lto_o%J2K&#m7^aw?;ZMFc
z&+et{?-0ue{U?I2wzFTGAe64fU&VRid{tV3$JZypjbDDr*+)$?a?L%|RM;HI+Y_V`P93&MXpY&c^jNRrU0+x5w*KTNE8pHy*LvkBBiOahwd#299x8-`|6=bqOQ-<r~R_()(t65jr+4g!EpI$NZYR2_6$?!Sh
z%QI$uQ+Dvr`uN(@;4u4ouU96gKlK_32KVzu9>a#;2xAsxQ2`Z-G_buTbv24x*N(=j@gh6x?5*
zwX|@>##eVjRYj6scsae^aQm+EJBE*O@oQfca!M|e_!XX8T60`s-o35ovUH+Vit4t`
zjdWdYeBn^=O3xSPgsRJ1Hyr-B>Ur0TyvIVNve{A@W*gU=h50+bSa3UPmX&;`zDef6
zHn*GechCAJ&r{>j^v}fe4*UDbar{kMSC?Mdc8R^SL;1pW)+)o5ugZc}JYM+KMtoz8
z`;>&@_hF*VwbfD|`FVd_i`aJDc%FUKmt6BB6YnTk|6H%MR9&p>nCIfjKMq^A2VUH9
z>O>^RSC$p_zeFof-*USoaA`}1AM;xs;aBVy-z63J+II8zlplKZ-ZjO(aQ^;XQqP>y
zc0JjddGKf5(ueA*nm4~%{&kaH%_uYJ*gv2Bubv&yR9|;Zl3kXMpS}5P(C_U2M}Mw_
zM{O%GY1xzCCXvjuOilTf#h-(#E@uRuy19K%qhI~id$)5LswyWkMf{!`Rk)gE&AI;!
znL)od&y7BA`}scu<9~+NS56ikUw8k+e}>-7`h-{3<-Njhx##~Z+7;>fpP`{C`m?B4
z$<{5CPw#2^bk6UkO@#7iruFlLe)!$7t+ubKpa05M&8|C4DEaTjUsp439r&{6_%-8y
zrbVh-Z1siz{m44yzTIoD`L~HCMNj@-{c|?9$?;fVz41R&mcX0kd;Nbu+<$0m&ce&F
z4U>L`)bF_eFk!r&b7khN?cMr9H6EpwytaBGk
z{Q1vs*|(m-t~L6P_Rb9#zOZO*yf?e;-y4oM{!f;z63kCNay)s3diJUR4Bx*0ocean
z9{VR#b1knIJQrsEt3B|{-!H6p&eb}cDR#?kZPDRH
z6O@8~?7Q{6)OCAky}9=#lMn4Iajz!%J^y#}kmuj*%w^NI{oCi>>n`i-_vg~@{|vvg
z=c%t~6j{^sNwBZ^%>%N<7k)yta`k584exfzq&XHd!7e?f+EQb7UdquqZ~
zUTD2nxLvCCsWW-`@pK8>&zg5N<);>1zjU(f#L_U0fPb$zjtLrHms|39QjvdA_QbOh
zZ>E`^t)Bk#&eacDiXUZHIh|En-2BYo_KwEMjaT>%+sxY`dEje_u9$s`x$^I||Je3i
zKX9Sr>kA`m`6tYCbpKT{qr=3DS>aj{#$o&KnnrUk;&
z{Lb)e2XPuUs#*SCdvm4ClZPi>6losZULP2GLi<$xeY+_y?#4fTQJc9;TR8dhr)8Vo
zeKQf$?EU*o@WSOEiSJ*Bc{1wk5p>Mq$*ygsXA%kz$#6dOEMGi3f=DK~X~`I6{6lYX1of4}hH>d_f(hZFwUUt4-_o#o$*EF+dD
zeQA%5eY!D6f8NZ0a?+n()O)R&^zPKcC#5k7{VQy)M_kO45yVLMeX@5YaD6f=Sa0>goiC^9aSS8dP7OnFT{rC8tZR2y%$V(o-p35ys35mF9)P1OG
zo&S#ap-W|Fi!KXEc^A}vrDTPQ?_GljRYAJOhL7dF)_weE_h?H>2j7pct3D~K2Oi(C
z+9$1KA{+bueO95FijRA`u4EkiePFGliu>FhiBX!2lRi#-9VlvhEZfhc;rC&=ds|~4
zO1$CCS*9)dM&zr+uPgri%S9_69^bJdN~h$+T9J;71t;7C=Pxyw?;P$mKcH?;NWNIr
z%3obqJ=%p<+HJWr@7U6mH~bH>%wp<$GiE6+Q=i$lSmf=&_OpR=`WAONg}=zW5iWD_
z`BY0$ZvF4A9!uMm=N}h&^y-eC
z-A^mbr#d8O$M@AfXBXVNdn`k!s?f*oPC&g?6?c&DzdaWx)c+0TtL3v@p;O&|tef>D
zSN~Fjm9l&p_g`d|7oL@BYxcB!5?o|m=zp$C%K3bt&qSl@o(n4SUVhevUzgmfzqd@P
z|L#9my-)VPzKS#N6lvM;!g0}|opukZ`j7Rjd{J-JT==UxaL4mmF^iw6S$;WxX;$Go
zE!%%n7CGN|Hh0FlUIV8u%<>id^`E;c6s+caoFDhtRDiYb&Yv46EdOZ5-rlz9Icwv~
z3xz>xe$7Tk-xTCu{>{p8W03s4&hhPW$3L(3xN}(5?BJo+QO3&Px+^8Q_a_}kyK
zd7}K3hwgW|yc+*A)U5dPdTH;J1-ysy!Yse=aQ-!pac_vZrTVt{iD!CE`SXh#4F5As
zxc_-=#^0qc{xkT0QmW^w?fa&duUkIxnTB-3zYni}JzKxH-;m??I>W#2U*&sKT_Su=
zx$Ah#S;_oo_NKJ!R$JF^TAab
zH)f>ETO71oQa?HPK;bj@#w~L8a{Hg(TPYMDcKGuFrFnct*6E-AGpL)!pSiPIJ-BDq
zgt1&=&tM;w;3usZ-o2N_MXrrKZTPDLl&%agMLv=F)Ta>s#FdFopTT0;bA`vR-7huB
z9hcQK?vZj;2$JLD_xJZ=Q7)cp%kL8s#C!UcJG-cIk>R}=(aOr}3$!h@r}fo`ZxlLq
zQ(Vpo??};(qtC&9L&y9bj@5Bw;&Mz)m7awuCdF9XI+j3ivmwVNmc-=B(>dena
zuI00|7)|WTYO;JE*ZPQ`uQe?tj$h&N*23vx{P~J^I1V0MU(VYV95pBO!?&wEO+KPu
zl(y+Ev)5)m@j7C+*SBZuZk^n^^F_tM^+BTiYD<;ZY~I5x^EcZgCXYEe`NDNwo*xID
zryb)rUCMenA$j2we&?6bzmwY{syF8@vv|B>)u%J@%C=R7J)wo#$uH~;U;nJ1x8-=*
zgXTGNKAv@1-6v7R-Ffbk|KoFpA!-E=*10)6n6=-iJ@&ZdJL^!lh6x3>C%&wU47b*N
zc(J=!tS;D*bLQHT
zqD3<%%KK$6tQM+TZ+m>L``=kb7JvK;BX^y+XX0}suu($hcewM?tjo6r*7;e7X5{d_
z-&On9HN!Fa=Je%RPgaH+FEi=6FLihJv&)<|?TKH0PubA3Vdd7f+Hb|h1lL?R`gxmF
zCQDX5${kbs4Jzy#)1I%_UE;M67(&B2Z-SH6`k-gj|Zz
zdikT05`VQqLZ6q*lt2FSeVy95NBoL@(lW`Wb+@u-Oj&eR!S9vCgMT7N1?Nptd{cC2
zjf;Q`yUfS$t2M2A1-H%3v^;yXb;+8l>05jIpSjxFm@YcmtTs9O_LA!QFEXJgrWP2S
z{&97M!|m^FhL>$ES3I9|vvbKQ_k;7~&i`pjk}0cX|93WAw?_2gMFsnt0&>;U?a!_b
zbx2W3`1rT}*VU@K9I20gtgQB$f9Bt3gG*n2+e-aZzw~D9TD8s&Po>7t_Q!qMi>02e
z);6DAt$5sbf&M3^O^Z6ai>!ZDhjlrWo6GLCo4V9$s@ZPCl@i;_Lar>|xuc`<^JxuP
z^PM?$rDyIgE3!`8b$f;Xl!|pl-)zLrSE-)4do$$C7I*zhzT#ikYBn^y{(0^0rEjKl
zUhdqmSgoa0E&GQ{?zM++um6<#l5l(aJc&~I=UXeUx82j&`a2?ZVo;>So1XbI_XSne
zGMe5u&YgUF(}r93}0WFhURQ4T6XrhAjwtYo?
zRpuMNFEKh5BfGTfSF;~Wg2e6h$)TUrRqL;w+v~pm$CbEZ?V7{c<#zj{R!>g)boxe*
z+=EMV1dm6pQwy@MJaC-XBPC---cx@!*_U_1bkd(bDV&waRT=!FE41KFAFn?9B;&st
zOzM&kdM+ECzWgly)KZ17!8_`?xXMdZjmO{8_TcNF%7(9hR&8D`%lKDw_UA+U
z{o}rRIX%^xdj78EH>H(#Z#WjY&z3)D_j)~#T}yEgr{5d%*M9f+GpoOR>DFWFrt+)w
zNaf9cljhAYa{Md(WmWam8|%a3_bkaR{ndQ7WXT5Exz*3NhV0t5b@%c4{Ac!;?lStz
z@g%IMKRM#;R|7fG#NV6ys<_r%$W@tl_dmnmSnZ(4zO#&H^xqP{*mslt@r8dDzplp2
zH%_-cu4XPBQ&)c`%-3}1rb(&d{XN^2@Bhi#d~jZXfNl7Mdj1bmNl#-?+c_v6SVr?G2Rb3NgQ9DZke3w4cSRisOZTCzYQ`A75XU
zbYa~I{y1K@Q|^B5TO+lk-7fo?t&=#Utx@hQb{@RfR!$O7_zy8E}3*_@CkHtm!*rIsNaI%Jeb(
zsjxp0a#8-iwjA3Z=Kl;#x9pwjty&i7)bE%*<>M>k`Ina7ZOgk~`0-_5{ZeO*tv!CP
zs*DqQ$`qb|Wm+G#f#HOEYMI0<|5No-(@%KrIA?jQfW3$#|7lno*QWG#zIk)&3je$|
zU+LD9GSf@rq-s;0;M;#SS06k$6e*Egn&)4$AfevteCx@ODfOJ;e*O-*
zPi@gn&?SHIdwlgn=<9Vmvwt4T4
z`mtZ|`p+7K9Kb@z6q1OKB5(;a`-Of6aaHt5}~
zKQoPf$e;KkI&qfA-1?^r?>v9S|Mh5O>!wY|j~UOY7O-EJZJHvV%-Zo&VshVu+ywTg
z;R!i$Imf)0)y?+*&ye~nDCNox~d_Az{)A2Wx
zj#=jgezp0}@aE8Z%Tv={81H`FJpZLHW1jGgJ91_l{}i9AkEs*Y$tjf2`B1y#Kf~9q
zwbHG-wEWM!Jn${}{J$10-yf~#>>lSal)v|xbZFwVAohFbA7s8LaoNDu{Qnt36(`F@&+D=LW^2Eem2WKQDhzxgx!vXX5c?nV~zLeEF*xqvOMOe_8dFuB-8u_HkF96!%sA3M|-|BJY=R
z{_)F~fz5vB*tZ(;owxb?+N+YKT=s9~%mwm?_ZsrqaP|CIW1arz+5G#m{YoH}C5Fa=s6zT;tUxbniE5XR92Jb}|>egbP%
z{k;3VNw3WE7EL_;pCRp?jK;}-C9>u}no^P{RGj$FV7YEiWaET-`Om*Dx6XLozg||`
zt}J%q*=2M1_#E?&lqz4p|L51$6>GRAI2^P3&oKXU*G;K1>4tj#&;J=-uP(f$Df9KK
z{P{nBdDAt`V&4?()7x-vno3I8r`tAt_VORsYwh9}JfNQgpI~d~=WCitgR1-rbUFb?;m3PjJ1O
zBvHVB!{gVg`raZrq3iGR*IqDonE7U7(r$h|cZRJO<=<)bKjSS+yi|DOllDr@n?2Jw
zyym<-t-dkj`DfDuKemT89XzA#(8jL(bdra6`pd@tYkS$>Jox)^dH(MV_fJQQ|7l*z
zS$0XSy7QEgrbhbQ8O&c)u7>sRy0OCa++@4@>!!ayYO54EHE*BJv{Js$IA-s)<@E(i
z(|66i{(H@H`KhIKDtr3tj`RpvUzaU3dsM)%j>|acs`9I)Z9U3G{~21pF8KgD8h0z_
zW1}_IjiDA6sapQ8V4VWXgcStG~bRF
z^<3B1vWCYk7xmcou2xCqRlt*ryXB4Qlz)X!&4?GadlNP3P2TL|UhhlZ)}0RQvE6gZ
z^PkMu^=3;Y4;Qms+@hk)XUX0M8jwBYvZH79zuM0sVh(p!K3*uY@aL&{4o|ACY2K*W
zu4A>?=-Am!j{jE0$0z%RiziMzKD}7}UVME0!X@tB9pCJW|1;FgYD=j!IVk?G%Bk?+t9@7bXMStd6Hht$=|uaVf6CVuv!7Od
z{KAcE-u=H>(fmc1h2_sn=l8!pu~MwQ{@>m(w_Ep8avQ3eZ~X3(pJ`uW=J_X3`1*?s
z!SXZg&(1&MD|Y*EN3M2N)9E=M+urfB)Rihs?~{;EzBS$8r?-y9aj(Yf>hm(gatiLR
zwRo$2T;|I%-H!fK43;9z^X8jhniDd=Fi?o`Ny4QaC%Hcv-1+@=+2q*YN2L3w
z6`4|+CTS7}t(kN4W=qRon~}slfm!jZ-~A85f3+UpYK#9;Y0m%ixt+%!=@oz7w>n+=
z=_B;8X7SB*8~Me3_I6n@-a#6BSM9vN#qiC?xywJTnjC37xyP%z!OY@6gVfDwhI5jW
z=RZs`a{rXI=5%vs$2TD+!ylhL#b$O~*sjIrUl9IGG|szr`BQ2C+IHnnYhNx1JN6->
zjJNrx)N<3E$*oDzzbElb{PA`9nV>Y~LymR{2jmv4e;sI5{DT@Q&UIs{Xk!y}FMgSJ$cc@yQ~i0g#JZLHXVkf^*`@h=Pt|3v4R7Z^4V%d;Dy9GK
zU#O(Czl_w5Bj)%1GjO?emj}*&9;I1sRH*sfzJhJ(oxBhWP5z8UxfUg9p6RnE?;Gq
zdAD=Xe*5^Pihov>G5me1d?zGl`47LWcg`*m%O<`I672FxU$IKwP>o1R^%wEb!8|Jq;j?x$b>
zW}N>Kl2y3V-KVQ)QrR{OWd;7g6Dt(v8E~ysZ+-sR{@H8+2B&A6b?29?cr1~yr13@@v;0J*^=>Sg+gCUx+ckPV{v_>xX#sC{+MSJ`
zFU~Szc>lfqh5PfE_9KVBO?dHZOND;o3VX?SM?Cf~3J=ay)Zza=Rps%kkohN?zlipJ
zlskX^gWrN1KNo&VkEyS&==sm^cuiLFl1IPo&pY0Fxn8+Qa9YK7=HA72bEc|)70o*r
zd+pogNfA#yzw7LH{xLD4PG(MQMw!v-pKab2hxb+OJ9_s&LqBuWx22QrEb0+S)3EFD
z_&0T}uSzO!Qih>=1$!Gq^9v7U`yUV1swgfBlP^7>An*U5AvEn>m_|U;?&+WI*e|QM
z+7mG?pztz7h=^^(nhl0FkFyQmPMrK}#p=~ZmS3F0fBHYe^C8SgCaJ*?QC|0zRKt?Zb4?93Q`zr|mUD(0^7v@hLW`0HQ0{am$wq30!!
zxi3%tDO2Y*abH|5yL|h9hKTv6+E`lN-2Hc6`GZZ}PI+hlUb)NnDPKKASPy8qHz@OdjKSTe|vxc5L!P_dnvHxdS
z|L0|Wx2*Are_Li8e=fiN$ED}IfzPimFPwjFx=L;BURRIPT=(X;TF804sS*yo`Y-SP
z<^K#m@A1pzbzL&zkRPE_nd@pi_2{;+lGsj23%o~VLQJ*
zKC82h*Xz#L$F?hXJeEl*IbRrb^;pn6-J6evZ5
zgu9M;T+%tPYs){KqP_LUHs`Ggy*}~UuF8eS@5z*yI==mv*4u8o+S(*%Nm1H`m522T
zj}`u_Ke1fJ+T*y~*UhC_%t8kQte*FTnm4oexhLNV4$8MfByFR{Lg0@&9>WC%g6uQ
zYvaA)^N)TnpY?u*x0d#Z@crelau&OO_fF}52K)1$m!7w<+wyfna(4Z%<6le~W;3j?
zeKqxKi+RD+iSD*VnlBAIzs(Uj9`9Fw{_)q9-i#Bf%KkHOon3VG;*)*aKk7o4?7VzE
z^Q5Y~^FPt&=3`y|igGO%gVewp3EJMsJewS{%cALg!GvgXCYc)O{$+mD@^zuPu&
z&WmHqR=ZUkyJdFm-r9$!_nJA+IO+3sP0~_7j-%BED*@a2kxEOwf?DEUtT^Sp@`CH5wdMPk7yM`VdU5-I2CHiu
zKboz3!ZyRuZsYPF;i|$3U6(h{PiBsps(DmbY2V{3hl6{bW|~zUZ`-LSf`8WfWvhDZ
zz83jyp7s6id9e^}*B4<|{^&2h?-Ufx!SFSNY0vZcAKvMT>6e#e^nb4oUvBzoyPM2a
z&v#QdpDkK>ZqCjHZ^{y1g)d+F#jfOqo=b(77VUiPHdpI)tmH!;j+Jk|dhfLh_;zVi!k4pU
zv$i)a4mz9T^*da>a#3uw;VCiZ3*kH6CB0VNd3+=_bn$!V&?lw8)Q`+mzBQ}OJ@>)&
z+GRf$9S`jF30kSXE&G6+n)7E(QPs6?kIrd)FmcLnDXqlB;D{HM+g7q?D!r`t>4-ngRMx5{Jb
zh6^c=e;?keIN64|`R`?)$;jPqB@{xjHIh&{E*y~!xD_E-P;
zKUrHgHcnd1{`=%#*NlAzoLmiGN}fu8SfSF`uRPy(x&6c?p=XXY+gG!c=^lR_n!c6c
zNqcnVe=px(@c4@@sr2UtiTW!056f!S>@Ko3vOh1n
zT1Do$wg2~y*8HSXUJJoraD)Wq2Kq2;Mhw!g3FEih!s&G*_87U5`L>Hkq*
z`O~s|Pc~_Zud?>PuC7W5&S-)t3nqn}3-%uaKqud394R|CCxiIY~&v?yI7Fuen^i
z$UA4Z1?BZob>yDo-JW#XJ#;0
z{_}4uk3(zVJC4UYmiNzOv+8qo))aOt)Rd7k?ys7rP^MOK{8a66|CfQ9CxVvCp1&;r
zI9Si`VNdyA%ay505uTwe@(&*TZZiCvRo8gn07KJ~{+#~|y$*X)7!PfGc>eJ}QzQAA
z5})`g<>%FFwHaNpd7Q~?8Q}4*GX8YewlgWWPL$=x=vB2n=)Y|0rE{FkewTmU42Ay7
zKd)YSWxyz@QtK}Ni?3d*eWzOwt4dGqBQwie?yiab&(A-|dgFIo<*WAmBL(-*)@z;J
z@-$B8v83d23tRhjc2lb~E&CilHQniVax?t-XmdhVM8hVX^mk3}e;C^s{utEzM@^4y
ze!EY4e{0)g)hRF7jHlg*s9PDTdq3?`amUFZ_V0fDpN>D$PE%uT+QA|o(|08Onfyf4
zIqTCnZ+XrMZ_w-hk)`pmG2ht5_UGOI44bdV<{dwie_--h~o_~DspP{$(+U9b%fUsS9hnwZ6`LUU;tNQZ%)4!=pHsy1x
z86Ny;d}))ia6*>H->Ci+40BFX6~MU^3Q(-U-@(Viv0OM
z&t}P3wZ*j*9#xvu-2d>e`+tVjT}dk1JB;S_*#E7+@Xusn&%{oCl}|UmzNlZTRwZ}f
zGpLL_HPy|0<#U_=4D*joW;EWeb$r|X(-VW{@8SHX=kWbMgXN0ztPzD1dy@C(e}3<9
zetP4<_}y<`Wb#b@5z_d*Lh@hyG|eM_?rWZ~X%0MgVB_PbiL=7&^;c`Y^+;KB^O${9
zUd7`Ne^!cavfI<;
zDZ?uz%hPT8|1-q8$WJOhSGiP%hkwN~PsOi`uN3z!ni1XeFGTFiE53{!Ld^4z|GezK
zJ<#`Vo86zTm?vNVGrazNfjOG}#a-K8m&ZkO{+Sxe{H?03KmTc&5TA#9eATqJuHEKL
zYrm`tI_B`gTwQLb{PUku`xTC#vAk7p)fXa{zasHv
zpJjV-s?CJL$n%U({aLFDuY?7~`X(#OK34dCJ}Xn5S$@Xbx8cj%pPrC!D-Jm&aP#=}
zTZ_J#+$kweUb(z-Uv!>)`Oi>y_A>YNGC}XP4?fM>*?KD0=;QIYn~UEv2pn#x$oV(b
z;l#y{S4!DU<|W4MX}-c$&KK=kepyvlZE(=0?=k4ujTWCXN96wW
zzji%zY{4#`y_N5ZJyLX!*UhloH+6=Z)}1=#pZ^(pZT$N`|EoBvuyH{;&kmJIZ0;-N
zAO90kJ!!wYOm0=R;J@nnU#ksgZg1jO`2L^4ey-lz2Q^3Jj_>%-VDZQOMTWK1vVidZ
zWwu&N4#-v4YxP-vXDVVY+*v&T^S@e+&lQiCztT4AcFTP_rJU=u7TfvlQIAZ|bF6zd
z>2Bed_0FY_R{1m@lV1P%KZE`ArLk6}6pYtBeZLzD~XE
za+qE8^2=YlHRR1j4f!85Qnle;p(nV)3)L!0=Veil3_vy=wUo
zJ%4@Fvyw>p5ciZ@4faQ8t+c(6^ZA`?as4gcp0>xYPb_$)^3|sQ+Tt6V9=C5?Sn}e*
z^Gh4`-afARvNGzs{gn_QAFd}deOuQkJv#TQu+ZRr$&QqB0b#t?Iu^{G6CSJGcEYw+
ztLFrV#gp)*URxetxmJ=H8a5}daMR28a)oD&G}X7(UfirH*S0Hi5&PP}Sy%nDzC7&6
z&8jrr)a4)XBKlHIa%tKDFK_)7rZ+P88E&7_6y5f4+Mavf0h|X`nCfx8(@^H+W7tWQm@H63z!?KrMhqEM9(vkC{#L}~(mc_9Ie)L&bcLUL
z+)%sPVr3B5oW46(PF93JEj()7+ReIoUO{#9y~RoFKjbuTUvqu^<=LW~&&S-?FJ)+$
zQ?{b>-+TF}upBw7%aV=X?9WYf+@1NjKiT6_^Y>q0mWdx{U+Q-AxJ(z*k>!&=&AZF$
zcDAXUtG`nAlg8)92meBN%Guw|`IT~6^294c4>!Mn2j7nxoN~V>-)bOnk>Th46{(^7tV)|3ZdELO~U{{CN5LeJlqc-qEie{A)X<2$~*{m*c1
zlD8XH|PuMhSH
znM)7;OpU3&*4eQpTqa%K&;4oOCc)eCOQTBEr&_l!{LdiO-#5SDSE!n|tGnxehLYbU
zD}3BnJiilq+{x-mZDuR`@<+T`OPpQpcU1=z)O|Sqb>%7H_g`1sbokGZ^84zYwhpht
zc^oTl7QPMMl3HD-G{f_ospq7NjDcTF4$I4JO`KAdG{b%Q%dnZVJL4rD$W#XjRrg*s
zjOoj4<-fM-iHU2gt&t{&#q(z?xqkiIa(2hJRXfcj8|OQ}_tkuT{?Zba?+2HCysecv
zIq98ek3i+?V9l3(GmpOvSaCohr1@z-_l@8*m5ooD`;MD@RVcC7e37MUncO$!;mh~4
zX7dU!ySTU3(cUpk*?NwFjF6-J`Y)@Rdzz|~Uxz)id{EeS{)JX##!SOG=?#{De*D|2
z6R$PtK%%sQykmf(j+?FL@$ElNHS8<+X8bFiaXPSh$M2N7`hTmoiq$l+tMbc~%l})o
zTDr*gUz~0IxvVQT9#8uBILe<|I3;$wbvlcTzVrJ#_4?P=AG_Usd=B%eIVJxYUO%68
zs&_L3=efi8w^>U5)ppYV+I8TG!STme>gQLT?YXoq|DL9DC%f{6zWZmwmM%Q9QS-?=
z?!TJ(PflT0{ZZK{v&ZM0F7}tD6#vRw
zcTplSW@1B8@r(LjSC9TU{a5%A+w77B`nQrpb>Ddg{}PNXUHq=syCn6X+}1turV{(L
zYY)wvDnD=8s+!&Yg$M1Q|M?si^6=Xi-piog)|0GF2`gisJeIWm`zrPHF@EXYwb_Ex
z6DB|9omBSW=9jPkwr23QbS=&MX&GmHZJkSf`>sB_so6o2w!0H&+Kc|%|NP#ve}?bh
z{;PepY3>^S<;#~wY3{80%NwY)+-XUHZRUZACtq28_NZh$a8TAgraGvvGOm5Cf{dHF
z<}rSS%Wlpo-yd9HV9G+`V@~k{Zm8ve69L6`5k0zY#S8o1dH|1*L{Nxkgmat8>PWhWT$z9=RUsc(P
z`!gK>JzV+p>k5G<6RHf3x}90q;#yzf@Zzw-e}?&4YfHudY>9bV)gKtvVO^c)?3ZJ3
z;-8{(xT|_vijCui2ep=~jGUW1CI4uLE*A6&Y3#ci_eif?xA>IW$(cfjw=Y)~HD|lktjI6JS7d7^;GJiPlDz}T{!6*H3kG9C!p8m2-!x2hh$1bs60T70uz8Ix+TdndEx0-myCTJ;)j3h8XKH~(k2?t09P
z@th`y<%tLNS~K*M&syi_pO|+ghJ$PKCq9Yl5B9(AzHpj4E;sMWhQI?6%U%n0N;A?#R$JLRD>)m&5W4DkAGkrEs((}07*1PUP*Ls4Q
zCLUcEw&u8=_0`jRZC0v_&bw$Nm%Y==*!A+1m7Cs_vu52XpK;u#>o|YkR)qzl~k)6?u1J;_4-
z^P0IVrCJ@ge~0fknV)6bXB^4&_|w0TkM;{!d{bNHIZNLl&+*`w6|-VKhWvT&?2&f&
zTtVilv@Vx-#dGT7rbaos&%N=%)nuFd>7QW}yIqTwIK@pPFRe8^e{E4>tYDh3=aeU1
z3lF>9404T0d>OFoSJyq`^y%@uoF!^ou0G$E_*o|0HSy812OjlOPiERn^-r}7_6uma
zw<ehcR`+S95I~WlovPWjpGN?sQ|n5k3SPIBVym#-6}O#1@jKiPY!K4YRO)(yz`ph@>x<6&(vk=wu;ZZ&TjJT
zxheO&$_JMuo+aEk&$c-2@v|pYUA?zu>#Y(e^cVW1w9c#y-u=>He#OD(H?BngUiho4
zb7uVenzcUMI)$&#DopOHlv}jA^2{7_2=wURxwV4_gmV)iRxosF)GCkan7+PA35nXjOJYUFK|`nS5yDw*n<
zpG;$qCJC@B`tg7Fb$i)&yKYa{)W$f~nEv-%b_qu9RsXhTcC>RHp2xpp#XXzSCm}}z
zf7SH*D0yt2IPsO%WwoPa{W1$zbo~4E&op0gS3#CJ!{3L^QEJYvK{J21El&L^vD#P6
z`1sSn33dC9tu>O;7PXJc{AQZ4;+IrneBi{enY;pjT@6;)TC9w;wbx2yDP6VGOi9CW
znc&-Csbq$%$%=~(sLN_T__NpQs^R=#f63#)^OK`Yiqv9)`&Q4n-1u`>@%*TDOPl^?
zg{WU!vM9+}KI(lp>^eIoHjG)N?BMIL(ET+W|K2gI()zt=@q)OlQ=XqRZIahIYwVX~F7tC#
z_*-4?7`8AeG4!A6W4n26E1ZsOuc)Sr*TSWy-V6&~R
zk~+Cvx$g4)pI3j#_f^Zte_V5;FZq#<|I?S#H-1Q*I@zwJ!Tn!T_R@{HAGG=A?wdOG
z@eG^yT;~oHi*zdetFT|Va*uw2o=Jv>t)TnM=nK~-$IkyF81`e)@5M{o5=5B8lqaw$
z?+u7awwsz6Z5>e@x%Wu4XPLc?eBzbRt2GJhRm#4u`TRMd@qBXF+mw5=qgSkQ+3YGA
z>#X^BtGD#qTg%_g6Zy~JwUGN~kZ4}W)wKsJ@{;q~FRf{dv<#jfw`j`TIek;5b_TZp
zYzOU!FHp6;@~dpoA(=nDhd(ZT{qK8yRo0)yMW6PcYBDmGe12)dk#lwLSpw%RD161M
zXuY{lqHNjZ-F+=3raDW!Bqkoe7dP{rtwuP*$M5oAOa+R+l)mlTvgVX{nXz=i;or+9
zTv-3fRzby7Ii+_^(Sa2C_go$3$+wp}Us!a)B6;4I5AO0&4d!=EKHT|da$v)9<&R5}
zPpB;pJ1m!Z=5Q{Pc)88D#rB5(LXIUK4if&%SLl(lpl9;D%#@$gmA9LU6%^0Ye06xD
z1OMHr$0h%j#`GBeIqEUj>-oDc%gl8uMV2&jJQrfJGLOpmr~2hd;5DPY$GseGrsg$#
z$dF_`l`q{M3Yz7eth~H1Y)RmG$rI03YaSNOi@vuxJ81HSg(}s2A%%hSXD^TU+O1V8
zySqBnoYl|$Kf}6>S;tlfsYyJk3l&!Q!?Bvjyhuyl`e;)?+PkttA{F&cthD`7ACaeCa?Df+g{Ab`U$ZY7Har;c*RQn3P
ze~<6Y2`O-V@QIgmYQFCN2X>F9@J`A(e&SAl@=FInkDYIuU%w96l)mEl(rE2I=~=Cp
zWu)4IjF>{M$O;M7HAj&uh2WKMr};-sG;-k}>n_-N<+6CBMCo*luQ9V5Gfami(d3
z>vS7!`s(MFI4yR)^H^=GR#j-yQs0v6W^*gn?C$m{TlXV$-{Tu+)ITrqaJBR3x}p;H
z%h==WqS9IO)XoQ=4L&KdaHWOvGKseCMMV~BON6WBv>GP&WxC8*@x*FzrwPl=*Vp>Z
zR{WguQGc)hW-H}RpB*Z9uYC4=CKy_Cs(j{-pr>Y`?;?%zeqH9iTKh%PR^y5GZKW`a
zUm>}kyX_v$+`aMTtywN!i;@hE8n!>keDclY+V^K$+;uLc_}FIdS@~#*{fuSuSz8LO
zESsrg-Y@w3*w)w4t*s>|&`;m1v%PmDDxU&~$V
zJ6-0w$%mJ3lB@HoM5Maa3~tItZQAZ>epZ?_@4*+-Be!4eHOl%^)%Hd-N9yr3*@Y`*
zz3x2RP{hA*>E}-s7N)IYOC(sPPrf~C%XCS3%{#XIQ3nq$`eJ(RO`mjsVUXn1_Op@N
z1=4-{7F_(+w3lD5ZTS>lwVHI9uGWrM%U_3HdXhf5KiMmV^5C*<{?5%If8JUAY=5PB+FVAat7d^us&f0I$(8ZD
z180gJHx*Q^d#`+{n`gq*v=cw0`mODC7As%h>->yu*)-+#O7k^hHiUMZNw4_wPD@Se
zj@5%JNxsXqGM_y#IMO}8&~*k+#^*D+0n?;68a=+Zmbb^Y_IOnG0`1Q=r(e4s3#m9~
zEO^IOYv--#U8d0)l6=XQ@==}N_6x1ITeQW8L%RQKv-0ml6H?vTwY@&>Nq%a5ZN?hA
zc~?_9KDJB7@j6ek3l~l4`D9@#oxHef%aM!1>ZO*V!g^I#o^pL^H@W0o`>;7=rkU2J
zDycNXYio@Xs`|4!Co6YtRgzNBz7x#x@2gKpSN^pvJ7>G_$}e>b7ftB*O8hSBIq70R
z%9pbq>}yTkG9T^ox2drF71I5^VwuMB)hjI)O$_0&<@aeY^s&A-Bf3bpY-!*
z%fqavty-zNIapJD;wv#;rnWnu2uculhz!Ujq!O~)7TDAs1octJ0-)x?*Zfc
zpI2|k|IAoBXB%&N^uCj9{-#AYKO0#7KG1c_RoThXh?#HaT8`V#dFM%l1<8oTA6p;2
zGvh$s)fq;yNy4QIW1V}ZwN6RDE>pL)^?~J?S=H{>lPB1pe;n%(@L|`ySJ|x}V)iFr
z)z_WfyZ*qR!sv(lG>@N@yjJ%lKCMbgll^sApx>EL);aHFUtI}qs$BDQ$LS2tn2-~a
z5i$?He_!=d;qJlJjGr_Wjh@*YWl2_A+7?r@{>1lHhTCgG8=TE$q%J*)*v0Akvo7V!
zm*uO=ohROrS}i@*rcP;j5a+=Mmjx{n)}BA@dob*Ezw@mL+t{u@Da$enZhPu$$gf`U
zB{6X0V~eFKtC{#^SJd%6yzo_ImXySCEs5g(GXZ_!&*MUO^+!4X-gd`I?uy3W*LoJp
zN}Dx;8xL(iRq1@!fBB^ue`gf%>NrTsnf=l1II?A;d8nnRuE>lJKbg0B&W~E>cWa7W
z<=2%Ovy}^$=e-S>_R`;$QRIl;n{~z>{-=G9>Q$I3%SdYNKdL6LI)JBU
zdGg}^h08rp@EH0`5N~aiUD5j8$;d)^Y50V;NzTlD{A`O;4{BAiFZG;o(%0Uqx+_ff
zh`Wx#{fg2Rdciy@^1UAZij7aozAm4;u6>8n($z0a-kdt}-sh?(o77r$9>*1F4*sT7
zCN9$2^myX^wJwe)AFVMsX!$a*_9k1E)R|384g6KT|Kh4ckH^TEJ6~G8OQ3e8iOC6x
z!gb0oP<T|ao^x)m@rmX3TfL1Ry)qc1x-zgy*q1inbjvP+ncZ5Jbndj_`BlsE6pXpE~W2Sa(7l4yUEeNnOpXIIn`#)
z@Nm*#>1*q`6l}R%#KJ1ew2M}a6zJP%A8=!RI$D;?LUo^!{2_DNih5+_2lsm
z<+V|LFCMQ=)Y6=^Jb7dE(aF;NwzHN*?|)eQ#cu1V!&UB*t0&%jCy^X;X<@Rf$+`CP
z%FC56Uz#)BrPMM$-s@P`XBop^QXACYS+1FDEnXad?$m#VilE9lHOrMYU3#+e)ch4I
zr#eR%Y5XWUk4boeKWcHq@Ysdr%Tl5{d<32P_f%78eU#%-^%2F;1}rVE^oFc
z1)1g(53aB|SIetEgX7?$gGFHqpEPHmu=%8Aa
zEZfNYCd0w;cygEjishSrUGbgxHmpV3df|#05B@xs`>Ie^`Dn@ncbl%Y4eiVCS}xnb
z@=L1P^)CNIU%R#yO-9DoKd-oHs};l_xWZH)!z7aLgyb}QS?zOn(X?BY
zuPm0t`I|gqJf^+ovnQ)<<)ax3LiQwIS~#Uy!c?p9+N?c~P5$r{Wkq_#*o8SCduC${+V+1G(~sKjQA3NZb|CWgiD3D*G6rtzsFGZY^7^!
z@aubPZ?C(~SI>2}SBmRlD)*g_;koConNFAdoX%3*_jM`b&rR7%GuJcc9p77EwsZ5x
zx2O0f8Cv}M9D8*0gx9;Tn;yld{!<
zt*Z=Vj`3Bjp7^<|^PTF(6b)Nmzn#alHmzh^&eEh6B$;G;c&+cVT$|#6C37uSIxjA$
zSfw&IUPbWWYGxxIIgS@u8~lv4LW++DsZM)1-O`g?d97{xGzXj2CEr#(@0{@KWAK@}
zkY887sISm?*!ZMuu?^#mF3uzKjs!>inJL?=#w2R(Vc+T&(JcL|Aj{1%@x2d&z=HKV#^Ty3{hN?Z(5%Y9?1({?ma+40Yx`ThVy>@P^}iW#w;NmhG7TVX3-phD49S
zzhkp{H=de*Xj)!ldsbKS_n4q$rx+d&nP4^P=}Jo`f1e=tCq%&P#fGXrZS$QO4Rijw
zy4^^99ptk+WyOs;x6L|5<}>B^1FtPAJ?CDPpr&d3^U5WS9MPq_~811I=0=My4&F3$|dne_EqZ~Kb@MlcZHN}fx(HNFApx*=Xm_7$Nv2--z=6b
zPA#bVzT}j!-B#{DYhTWq+NPz+_VnQEfPh2A0Vno6DOt%}W^(vC+f0wuO3zlEn%x>(
zcx&~EEvJoDyDh;bZqz5;;AwWRqmK3*o_Bw}=v)(vx3N4M+kRc;eDL~csZ&CtO=#@n
z<5}0H$w;mESREdd=4?DOb8D8z#!CxR)=oB7dg+#VB$(r9KupY~XEWV0__F!$&N5G$
zIm_6!JCyzTj-~v8&w8G9i!Jk>^X1Vj|MgL6h2FbO)`V}7;groRo|RVUR(!cjN9OUq
zDKpReX_^OAE;_Q4En~?!t4p<-GtI2+wk+&;>2rRqtW`jwN<`$|S0(dSq?>$rQnKW6
zv3g0idy&Jz)rNOP-ycoV*=ptAzcgJdBP&+)0X$()f^QWbN|x>#)fM!@YJ>F7130^hwkB
zWr*iIKQ>m&%vIL2I8Po}clneWyR4_6oU8pQBv;N+*g?G2N
zz7Ep7Wpvd{>&YwYd8{6rl3V3_L&NlHStDZfuPt3PS>3@u`1sO@o+l5p_SD;7TK<`-
zU~jfrkj_HEp6yW^B`d88wg#!5G9Zus7U#
z)-UjrRjrw$X;1zYqvj~h11Hwy9};JK?AY+1p_E}=n^F0LFKb^NyPPI+_ffaE!ef*F
z3TF7uP#z+N>R?NwUR~$t|~<)
zY?HG0d9=KEhT}V4hXq!}L5uTy+p8`#zN;%)_Q{zmTe!vK-6Z)!kEGHbnUW>RpV>s7
zoY(eMeqwi3S>nFR?90t}f}j3<)VcU!`#rfW$A34rXNBah;dpUXS-b61`ibBDzk+W+
znQq%_mhy8Zzu%%+5_?qS_iW|4D7^E%hqTf{&vG^EON(W%v_;6wD!QU|=h2dL97~vw
z7Y0tZ)zIzK+*EqvrGuDa{@u&EC-3~5xuka^r^&YcuRgyH*(IcGmRHYJEF;zFmp5zP
zA5&&A9|>Ql=LYgwC2KqUELTjK%=jy03aM2T$y&M@T_wIS4_L@tGE-{
zMV@U>zpuKzF?e(Ns`E$YN44+F@MH_OT=A%;X8H20@DnR$uXB%T>YVX8z{A)-?A})C
zQp+XB+S(q^N}juRZ@qjK=iwm1i4%W@h-v?Mxzkr*(t(vL%75lK{$BoNx$@gdGlbQH
zmMxfAwqI1GcbmiEy}}Qt7%Wo>>)o?@($0rJ|71+9+4-IMaIm_h!{b$RuC!Esd)OX$
zmX)`l_|GckIUy?^PQMdU#1mpPS^I=Rk(SX-nJY({46?*xq_|x2KXY~N6xIB)Lgi<4
zSE|5?9jh+sFO61LTD?CeRB?)m?_CSiAeZy(Yco#GJsMVe_u%Vj*Phd}v=-|`tnC!u
zxN6ezAJ<({)Kd18MtSV+x-vVb8z>y=`Vd3TP!%c@ow#kWzS7^eqGRJT~@bc;fWP5&axOCI@vc>
z>vYIx|M25cF-zi(ewowvC$x2j#q+gk+K-lmA3Sx%V$qadMa{Uc8nertn?r)7V+ky^Crn{DPHC%dUKOFxVKIa5%%V4G#!)EK+W@<-D(es=yj<@=R0
z=aZ)Sqp3|#`;Bcg?)Pc&{#A$bf>=7);
z&3~uc|NX~$H@CaZv%YB8gj=k9u_lAB;mXcaA48Mtr_Y*Z9J6fcjOc4iRZ>DjZ3_K@
z?!I73e|VT{e&Ox;UMsaHEa=*pcl+{0r>Yy=+b*SxTFu=o?;QET?51J(lIPi6S0(qJ
zlyCfT>G?DEYqOQpbS^vBENWw!tFlC$<-+l2Y!m-xMI2k_wZT;0V)@F$a+&*&xO!{o
zF=jaTt-iK8|E5CT*@LUCKTB(hy6($}DUWk?>FW6W$@@)K#BJTsiGOZP`7ZKfK5t;H
z_Y1${LLm$08Hdi?tm+lL)KJL7&2ibO`@7F&N^aUJv-bBc386OobbGH^Hv|P%E%?u{
zc>dDJt+f~Vmj>POX^rSUwsP*~(Ekiif38ZmFxkZ@^ZxfHP2s})>#}?GD}Mz|I~?8PY3_b)(bWA`ipMT?qNbRQNjZ0@=TRr`#S9DDYPw#A#vp<$?PPlA-Ma0fYHcL=ZMyl*X
zmipI)JX`nI#C=(*_CzadjZxx;%rj+n?p_P|>Wr3)+>SK!NKW>zpXMTW0DHLw`9pYykJbB{T@H&fC&PsW%VNLU7_53@cx_ux
zM`~JB@3b`=M1_;K__R5=s(N^=IL)=ixlEwTC#mVttQ66x$!FTrdY&yd;*at-34WUL
z+hy0JOIPG7zAiCmzBXT5d|P`_vFDr+wkJW-6a6Q-?D`PvEqRu0)!!vSwafZEg}-))
zZFb9AxMRt0$K`Ks%13k-+fB(^6<4|B^Q`%sQ)&~%zjHBno&S8R-*Rupx0Jt$WhN~%
z-XFE_v6edZdG@t_)4dtrTz=Op$N1S6WQFdMcydjC*1awBlB;IfcJZ$S+E4tH
zeb>&v&#z6c{JQjwKy8}4>)!>W|s>1DOyEe?%T$j|%QBb*>!#Ff>=W33-T5A;3{qJ7cw*2X`
zoxGBZuI@PMb;GLbVFKn?Ji=fk-)Jz_yf&-U~lN^2X_XeK)tmhsW6sXN(=I$Ii*{-f(`Vg#x7QsBFI+vM7Yg-W{H@m8mYHjdw2D--J`1zK>e<#=HIKvHe85R;Lb`R?(*AAerSo_0==$TCmO
zlFWN_`}^_dp~n{T74EIKnr+n0?@!C$Bki$ivwc^N`=71yb3^ha
zBK7}l5&5@1^o#hGrdK6?H%yZ(Yi{g(9TT(9bjzEYt6o2zp`6ovG;71w`A)G}wdX!r
z9@=)yraQRjw~-z?~4_D
z)w{xJ?e}ALTX}ZP-68*4{PTM4T)&sQPTimDmcQIKCI8%($eQZOU!ULja_#Ed2FnR`
zrBS|FH|izUTbKvUTUT$DIrDs&{oJSnj-~3aFTJS}{?T-^zDH`QdPnYI8Ph^Gx35cd
zYO`INmUUFTYEM+}NU-G%%dOM9dOB~h>7qlIU2IarN`kUGszS@IZN9Xz*mKrar&%wY
zkA~Fxrd^ZxvLZUDY|Ss@u$2c(6tA!NHSN~lvj%r}z7Jh-He5^j*4eLW=6cnaByW6Q
zv0{0OzfJqh=xdYD0MkWR
zRR)njS9Gi(*5wtIAQBXGfzee}mq8@Z(}CMnRfJ&+L_~yPOQ0(gm!@V0qsF2xhL^j7
zC(q054N~`dXv1MfR$rh=qIpRHwKbgKzlc~9XZFjF+?zfKmo9nEPKM?B+wfwm{{cu!I
z{mqN*1sqYYmcLJ&KCw4e+unFx&(lp>r?#JtEQ~++_v6p2&9zKDKbt?Vt2TU*;pAzW
zQL<)+X>{mot$(G;+1s-JGw6nYUj1}>QeLl*&~mvcr<1~*_}8ZP3*J~)Z1k_xbx-2*
z;{}J$#h+{SE5BhmwQp10*>K%CCKc*i3(VuJH$9|7qM}Ml&XLZw6%k7R>y6=2Z
zIAPPoS&c*F8O*NQ*;
zMKw|s^3+|@opIe;0GI~uP2ofr3{hWcf7{FrG}5|n*zd*Hs+ufF^ie!HyP_oLM7b9&u9ms5W9*SvE7x=y-O
z?bZ53{|$TB?4BE3aqGuM#f|f;I`^cmkpG!cZ}n`m=dAUqe22bGdRM~#=&a*^hNmn4
zyxLvS_jmu(jq<(8&nBD3OnjrCsrPL5>+-eN(*C>>yYg=KnzKKz>Rd{jujTYCb=uy!
zppwJa%iOuxE__;7b&daa%GYIo*E!#tzllGquQ4^|>+;Ua<$*Ex
zZ>9YEs(wr5-^ax_eztG3s^6;qy;UpDZTU3O(?8$;eeC(%{(G<7QTFZWA*CGKYahCQ
zTjKnqwFuPYGT**d?vUc!C#Cmq2WmX%a(u*beQ!~8|61u4zxJ?#gg;Eyc<=q6fir@+
z>xr>j=5Mar*0;+_k00Z+du#IJT;0`^&w4I@3wWcSY4_~f>PMWV5>57N9dp;lL@x+Q
zVoiP47`9MiwTkzgCGXCj|KX``Z7JWYT+#J&|I^KNrM`l^U&N6mwsLM3=JuA74d9z#Q&Lw9V>`i7ad)9NA5t2kEw5Ro4F7}+2U~Q5%dzJ=B
zR8@pw=OR#B@1m#YEQXkiv%E9}b}m^osX?sEOM@|E$s!N~oL(9<7EPML?FmXasF(wq
zJRC##aVe7
zXPI|EXl>TxX_HOvT%1+L-3L~8F+toUZL-PCMTa0N799YGlCi__w4Tcu3)n$H=a#{E
zbIFpkA{^j=Vk~x5m0ZBo<#TZsLzJemTLxpslCz*nF0Cs;S5*=e5KF*yB}0^^#uBEB
zp58u=uBsvppzOocrLoLlQI`e-1Z%P=k*P*n+43DN
             
-              7 min read
+              8 min read
             
           
         
diff --git a/HEAD/blog/category/metrology/index.html b/HEAD/blog/category/metrology/index.html
index fc435b6f..737e239e 100644
--- a/HEAD/blog/category/metrology/index.html
+++ b/HEAD/blog/category/metrology/index.html
@@ -2375,7 +2375,7 @@ You're not viewing the latest version.
           
           
  • 
             
-              7 min read
+              8 min read
             
           
    • 
         
diff --git a/HEAD/blog/index.html b/HEAD/blog/index.html
index 74615f1d..dacd0c3b 100644
--- a/HEAD/blog/index.html
+++ b/HEAD/blog/index.html
@@ -2361,7 +2361,7 @@ You're not viewing the latest version.
           
           
  • 
             
-              7 min read
+              8 min read
             
           
    • 
         
diff --git a/HEAD/feed_json_updated.json b/HEAD/feed_json_updated.json
index 6dbad2ba..9764ce38 100644
--- a/HEAD/feed_json_updated.json
+++ b/HEAD/feed_json_updated.json
@@ -1 +1 @@
-{"version": "https://jsonfeed.org/version/1", "title": "mp-units", "home_page_url": "https://mpusz.github.io/mp-units/HEAD/", "feed_url": "https://mpusz.github.io/mp-units/HEAD/feed_json_updated.json", "description": "The quantities and units library for C++", "icon": null, "authors": [{"name": "mp-units Team"}], "language": "en", "items": [{"id": "https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/", "title": "Introducing absolute quantities", "content_html": "
    Introducing absolute quantities
    \n
    This post introduces a new abstraction called an absolute quantity. It complements affine\nspace abstractions (point and delta) and will most probably be a new default in the library\nwhen we release V3.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/introducing-absolute-quantities.png", "date_modified": "2025-06-17T08:25:08+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/", "title": "Bringing Quantity-Safety To The Next Level", "content_html": "
    Bringing Quantity-Safety To The Next Level
    \n
    All quantities and units libraries need to be unit-safe. Most of the libraries on the market do\nthis correctly. Some of them are also dimension-safe, which adds another level of protection for\ntheir users.
    \n
    mp-units is probably the only library on the market that additionally is quantity-safe. This\ngives a new quality and possibilities. I've described the major idea behind it, implementation\ndetails, and benefits to the users in the series of posts about the International System of Quantities.
    \n
    However, this is only the beginning. We've always planned more and worked on the extensions in our\nfree time. In this post, I will describe:
    \n
      \n
    • What a quantity character is?
      • \n
    • The importance of using proper representation types for the quantities.
      • \n
    • The power of providing character-specific operations for the quantities.
      • \n
    • Discuss implementation challenges and possible solutions.
      • \n
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/bringing-quantity-safety-to-the-next-level.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/", "title": "International System of Quantities (ISQ): Part 4 - Implementing ISQ", "content_html": "
    International System of Quantities (ISQ): Part 4 - Implementing ISQ
    \n
    Up until now, we have introduced the International System of Quantities and described how we can\nmodel its main aspects. This article will present how to implement those models in a programming\nlanguage, and we will point out some of the first issues that stand in our way.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-4-implemeting-isq.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/", "title": "International System of Quantities (ISQ): Part 6 - Challenges", "content_html": "
    International System of Quantities (ISQ): Part 6 - Challenges
    \n
    This article might be the last one from our series. This time, we will discuss the challenges and\nissues with modeling of the ISQ in software.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-6-challenges.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/", "title": "Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting", "content_html": "
    Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting
    \n
    The Wroc\u0142aw 2024 meeting was another efficient step in the standardization of this library.\nWe've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.\nWe've also introduced std::fixed_string to LEWG for C++26.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/wroc\u0142aw-2024-report.png", "date_modified": "2024-11-29T12:45:06+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/", "title": "International System of Quantities (ISQ): Part 1 - Introduction", "content_html": "
    International System of Quantities (ISQ): Part 1 - Introduction
    \n
    This post starts a series of articles about the International System of Quantities (ISQ).\nIn this series, we will describe:
    \n
      \n
    • What is ISQ?
      • \n
    • Which engineering problems does ISQ help to solve and how?
      • \n
    • How to model and implement it in the programming language?
      • \n
    • What is missing in the ISQ, and why is that a problem?
      • \n
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-1-introduction.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/", "title": "International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used", "content_html": "
    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used
    \n
    This article is the next one in our series about the ISQ. After introducing the basic terms and\nsystems, this article will talk about the issues we face when we base the quantities and units\nlibrary on just units or dimensions.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-2-problems-when-isq-is-not-used.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/", "title": "International System of Quantities (ISQ): Part 3 - Modeling ISQ", "content_html": "
    International System of Quantities (ISQ): Part 3 - Modeling ISQ
    \n
    The physical units libraries on the market typically only focus on modeling one or more systems\nof units. However, as we have learned, this is not the only system kind to model. Another,\nand maybe even more important, is a system of quantities. The most important example here is\nthe International System of Quantities (ISQ) defined by ISO/IEC 80000.
    \n
    This article continues our series about the International System of Quantities. This time, we will\nlearn about the main ideas behind the ISQ and describe how it can be modelled in a programming\nlanguage.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-3-modeling-isq.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/", "title": "International System of Quantities (ISQ): Part 5 - Benefits", "content_html": "
    International System of Quantities (ISQ): Part 5 - Benefits
    \n
    In the previous articles, we introduced the International System of Quantities, described how we\ncan model and implement it in a programming language, and presented the issues of software that\ndoes not use such abstraction to implement a units library.
    \n
    Some of the issues raised in Part 2 of our series\nwere addressed in Part 3 already. This article will present\nhow our ISQ model elegantly addresses the remaining problems.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-5-benefits.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/", "title": "mp-units 2.4.0 released!", "content_html": "
    mp-units 2.4.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    This release was unexpected. We planned a significant new feature to happen next, but while\npreparing for it, and also while writing API Reference documentation, we made so many vital fixes\nand improvements that we decided that they deserve a dedicated release first.
    \n
    This post describes the most significant improvements while a much longer list of the changes\nintroduced by the new version can be found in our Release Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.4.0-released.png", "date_modified": "2024-11-05T18:46:13+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/", "title": "mp-units 2.3.0 released!", "content_html": "
    mp-units 2.3.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    This release fine-tunes many key features of the library. This post describes the most interesting\nimprovements, while a much longer list of the changes introduced by the new version can be found in\nour Release Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.3.0-released.png", "date_modified": "2024-09-30T17:11:10+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/", "title": "What's new in mp-units 2.0?", "content_html": "
    What's new in mp-units 2.0?
    \n
    After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from\nGitHub and\nConan.
    \n
    The list of the most significant changes introduced by the new version can be found in our\nRelease Notes. We will also describe some of them in this post.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.0.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/", "title": "mp-units 2.1.0 released!", "content_html": "
    mp-units 2.1.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    The list of the most significant changes introduced by the new version can be found in our\nRelease Notes. We will also describe the most important of them\nin this post.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.1.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/", "title": "mp-units 2.2.0 released!", "content_html": "
    mp-units 2.2.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    Among other features, this release provides long-awaited support for C++20 modules, redesigns and\nenhances text output formatting, and greatly simplifies quantity point usage. This post describes\nthose and a few other smaller interesting improvements, while a much longer list of the most\nsignificant changes introduced by the new version can be found in our\nRelease Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.2.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/", "title": "Report from the Kona 2023 ISO C++ Committee meeting", "content_html": "
    Report from the Kona 2023 ISO C++ Committee meeting
    \n
    Several groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units\nproposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential\nstandardization of such a library and encouraged further work. The authors also got valuable\ninitial feedback that highly influenced the design of the V2 version of the mp-units library.
    \n
    In the following years, we scoped on getting more feedback from the production and design. This\nresulted in version 2 of the mp-units library that resolved many issues the users and Committee\nmembers raised. The features and interfaces of this version are close to being the best we can get\nwith the current version of the C++ language standard.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/kona-2023-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/", "title": "Report from the St. Louis 2024 ISO C++ Committee meeting", "content_html": "
    Report from the St. Louis 2024 ISO C++ Committee meeting
    \n
    We made significant progress in the standardization of this library during the ISO C++ Committee\nmeeting in St. Louis.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/st.louis-2024-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/", "title": "Report from the Tokyo 2024 ISO C++ Committee meeting", "content_html": "
    Report from the Tokyo 2024 ISO C++ Committee meeting
    \n
    The Tokyo 2024 meeting was a very important step in the standardization of this library. Several\nWG21 groups reviewed proposals, and the feedback was really good.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/tokyo-2024-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}]}
\ No newline at end of file
+{"version": "https://jsonfeed.org/version/1", "title": "mp-units", "home_page_url": "https://mpusz.github.io/mp-units/HEAD/", "feed_url": "https://mpusz.github.io/mp-units/HEAD/feed_json_updated.json", "description": "The quantities and units library for C++", "icon": null, "authors": [{"name": "mp-units Team"}], "language": "en", "items": [{"id": "https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/", "title": "Introducing absolute quantities", "content_html": "
    Introducing absolute quantities
    \n
    This post introduces a new abstraction called an absolute quantity. It complements affine\nspace abstractions (point and delta) and will most probably be a new default in the library\nwhen we release V3.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/introducing-absolute-quantities.png", "date_modified": "2025-06-17T14:16:55+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/", "title": "Bringing Quantity-Safety To The Next Level", "content_html": "
    Bringing Quantity-Safety To The Next Level
    \n
    All quantities and units libraries need to be unit-safe. Most of the libraries on the market do\nthis correctly. Some of them are also dimension-safe, which adds another level of protection for\ntheir users.
    \n
    mp-units is probably the only library on the market that additionally is quantity-safe. This\ngives a new quality and possibilities. I've described the major idea behind it, implementation\ndetails, and benefits to the users in the series of posts about the International System of Quantities.
    \n
    However, this is only the beginning. We've always planned more and worked on the extensions in our\nfree time. In this post, I will describe:
    \n
      \n
    • What a quantity character is?
      • \n
    • The importance of using proper representation types for the quantities.
      • \n
    • The power of providing character-specific operations for the quantities.
      • \n
    • Discuss implementation challenges and possible solutions.
      • \n
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/bringing-quantity-safety-to-the-next-level.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/", "title": "International System of Quantities (ISQ): Part 4 - Implementing ISQ", "content_html": "
    International System of Quantities (ISQ): Part 4 - Implementing ISQ
    \n
    Up until now, we have introduced the International System of Quantities and described how we can\nmodel its main aspects. This article will present how to implement those models in a programming\nlanguage, and we will point out some of the first issues that stand in our way.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-4-implemeting-isq.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/", "title": "International System of Quantities (ISQ): Part 6 - Challenges", "content_html": "
    International System of Quantities (ISQ): Part 6 - Challenges
    \n
    This article might be the last one from our series. This time, we will discuss the challenges and\nissues with modeling of the ISQ in software.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-6-challenges.png", "date_modified": "2025-02-11T16:26:19+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/", "title": "Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting", "content_html": "
    Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting
    \n
    The Wroc\u0142aw 2024 meeting was another efficient step in the standardization of this library.\nWe've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.\nWe've also introduced std::fixed_string to LEWG for C++26.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/wroc\u0142aw-2024-report.png", "date_modified": "2024-11-29T12:45:06+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/", "title": "International System of Quantities (ISQ): Part 1 - Introduction", "content_html": "
    International System of Quantities (ISQ): Part 1 - Introduction
    \n
    This post starts a series of articles about the International System of Quantities (ISQ).\nIn this series, we will describe:
    \n
      \n
    • What is ISQ?
      • \n
    • Which engineering problems does ISQ help to solve and how?
      • \n
    • How to model and implement it in the programming language?
      • \n
    • What is missing in the ISQ, and why is that a problem?
      • \n
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-1-introduction.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/", "title": "International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used", "content_html": "
    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used
    \n
    This article is the next one in our series about the ISQ. After introducing the basic terms and\nsystems, this article will talk about the issues we face when we base the quantities and units\nlibrary on just units or dimensions.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-2-problems-when-isq-is-not-used.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/", "title": "International System of Quantities (ISQ): Part 3 - Modeling ISQ", "content_html": "
    International System of Quantities (ISQ): Part 3 - Modeling ISQ
    \n
    The physical units libraries on the market typically only focus on modeling one or more systems\nof units. However, as we have learned, this is not the only system kind to model. Another,\nand maybe even more important, is a system of quantities. The most important example here is\nthe International System of Quantities (ISQ) defined by ISO/IEC 80000.
    \n
    This article continues our series about the International System of Quantities. This time, we will\nlearn about the main ideas behind the ISQ and describe how it can be modelled in a programming\nlanguage.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-3-modeling-isq.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/", "title": "International System of Quantities (ISQ): Part 5 - Benefits", "content_html": "
    International System of Quantities (ISQ): Part 5 - Benefits
    \n
    In the previous articles, we introduced the International System of Quantities, described how we\ncan model and implement it in a programming language, and presented the issues of software that\ndoes not use such abstraction to implement a units library.
    \n
    Some of the issues raised in Part 2 of our series\nwere addressed in Part 3 already. This article will present\nhow our ISQ model elegantly addresses the remaining problems.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/isq-part-5-benefits.png", "date_modified": "2024-11-11T22:37:29+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Metrology"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/", "title": "mp-units 2.4.0 released!", "content_html": "
    mp-units 2.4.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    This release was unexpected. We planned a significant new feature to happen next, but while\npreparing for it, and also while writing API Reference documentation, we made so many vital fixes\nand improvements that we decided that they deserve a dedicated release first.
    \n
    This post describes the most significant improvements while a much longer list of the changes\nintroduced by the new version can be found in our Release Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.4.0-released.png", "date_modified": "2024-11-05T18:46:13+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/", "title": "mp-units 2.3.0 released!", "content_html": "
    mp-units 2.3.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    This release fine-tunes many key features of the library. This post describes the most interesting\nimprovements, while a much longer list of the changes introduced by the new version can be found in\nour Release Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.3.0-released.png", "date_modified": "2024-09-30T17:11:10+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/", "title": "What's new in mp-units 2.0?", "content_html": "
    What's new in mp-units 2.0?
    \n
    After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from\nGitHub and\nConan.
    \n
    The list of the most significant changes introduced by the new version can be found in our\nRelease Notes. We will also describe some of them in this post.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.0.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/", "title": "mp-units 2.1.0 released!", "content_html": "
    mp-units 2.1.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    The list of the most significant changes introduced by the new version can be found in our\nRelease Notes. We will also describe the most important of them\nin this post.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.1.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/", "title": "mp-units 2.2.0 released!", "content_html": "
    mp-units 2.2.0 released!
    \n
    A new product version can be obtained from\nGitHub and\nConan.
    \n
    Among other features, this release provides long-awaited support for C++20 modules, redesigns and\nenhances text output formatting, and greatly simplifies quantity point usage. This post describes\nthose and a few other smaller interesting improvements, while a much longer list of the most\nsignificant changes introduced by the new version can be found in our\nRelease Notes.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/2.2.0-released.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["Releases"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/", "title": "Report from the Kona 2023 ISO C++ Committee meeting", "content_html": "
    Report from the Kona 2023 ISO C++ Committee meeting
    \n
    Several groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units\nproposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential\nstandardization of such a library and encouraged further work. The authors also got valuable\ninitial feedback that highly influenced the design of the V2 version of the mp-units library.
    \n
    In the following years, we scoped on getting more feedback from the production and design. This\nresulted in version 2 of the mp-units library that resolved many issues the users and Committee\nmembers raised. The features and interfaces of this version are close to being the best we can get\nwith the current version of the C++ language standard.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/kona-2023-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/", "title": "Report from the St. Louis 2024 ISO C++ Committee meeting", "content_html": "
    Report from the St. Louis 2024 ISO C++ Committee meeting
    \n
    We made significant progress in the standardization of this library during the ISO C++ Committee\nmeeting in St. Louis.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/st.louis-2024-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}, {"id": "https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/", "url": "https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/", "title": "Report from the Tokyo 2024 ISO C++ Committee meeting", "content_html": "
    Report from the Tokyo 2024 ISO C++ Committee meeting
    \n
    The Tokyo 2024 meeting was a very important step in the standardization of this library. Several\nWG21 groups reviewed proposals, and the feedback was really good.
    ", "image": "https://mpusz.github.io/mp-units/HEADassets/images/social/blog/posts/tokyo-2024-report.png", "date_modified": "2024-09-30T12:47:28+00:00", "authors": [{"name": "Mateusz Pusz"}], "tags": ["WG21 Updates"]}]}
\ No newline at end of file
diff --git a/HEAD/feed_rss_created.xml b/HEAD/feed_rss_created.xml
index a66c5ab3..845329dd 100644
--- a/HEAD/feed_rss_created.xml
+++ b/HEAD/feed_rss_created.xml
@@ -1 +1 @@
- mp-unitsThe quantities and units library for C++https://mpusz.github.io/mp-units/HEAD/mp-units Teamhttps://github.com/mpusz/mp-unitsen Tue, 17 Jun 2025 08:29:14 -0000 Tue, 17 Jun 2025 08:29:14 -0000 1440 MkDocs RSS plugin - v1.17.3  None mp-unitshttps://mpusz.github.io/mp-units/HEAD/   Introducing absolute quantities Mateusz Pusz Metrology <h1>Introducing absolute quantities</h1><p>This post introduces a new abstraction called an absolute quantity. It complements affinespace abstractions (point and delta) and will most probably be a new default in the librarywhen we release V3.</p>https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/ Mon, 16 Jun 2025 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/    Bringing Quantity-Safety To The Next Level Mateusz Pusz Metrology <h1>Bringing Quantity-Safety To The Next Level</h1><p>All quantities and units libraries need to be unit-safe. Most of the libraries on the market dothis correctly. Some of them are also dimension-safe, which adds another level of protection fortheir users.</p><p><strong>mp-units</strong> is probably the only library on the market that additionally is quantity-safe. Thisgives a new quality and possibilities. I've described the major idea behind it, implementationdetails, and benefits to the users in the <a href="isq-part-5-benefits.md">series of posts about the International System of Quantities</a>.</p><p>However, this is only the beginning. We've always planned more and worked on the extensions in ourfree time. In this post, I will describe:</p><ul><li>What a quantity character is?</li><li>The importance of using proper representation types for the quantities.</li><li>The power of providing character-specific operations for the quantities.</li><li>Discuss implementation challenges and possible solutions.</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/ Wed, 15 Jan 2025 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/    Report from the Wrocław 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Wrocław 2024 ISO C++ Committee meeting</h1><p>The Wrocław 2024 meeting was another efficient step in the standardization of this library.We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.We've also introduced <code>std::fixed_string</code> to LEWG for C++26.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/ Mon, 25 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/    International System of Quantities (ISQ): Part 6 - Challenges Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 6 - Challenges</h1><p>This article might be the last one from our series. This time, we will discuss the challenges andissues with modeling of the ISQ in software.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/ Mon, 11 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/    mp-units 2.4.0 released! Mateusz Pusz Releases <h1>mp-units 2.4.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.4.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.4.0">Conan</a>.</strong></p><p>This release was unexpected. We planned a significant new feature to happen next, but whilepreparing for it, and also while writing API Reference documentation, we made so many vital fixesand improvements that we decided that they deserve a dedicated release first.</p><p>This post describes the most significant improvements while a much longer list of the changesintroduced by the new version can be found in our <a href="../../release_notes.md#2.4.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/ Tue, 05 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/    International System of Quantities (ISQ): Part 5 - Benefits Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 5 - Benefits</h1><p>In the previous articles, we introduced the International System of Quantities, described how wecan model and implement it in a programming language, and presented the issues of software thatdoes not use such abstraction to implement a units library.</p><p>Some of the issues raised in <a href="isq-part-2-problems-when-isq-is-not-used.md">Part 2</a> of our serieswere addressed in <a href="isq-part-3-modeling-isq.md">Part 3</a> already. This article will presenthow our ISQ model elegantly addresses the remaining problems.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/ Mon, 04 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/    International System of Quantities (ISQ): Part 4 - Implementing ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 4 - Implementing ISQ</h1><p>Up until now, we have introduced the International System of Quantities and described how we canmodel its main aspects. This article will present how to implement those models in a programminglanguage, and we will point out some of the first issues that stand in our way.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/ Mon, 28 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/    International System of Quantities (ISQ): Part 3 - Modeling ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 3 - Modeling ISQ</h1><p>The physical units libraries on the market typically only focus on modeling one or more systemsof units. However, as we have learned, this is not the only system kind to model. Another,and maybe even more important, is a system of quantities. The most important example here isthe International System of Quantities (ISQ) defined by ISO/IEC 80000.</p><p>This article continues our series about the International System of Quantities. This time, we willlearn about the main ideas behind the ISQ and describe how it can be modelled in a programminglanguage.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/ Mon, 21 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used</h1><p>This article is the next one in our series about the ISQ. After introducing the basic terms andsystems, this article will talk about the issues we face when we base the quantities and unitslibrary on just units or dimensions.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/ Mon, 14 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/    International System of Quantities (ISQ): Part 1 - Introduction Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 1 - Introduction</h1><p>This post starts a series of articles about the International System of Quantities (ISQ).In this series, we will describe:</p><ul><li>What is ISQ?</li><li>Which engineering problems does ISQ help to solve and how?</li><li>How to model and implement it in the programming language?</li><li>What is missing in the ISQ, and why is that a problem?</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/ Mon, 07 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/    mp-units 2.3.0 released! Mateusz Pusz Releases <h1>mp-units 2.3.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.3.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.3.0">Conan</a>.</strong></p><p>This release fine-tunes many key features of the library. This post describes the most interestingimprovements, while a much longer list of the changes introduced by the new version can be found inour <a href="../../release_notes.md#2.3.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/ Fri, 27 Sep 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/    Report from the St. Louis 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the St. Louis 2024 ISO C++ Committee meeting</h1><p>We made significant progress in the standardization of this library during the ISO C++ Committeemeeting in St. Louis.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/ Tue, 02 Jul 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/    mp-units 2.2.0 released! Mateusz Pusz Releases <h1>mp-units 2.2.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.2.1">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.2.1">Conan</a>.</strong></p><p>Among other features, this release provides long-awaited support for C++20 modules, redesigns andenhances text output formatting, and greatly simplifies quantity point usage. This post describesthose and a few other smaller interesting improvements, while a much longer list of the mostsignificant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.2.1">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/ Fri, 14 Jun 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/    Report from the Tokyo 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Tokyo 2024 ISO C++ Committee meeting</h1><p>The Tokyo 2024 meeting was a very important step in the standardization of this library. SeveralWG21 groups reviewed proposals, and the feedback was really good.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/ Mon, 15 Apr 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/    mp-units 2.1.0 released! Mateusz Pusz Releases <h1>mp-units 2.1.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.1.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.1.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.1.0">Release Notes</a>. We will also describe the most important of themin this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/ Sat, 09 Dec 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/    Report from the Kona 2023 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Kona 2023 ISO C++ Committee meeting</h1><p><strong>Several groups in the ISO C++ Committee reviewed the <a href="https://wg21.link/p1935">P1935: A C++ Approach to Physical Units</a>proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potentialstandardization of such a library and encouraged further work. The authors also got valuableinitial feedback that highly influenced the design of the V2 version of the mp-units library.</strong></p><p>In the following years, we scoped on getting more feedback from the production and design. Thisresulted in version 2 of the <strong>mp-units</strong> library that resolved many issues the users and Committeemembers raised. The features and interfaces of this version are close to being the best we can getwith the current version of the C++ language standard.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/ Sun, 12 Nov 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/    What's new in mp-units 2.0? Mateusz Pusz Releases <h1>What's new in mp-units 2.0?</h1><p><strong>After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.0.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.0.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.0.0">Release Notes</a>. We will also describe some of them in this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/ Sun, 24 Sep 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/   
\ No newline at end of file
+ mp-unitsThe quantities and units library for C++https://mpusz.github.io/mp-units/HEAD/mp-units Teamhttps://github.com/mpusz/mp-unitsen Tue, 17 Jun 2025 14:21:04 -0000 Tue, 17 Jun 2025 14:21:04 -0000 1440 MkDocs RSS plugin - v1.17.3  None mp-unitshttps://mpusz.github.io/mp-units/HEAD/   Introducing absolute quantities Mateusz Pusz Metrology <h1>Introducing absolute quantities</h1><p>This post introduces a new abstraction called an absolute quantity. It complements affinespace abstractions (point and delta) and will most probably be a new default in the librarywhen we release V3.</p>https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/ Mon, 16 Jun 2025 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/    Bringing Quantity-Safety To The Next Level Mateusz Pusz Metrology <h1>Bringing Quantity-Safety To The Next Level</h1><p>All quantities and units libraries need to be unit-safe. Most of the libraries on the market dothis correctly. Some of them are also dimension-safe, which adds another level of protection fortheir users.</p><p><strong>mp-units</strong> is probably the only library on the market that additionally is quantity-safe. Thisgives a new quality and possibilities. I've described the major idea behind it, implementationdetails, and benefits to the users in the <a href="isq-part-5-benefits.md">series of posts about the International System of Quantities</a>.</p><p>However, this is only the beginning. We've always planned more and worked on the extensions in ourfree time. In this post, I will describe:</p><ul><li>What a quantity character is?</li><li>The importance of using proper representation types for the quantities.</li><li>The power of providing character-specific operations for the quantities.</li><li>Discuss implementation challenges and possible solutions.</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/ Wed, 15 Jan 2025 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/    Report from the Wrocław 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Wrocław 2024 ISO C++ Committee meeting</h1><p>The Wrocław 2024 meeting was another efficient step in the standardization of this library.We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.We've also introduced <code>std::fixed_string</code> to LEWG for C++26.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/ Mon, 25 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/    International System of Quantities (ISQ): Part 6 - Challenges Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 6 - Challenges</h1><p>This article might be the last one from our series. This time, we will discuss the challenges andissues with modeling of the ISQ in software.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/ Mon, 11 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/    mp-units 2.4.0 released! Mateusz Pusz Releases <h1>mp-units 2.4.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.4.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.4.0">Conan</a>.</strong></p><p>This release was unexpected. We planned a significant new feature to happen next, but whilepreparing for it, and also while writing API Reference documentation, we made so many vital fixesand improvements that we decided that they deserve a dedicated release first.</p><p>This post describes the most significant improvements while a much longer list of the changesintroduced by the new version can be found in our <a href="../../release_notes.md#2.4.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/ Tue, 05 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/    International System of Quantities (ISQ): Part 5 - Benefits Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 5 - Benefits</h1><p>In the previous articles, we introduced the International System of Quantities, described how wecan model and implement it in a programming language, and presented the issues of software thatdoes not use such abstraction to implement a units library.</p><p>Some of the issues raised in <a href="isq-part-2-problems-when-isq-is-not-used.md">Part 2</a> of our serieswere addressed in <a href="isq-part-3-modeling-isq.md">Part 3</a> already. This article will presenthow our ISQ model elegantly addresses the remaining problems.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/ Mon, 04 Nov 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/    International System of Quantities (ISQ): Part 4 - Implementing ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 4 - Implementing ISQ</h1><p>Up until now, we have introduced the International System of Quantities and described how we canmodel its main aspects. This article will present how to implement those models in a programminglanguage, and we will point out some of the first issues that stand in our way.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/ Mon, 28 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/    International System of Quantities (ISQ): Part 3 - Modeling ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 3 - Modeling ISQ</h1><p>The physical units libraries on the market typically only focus on modeling one or more systemsof units. However, as we have learned, this is not the only system kind to model. Another,and maybe even more important, is a system of quantities. The most important example here isthe International System of Quantities (ISQ) defined by ISO/IEC 80000.</p><p>This article continues our series about the International System of Quantities. This time, we willlearn about the main ideas behind the ISQ and describe how it can be modelled in a programminglanguage.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/ Mon, 21 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used</h1><p>This article is the next one in our series about the ISQ. After introducing the basic terms andsystems, this article will talk about the issues we face when we base the quantities and unitslibrary on just units or dimensions.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/ Mon, 14 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/    International System of Quantities (ISQ): Part 1 - Introduction Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 1 - Introduction</h1><p>This post starts a series of articles about the International System of Quantities (ISQ).In this series, we will describe:</p><ul><li>What is ISQ?</li><li>Which engineering problems does ISQ help to solve and how?</li><li>How to model and implement it in the programming language?</li><li>What is missing in the ISQ, and why is that a problem?</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/ Mon, 07 Oct 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/    mp-units 2.3.0 released! Mateusz Pusz Releases <h1>mp-units 2.3.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.3.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.3.0">Conan</a>.</strong></p><p>This release fine-tunes many key features of the library. This post describes the most interestingimprovements, while a much longer list of the changes introduced by the new version can be found inour <a href="../../release_notes.md#2.3.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/ Fri, 27 Sep 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/    Report from the St. Louis 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the St. Louis 2024 ISO C++ Committee meeting</h1><p>We made significant progress in the standardization of this library during the ISO C++ Committeemeeting in St. Louis.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/ Tue, 02 Jul 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/    mp-units 2.2.0 released! Mateusz Pusz Releases <h1>mp-units 2.2.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.2.1">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.2.1">Conan</a>.</strong></p><p>Among other features, this release provides long-awaited support for C++20 modules, redesigns andenhances text output formatting, and greatly simplifies quantity point usage. This post describesthose and a few other smaller interesting improvements, while a much longer list of the mostsignificant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.2.1">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/ Fri, 14 Jun 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/    Report from the Tokyo 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Tokyo 2024 ISO C++ Committee meeting</h1><p>The Tokyo 2024 meeting was a very important step in the standardization of this library. SeveralWG21 groups reviewed proposals, and the feedback was really good.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/ Mon, 15 Apr 2024 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/    mp-units 2.1.0 released! Mateusz Pusz Releases <h1>mp-units 2.1.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.1.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.1.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.1.0">Release Notes</a>. We will also describe the most important of themin this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/ Sat, 09 Dec 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/    Report from the Kona 2023 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Kona 2023 ISO C++ Committee meeting</h1><p><strong>Several groups in the ISO C++ Committee reviewed the <a href="https://wg21.link/p1935">P1935: A C++ Approach to Physical Units</a>proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potentialstandardization of such a library and encouraged further work. The authors also got valuableinitial feedback that highly influenced the design of the V2 version of the mp-units library.</strong></p><p>In the following years, we scoped on getting more feedback from the production and design. Thisresulted in version 2 of the <strong>mp-units</strong> library that resolved many issues the users and Committeemembers raised. The features and interfaces of this version are close to being the best we can getwith the current version of the C++ language standard.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/ Sun, 12 Nov 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/    What's new in mp-units 2.0? Mateusz Pusz Releases <h1>What's new in mp-units 2.0?</h1><p><strong>After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.0.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.0.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.0.0">Release Notes</a>. We will also describe some of them in this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/ Sun, 24 Sep 2023 00:00:00 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/   
\ No newline at end of file
diff --git a/HEAD/feed_rss_updated.xml b/HEAD/feed_rss_updated.xml
index 4d8b33cd..c3c64867 100644
--- a/HEAD/feed_rss_updated.xml
+++ b/HEAD/feed_rss_updated.xml
@@ -1 +1 @@
- mp-unitsThe quantities and units library for C++https://mpusz.github.io/mp-units/HEAD/mp-units Teamhttps://github.com/mpusz/mp-unitsen Tue, 17 Jun 2025 08:29:14 -0000 Tue, 17 Jun 2025 08:29:14 -0000 1440 MkDocs RSS plugin - v1.17.3  None mp-unitshttps://mpusz.github.io/mp-units/HEAD/   Introducing absolute quantities Mateusz Pusz Metrology <h1>Introducing absolute quantities</h1><p>This post introduces a new abstraction called an absolute quantity. It complements affinespace abstractions (point and delta) and will most probably be a new default in the librarywhen we release V3.</p>https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/ Tue, 17 Jun 2025 08:25:08 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/    Bringing Quantity-Safety To The Next Level Mateusz Pusz Metrology <h1>Bringing Quantity-Safety To The Next Level</h1><p>All quantities and units libraries need to be unit-safe. Most of the libraries on the market dothis correctly. Some of them are also dimension-safe, which adds another level of protection fortheir users.</p><p><strong>mp-units</strong> is probably the only library on the market that additionally is quantity-safe. Thisgives a new quality and possibilities. I've described the major idea behind it, implementationdetails, and benefits to the users in the <a href="isq-part-5-benefits.md">series of posts about the International System of Quantities</a>.</p><p>However, this is only the beginning. We've always planned more and worked on the extensions in ourfree time. In this post, I will describe:</p><ul><li>What a quantity character is?</li><li>The importance of using proper representation types for the quantities.</li><li>The power of providing character-specific operations for the quantities.</li><li>Discuss implementation challenges and possible solutions.</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/    International System of Quantities (ISQ): Part 4 - Implementing ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 4 - Implementing ISQ</h1><p>Up until now, we have introduced the International System of Quantities and described how we canmodel its main aspects. This article will present how to implement those models in a programminglanguage, and we will point out some of the first issues that stand in our way.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/    International System of Quantities (ISQ): Part 6 - Challenges Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 6 - Challenges</h1><p>This article might be the last one from our series. This time, we will discuss the challenges andissues with modeling of the ISQ in software.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/    Report from the Wrocław 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Wrocław 2024 ISO C++ Committee meeting</h1><p>The Wrocław 2024 meeting was another efficient step in the standardization of this library.We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.We've also introduced <code>std::fixed_string</code> to LEWG for C++26.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/ Fri, 29 Nov 2024 12:45:06 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/    International System of Quantities (ISQ): Part 1 - Introduction Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 1 - Introduction</h1><p>This post starts a series of articles about the International System of Quantities (ISQ).In this series, we will describe:</p><ul><li>What is ISQ?</li><li>Which engineering problems does ISQ help to solve and how?</li><li>How to model and implement it in the programming language?</li><li>What is missing in the ISQ, and why is that a problem?</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used</h1><p>This article is the next one in our series about the ISQ. After introducing the basic terms andsystems, this article will talk about the issues we face when we base the quantities and unitslibrary on just units or dimensions.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/    International System of Quantities (ISQ): Part 3 - Modeling ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 3 - Modeling ISQ</h1><p>The physical units libraries on the market typically only focus on modeling one or more systemsof units. However, as we have learned, this is not the only system kind to model. Another,and maybe even more important, is a system of quantities. The most important example here isthe International System of Quantities (ISQ) defined by ISO/IEC 80000.</p><p>This article continues our series about the International System of Quantities. This time, we willlearn about the main ideas behind the ISQ and describe how it can be modelled in a programminglanguage.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/    International System of Quantities (ISQ): Part 5 - Benefits Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 5 - Benefits</h1><p>In the previous articles, we introduced the International System of Quantities, described how wecan model and implement it in a programming language, and presented the issues of software thatdoes not use such abstraction to implement a units library.</p><p>Some of the issues raised in <a href="isq-part-2-problems-when-isq-is-not-used.md">Part 2</a> of our serieswere addressed in <a href="isq-part-3-modeling-isq.md">Part 3</a> already. This article will presenthow our ISQ model elegantly addresses the remaining problems.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/    mp-units 2.4.0 released! Mateusz Pusz Releases <h1>mp-units 2.4.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.4.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.4.0">Conan</a>.</strong></p><p>This release was unexpected. We planned a significant new feature to happen next, but whilepreparing for it, and also while writing API Reference documentation, we made so many vital fixesand improvements that we decided that they deserve a dedicated release first.</p><p>This post describes the most significant improvements while a much longer list of the changesintroduced by the new version can be found in our <a href="../../release_notes.md#2.4.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/ Tue, 05 Nov 2024 18:46:13 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/    mp-units 2.3.0 released! Mateusz Pusz Releases <h1>mp-units 2.3.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.3.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.3.0">Conan</a>.</strong></p><p>This release fine-tunes many key features of the library. This post describes the most interestingimprovements, while a much longer list of the changes introduced by the new version can be found inour <a href="../../release_notes.md#2.3.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/ Mon, 30 Sep 2024 17:11:10 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/    What's new in mp-units 2.0? Mateusz Pusz Releases <h1>What's new in mp-units 2.0?</h1><p><strong>After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.0.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.0.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.0.0">Release Notes</a>. We will also describe some of them in this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/    mp-units 2.1.0 released! Mateusz Pusz Releases <h1>mp-units 2.1.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.1.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.1.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.1.0">Release Notes</a>. We will also describe the most important of themin this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/    mp-units 2.2.0 released! Mateusz Pusz Releases <h1>mp-units 2.2.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.2.1">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.2.1">Conan</a>.</strong></p><p>Among other features, this release provides long-awaited support for C++20 modules, redesigns andenhances text output formatting, and greatly simplifies quantity point usage. This post describesthose and a few other smaller interesting improvements, while a much longer list of the mostsignificant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.2.1">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/    Report from the Kona 2023 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Kona 2023 ISO C++ Committee meeting</h1><p><strong>Several groups in the ISO C++ Committee reviewed the <a href="https://wg21.link/p1935">P1935: A C++ Approach to Physical Units</a>proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potentialstandardization of such a library and encouraged further work. The authors also got valuableinitial feedback that highly influenced the design of the V2 version of the mp-units library.</strong></p><p>In the following years, we scoped on getting more feedback from the production and design. Thisresulted in version 2 of the <strong>mp-units</strong> library that resolved many issues the users and Committeemembers raised. The features and interfaces of this version are close to being the best we can getwith the current version of the C++ language standard.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/    Report from the St. Louis 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the St. Louis 2024 ISO C++ Committee meeting</h1><p>We made significant progress in the standardization of this library during the ISO C++ Committeemeeting in St. Louis.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/    Report from the Tokyo 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Tokyo 2024 ISO C++ Committee meeting</h1><p>The Tokyo 2024 meeting was a very important step in the standardization of this library. SeveralWG21 groups reviewed proposals, and the feedback was really good.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/   
\ No newline at end of file
+ mp-unitsThe quantities and units library for C++https://mpusz.github.io/mp-units/HEAD/mp-units Teamhttps://github.com/mpusz/mp-unitsen Tue, 17 Jun 2025 14:21:04 -0000 Tue, 17 Jun 2025 14:21:04 -0000 1440 MkDocs RSS plugin - v1.17.3  None mp-unitshttps://mpusz.github.io/mp-units/HEAD/   Introducing absolute quantities Mateusz Pusz Metrology <h1>Introducing absolute quantities</h1><p>This post introduces a new abstraction called an absolute quantity. It complements affinespace abstractions (point and delta) and will most probably be a new default in the librarywhen we release V3.</p>https://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/ Tue, 17 Jun 2025 14:16:55 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/06/16/introducing-absolute-quantities/    Bringing Quantity-Safety To The Next Level Mateusz Pusz Metrology <h1>Bringing Quantity-Safety To The Next Level</h1><p>All quantities and units libraries need to be unit-safe. Most of the libraries on the market dothis correctly. Some of them are also dimension-safe, which adds another level of protection fortheir users.</p><p><strong>mp-units</strong> is probably the only library on the market that additionally is quantity-safe. Thisgives a new quality and possibilities. I've described the major idea behind it, implementationdetails, and benefits to the users in the <a href="isq-part-5-benefits.md">series of posts about the International System of Quantities</a>.</p><p>However, this is only the beginning. We've always planned more and worked on the extensions in ourfree time. In this post, I will describe:</p><ul><li>What a quantity character is?</li><li>The importance of using proper representation types for the quantities.</li><li>The power of providing character-specific operations for the quantities.</li><li>Discuss implementation challenges and possible solutions.</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2025/01/15/bringing-quantity-safety-to-the-next-level/    International System of Quantities (ISQ): Part 4 - Implementing ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 4 - Implementing ISQ</h1><p>Up until now, we have introduced the International System of Quantities and described how we canmodel its main aspects. This article will present how to implement those models in a programminglanguage, and we will point out some of the first issues that stand in our way.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/    International System of Quantities (ISQ): Part 6 - Challenges Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 6 - Challenges</h1><p>This article might be the last one from our series. This time, we will discuss the challenges andissues with modeling of the ISQ in software.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/ Tue, 11 Feb 2025 16:26:19 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/    Report from the Wrocław 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Wrocław 2024 ISO C++ Committee meeting</h1><p>The Wrocław 2024 meeting was another efficient step in the standardization of this library.We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback.We've also introduced <code>std::fixed_string</code> to LEWG for C++26.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/ Fri, 29 Nov 2024 12:45:06 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/    International System of Quantities (ISQ): Part 1 - Introduction Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 1 - Introduction</h1><p>This post starts a series of articles about the International System of Quantities (ISQ).In this series, we will describe:</p><ul><li>What is ISQ?</li><li>Which engineering problems does ISQ help to solve and how?</li><li>How to model and implement it in the programming language?</li><li>What is missing in the ISQ, and why is that a problem?</li></ul>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/    International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used</h1><p>This article is the next one in our series about the ISQ. After introducing the basic terms andsystems, this article will talk about the issues we face when we base the quantities and unitslibrary on just units or dimensions.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/    International System of Quantities (ISQ): Part 3 - Modeling ISQ Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 3 - Modeling ISQ</h1><p>The physical units libraries on the market typically only focus on modeling one or more systemsof units. However, as we have learned, this is not the only system kind to model. Another,and maybe even more important, is a system of quantities. The most important example here isthe International System of Quantities (ISQ) defined by ISO/IEC 80000.</p><p>This article continues our series about the International System of Quantities. This time, we willlearn about the main ideas behind the ISQ and describe how it can be modelled in a programminglanguage.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/    International System of Quantities (ISQ): Part 5 - Benefits Mateusz Pusz Metrology <h1>International System of Quantities (ISQ): Part 5 - Benefits</h1><p>In the previous articles, we introduced the International System of Quantities, described how wecan model and implement it in a programming language, and presented the issues of software thatdoes not use such abstraction to implement a units library.</p><p>Some of the issues raised in <a href="isq-part-2-problems-when-isq-is-not-used.md">Part 2</a> of our serieswere addressed in <a href="isq-part-3-modeling-isq.md">Part 3</a> already. This article will presenthow our ISQ model elegantly addresses the remaining problems.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/ Mon, 11 Nov 2024 22:37:29 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/    mp-units 2.4.0 released! Mateusz Pusz Releases <h1>mp-units 2.4.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.4.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.4.0">Conan</a>.</strong></p><p>This release was unexpected. We planned a significant new feature to happen next, but whilepreparing for it, and also while writing API Reference documentation, we made so many vital fixesand improvements that we decided that they deserve a dedicated release first.</p><p>This post describes the most significant improvements while a much longer list of the changesintroduced by the new version can be found in our <a href="../../release_notes.md#2.4.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/ Tue, 05 Nov 2024 18:46:13 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/11/05/mp-units-240-released/    mp-units 2.3.0 released! Mateusz Pusz Releases <h1>mp-units 2.3.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.3.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.3.0">Conan</a>.</strong></p><p>This release fine-tunes many key features of the library. This post describes the most interestingimprovements, while a much longer list of the changes introduced by the new version can be found inour <a href="../../release_notes.md#2.3.0">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/ Mon, 30 Sep 2024 17:11:10 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/09/27/mp-units-230-released/    What's new in mp-units 2.0? Mateusz Pusz Releases <h1>What's new in mp-units 2.0?</h1><p><strong>After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.0.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.0.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.0.0">Release Notes</a>. We will also describe some of them in this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/09/24/whats-new-in-mp-units-20/    mp-units 2.1.0 released! Mateusz Pusz Releases <h1>mp-units 2.1.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.1.0">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.1.0">Conan</a>.</strong></p><p>The list of the most significant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.1.0">Release Notes</a>. We will also describe the most important of themin this post.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/12/09/mp-units-210-released/    mp-units 2.2.0 released! Mateusz Pusz Releases <h1>mp-units 2.2.0 released!</h1><p><strong>A new product version can be obtained from<a href="https://github.com/mpusz/mp-units/releases/tag/v2.2.1">GitHub</a> and<a href="https://conan.io/center/recipes/mp-units?version=2.2.1">Conan</a>.</strong></p><p>Among other features, this release provides long-awaited support for C++20 modules, redesigns andenhances text output formatting, and greatly simplifies quantity point usage. This post describesthose and a few other smaller interesting improvements, while a much longer list of the mostsignificant changes introduced by the new version can be found in our<a href="../../release_notes.md#2.2.1">Release Notes</a>.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/06/14/mp-units-220-released/    Report from the Kona 2023 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Kona 2023 ISO C++ Committee meeting</h1><p><strong>Several groups in the ISO C++ Committee reviewed the <a href="https://wg21.link/p1935">P1935: A C++ Approach to Physical Units</a>proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potentialstandardization of such a library and encouraged further work. The authors also got valuableinitial feedback that highly influenced the design of the V2 version of the mp-units library.</strong></p><p>In the following years, we scoped on getting more feedback from the production and design. Thisresulted in version 2 of the <strong>mp-units</strong> library that resolved many issues the users and Committeemembers raised. The features and interfaces of this version are close to being the best we can getwith the current version of the C++ language standard.</p>https://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/    Report from the St. Louis 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the St. Louis 2024 ISO C++ Committee meeting</h1><p>We made significant progress in the standardization of this library during the ISO C++ Committeemeeting in St. Louis.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/    Report from the Tokyo 2024 ISO C++ Committee meeting Mateusz Pusz WG21 Updates <h1>Report from the Tokyo 2024 ISO C++ Committee meeting</h1><p>The Tokyo 2024 meeting was a very important step in the standardization of this library. SeveralWG21 groups reviewed proposals, and the feedback was really good.</p>https://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/ Mon, 30 Sep 2024 12:47:28 +0000mp-unitshttps://mpusz.github.io/mp-units/HEAD/blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/   
\ No newline at end of file
diff --git a/HEAD/search/search_index.json b/HEAD/search/search_index.json
index a3d08092..d7cbcdee 100644
--- a/HEAD/search/search_index.json
+++ b/HEAD/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome to mp-units!","text":"
    mp-units is a compile-time enabled feature-rich Modern C++ modular/header-only library that provides compile-time dimensional analysis and unit/quantity manipulation. Its key strengths include safety, performance, and developer experience.
     
    It is the first library on the market that, besides being unit-safe and dimension-safe, is also quantity-safe.
     
    The library source code is hosted on GitHub with a permissive MIT license.
     Supported compilers 
    This library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
     
    Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality.
     
    Please refer to C++ compiler support chapter for more details.
     C++ modulesHeader files 
    #include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
     
    Output:
     
    Harvard Bridge length = 364.4 smoot (2034.6 ft, 620.14 m) \u00b1 1 \u03b5ar\n
     
    Try it on Compiler Explorer
     What is smoot? 
    The smoot (/\u02c8smu\u02d0t/) is a nonstandard unit of length created as part of an MIT fraternity prank. It is named after Oliver R. Smoot, a fraternity pledge to Lambda Chi Alpha, who, in October 1958, lay on the Harvard Bridge (between Boston and Cambridge, Massachusetts) and was used by his fraternity brothers to measure the length of the bridge.
     
    One smoot equals Oliver Smoot's height at the time of the prank (five feet and seven inches). The bridge's length was measured to be 364.4 smoots plus or minus one ear, with the \"plus or minus\" intended to express the measurement uncertainty.
     
    Oliver Smoot graduated from MIT with the class of 1962, became a lawyer, and later became chairman of the American National Standards Institute (ANSI) and president of the International Organization for Standardization (ISO).
     
    More on the smoot unit of length can be found at https://en.wikipedia.org/wiki/Smoot.
     
    Important: Help needed!
     
    The mp-units library might be the subject of ISO standardization for C++29. More on this can be found in the following ISO C++ proposals:
     
       
    • P1935: A C++ Approach to Physical Units,
      •  
    • P2980: A motivation, scope, and plan for a physical quantities and units library,
      •  
    • P3045: Quantities and units library.
      •  
     
    We are actively looking for parties interested in field-trialing the library.
    "},{"location":"api_reference/","title":"API Reference - mp-units","text":""},{"location":"release_notes/","title":"Release Notes","text":""},{"location":"release_notes/#mp-units","title":"mp-units","text":""},{"location":"release_notes/#2.5.0","title":"2.5.0 WIP","text":"
       
    • (!) feat: representation concepts improved
      •  
    • (!) feat: representation_of concept now also accepts a quantity_spec and accepts any representation character for quantity kinds
      •  
    • (!) feat: quantity::one() removed
      •  
    • (!) feat: Representation concept removed
      •  
    • feat: SymbolicArg applied to expression templates
      •  
    • feat: per and power made final
      •  
    • feat: derived_XXX are now constrained with SymbolicConstant
      •  
    • feat: prime factorization extended to any magnitude (thanks @chiphogg)
      •  
    • feat: cartesian_vector added
      •  
    • feat: equivalent now accept any units (even non-convertible)
      •  
    • feat: text output should fallback to the portable mode when UTF-8 is not used for text_encoding
      •  
    • feat: precondition added to to_u8string
      •  
    • feat: text output of scaled units is now enclosed in parenthesis (...) instead of brackets [...]
      •  
    • feat: abs(quantity) exposed for conforming freestanding implementations
      •  
    • feat: proper constraints for kind_of
      •  
    • feat: missing precondition added for quantity::op/
      •  
    • feat: quantity_spec conversions improved
      •  
    • feat: rankine unit added
      •  
    • feat: std::numeric_limits support added
      •  
    • feat: scaling_overflows_non_zero_values added to detect conversions overflowing rep
      •  
    • feat: deprecation messages now provide the release version where the deprecation happened
      •  
    • feat: electromagnetism.h updated to IEC80000-6-2022
      •  
    • feat: ConvertibleWithNumber introduced to improve convertibility of unit one with raw numbers
      •  
    • feat: lerp and midpoint for points added
      •  
    • feat: is_value_preserving customization point added
      •  
    • feat(example): is_vector specialization no longer needed for si_constants
      •  
    • (!) refactor: type_list moved to implementation details
      •  
    • (!) refactor: from now unit_symbol and dimension_symbol always returns std::string_view
      •  
    • (!) refactor: text_encoding renamed to character_set
      •  
    • (!) refactor: Magnitude renamed to UnitMagnitude and magnitude to unit_magnitude
      •  
    • (!) refactor: unit_magnitude moved to detail namespace
      •  
    • (!) refactor: absolute renamed to point
      •  
    • (!) refactor: power members refactored to be explicitly exposition only
      •  
    • (!) refactor: is_XXX customization points for representation types removed
      •  
    • (!) refactor: quantity_values renamed to representation values
      •  
    • (!) refactor: scalar and complex characters renamed to real_scalar and complex_scalar respectively + concepts refactoring
      •  
    • (!) refactor: MagConstant concept renamed to detail::is_mag_constant variable trait
      •  
    • refactor: mp_units.core defined in terms of core.h
      •  
    • refactor: MP_UNITS_NONCONST_TYPE introduced to benefit from the C++23 feature
      •  
    • refactor: SymbolicConstant concept refactored
      •  
    • refactor: explicit type of op/ for quantity and reference replaced with constrained placeholder
      •  
    • refactor: private unit_magnitude interface renamed to not use leading _
      •  
    • refactor: one_of concept removed and replaced with QSProperty in quantity_spec
      •  
    • refactor: std::is_trivial will be deprecated in C++26
      •  
    • refactor: SameQuantitySpec concept removed and replaced with direct comparison
      •  
    • refactor: unused SameReference concept removed
      •  
    • refactor: type_name_less introduced and used as a default predicate for expression templates
      •  
    • refactor: \"expression templates\" renamed to \"symbolic expressions\"
      •  
    • refactor: all_are_kinds removed and get_associated_quantity simplified
      •  
    • refactor: reference now returns explicit types for inverse, pow, sqrt, and cbrt
      •  
    • refactor: repeated concept checks removed from get_common_reference
      •  
    • refactor: std::assignable_from used in ValuePreservingTo concept
      •  
    • refactor: quantity constructor refactored to use another constructor with the result of sudo_cast
      •  
    • refactor: preconditions for quantity operations now use is_neq_zero
      •  
    • refactor: implicit expression variations used in quantity and quantity_point constraints
      •  
    • refactor: inverse() constraints improved
      •  
    • refactor: make_quantity_point introduced
      •  
    • refactor: point_origin_interface::op+ return type unified with the rest of the interfaces
      •  
    • refactor: std::convertible_to replaced with std::same_as in basic_fixed_string
      •  
    • refactor: less, ceil, and round refactored and improved + more unit tests for round
      •  
    • refactor: math_concepts.h removed and concepts replaced with explicit expression in constraints
      •  
    • refactor: visit_format_arg is deprecated in C++26
      •  
    • refactor: deprecated literal operators
      •  
    • refactor: constraints refactoring
      •  
    • (!) fix: electric_current_phasor, voltage_phasor, apparent_power switched to complex character
      •  
    • (!) fix: position_vector and displacement moved to a different place in a tree
      •  
    • (!) fix: velocity is now defined in terms of displacement instead of position_vector
      •  
    • fix: missing core.h added to CMake
      •  
    • fix: const was leaking to some SymbolicConstants
      •  
    • fix: make_reference should skip only the exact kinds deduced from a unit
      •  
    • fix: inconsistencies in get_common_quantity_spec() fixed
      •  
    • fix: unused convertible_kinds() argument removed
      •  
    • fix: compile-time branch condition fixed in quantity_point::point_for
      •  
    • fix: inverse(Quantity) fixed for subkinds of dimensionless
      •  
    • fix: point_origin_interface::op+ constraints fixed
      •  
    • fix: missing get_common_unit() overload added
      •  
    • fix: floor and ceil constraints fixed
      •  
    • fix: quantity characters fixed in electromagnetism quantities
      •  
    • fix: arg.visit support fixed
      •  
    • fix: expr_less now also sorts powers
      •  
    • fix: mag_constant workarounds branches for clang fixed
      •  
    • fix: checking for clang versions fixed in CMake scripts
      •  
    • fix: text stripping in type_name fixed
      •  
    • test: lots of tests for complex quantities
      •  
    • test: runtime unit tests refactored to have a bigger granularity (less top level tests)
      •  
    • test: surface tension replaced with entropy in an fmt test
      •  
    • test: test_package now is tested also with C++20 modules
      •  
    • test: tests for dimensionless quantities static data members
      •  
    • test: a few more natural units tests added
      •  
    • test: tests to check if quantity satisfies Scalar
      •  
    • test: add static tests for concept DimensionOf (thanks @jvocht)
      •  
    • test: quantity character concepts tests for quantities added
      •  
    • docs: ISQ part 6 released
      •  
    • docs: new chapter about our documentation added to the contributing guide
      •  
    • docs: directory name updated in the contributing guide
      •  
    • docs: mp-units Conan options added to conanfile.txt examples
      •  
    • docs: contracts Conan option default value description improved
      •  
    • docs: outdated note removed from the \"Text Output\" chapter
      •  
    • docs: a paragraph about additional formatting options removed (applicable only to quantity symbols which we do not support)
      •  
    • docs: Wroc\u0142aw 2024 meeting report
      •  
    • docs: explicit unit conversion example added to the \"Symbols of common units\" chapter
      •  
    • docs: \"Bringing Quantity-Safety To The Next Level\" blog post added
      •  
    • docs: quantity-safety mentioned in the docs
      •  
    • docs: complex character added to the \"Quantity character\" chapter
      •  
    • docs: intro to \"Value Conversions\" chapter added
      •  
    • docs: \"Scaling overflow prevention\" chapter added
      •  
    • docs: \"Concepts\" chapter updated
      •  
    • docs: old customization points removed from the \"Character of a Quantity\" chapter
      •  
    • docs: clang-19 issues mentioned in a compiler support table
      •  
    • docs(ref): document most of mp_units.core (thanks @JohelEGP)
      •  
    • build: CheckCacheVarValues CMake module file added
      •  
    • build: MP_UNITS_DEV_TIME_TRACE CMake option added
      •  
    • build: MP_UNITS_API_NO_CRTP removed from test_package CMake
      •  
    • build: require at least CMake 3.31 with Conan
      •  
    • build: clang-20 enabled in CI
      •  
    • build: clang-19 support removed from conanfile.py
      •  
    • build: clang-20.1 workaround added to package_info
      •  
    • build: update dependencies to gsl-lite/0.42.0, ms-gsl/4.1.0, fmt/11.1.4, and catch2/3.8.0
      •  
    • build: suppress warnings for gcc-12 in conanfile
      •  
    • ci: CI matrix generation added (thanks @burnpanck)
      •  
    • ci: import_std now checks if at least C++23 is being used
      •  
    • perf: caching of the results of heavy consteval functions execution added
      •  
    • perf: expr_projectable concept removed to improve compilation performance
      •  
    "},{"location":"release_notes/#2.4.0","title":"2.4.0 November 5, 2024","text":"
       
    • (!) feat: phase_velocity and group_velocity aliases removed from ISQ by ISO
      •  
    • feat: iec::bit using-declared in iec::unit_symbols
      •  
    • feat: common unit symbols now use EQUIV{u1, u2, ...} syntax
      •  
    • feat: scaled_unit symbol printing improved ([] around the entire unit, small magnitude values do not use a power of 10 anymore)
      •  
    • feat: scaled_unit does not have a priority over derived_unit anymore
      •  
    • feat: fractional exponents support added to mag_power
      •  
    • feat: tag types are now required to be empty
      •  
    • feat: magnitude text now obeys formatting parameters and knows how to print constants
      •  
    • feat: added support for printing powers of magnitude constants
      •  
    • feat: SymbolicConstant concept added
      •  
    • feat: common_unit selection algorithm improved to make rev + rad return rad
      •  
    • feat: litre text symbol changed from l to L to avoid ambiguity with 1
      •  
    • feat: alternative litre unit symbol L added to prevent ambiguities with 1
      •  
    • feat: Unicode unit symbols
      •  
    • feat: \u03c0 added as an alias for pi
      •  
    • feat: expr_pow extended to remove redundancy in callers
      •  
    • feat: DerivedDimensionExpr, DerivedQuantitySpecExpr and DerivedUnitExpr removed
      •  
    • feat: MagnitudeSpecExpr and PowerVBase removed and some functions renamed to limit possible ambiguity in overload resolution
      •  
    • feat: std::is_object constraint applied to value_type_t
      •  
    • feat: quantity_values are now defined on top of std::chrono::duration_values
      •  
    • feat: from now on truncation is not allowed in compound assignment
      •  
    • feat(example): currency example now uses chrono::time_point and has better interfaces
      •  
    • feat(example): treat_as_floating_point specializations for examples' types removed
      •  
    • (!) refactor: all iec quantity specifications are now deprecated and moved to isq
      •  
    • (!) refactor: mag_constant now takes a symbol and a value and the class deriving from it must be final
      •  
    • (!) refactor: op==(U1, U2) now checks for the same type (old behavior available as equivalent(U1, U2)) + convertible now verifies associated quantity_spec as well
      •  
    • (!) refactor: ascii -> portable, unicode -> utf8, 'A' -> 'P'
      •  
    • (!) refactor: char_traits removed from fixed_string
      •  
    • (!) refactor: convertibility traits and concepts refactored to use bool flags instead of wrappers
      •  
    • (!) refactor: tag types should not expose their members
      •  
    • refactor: convertible(U1, U2) implementation simplified
      •  
    • refactor: abs moved to constexpr_math.h
      •  
    • refactor: unit_symbol_impl simplified
      •  
    • refactor: unit_symbol_formatting moved to a dedicated header file
      •  
    • refactor: shorten_T removed
      •  
    • refactor: magnitude interface cleanup
      •  
    • refactor: derived_from_the_same_base_dimension no longer needed
      •  
    • refactor: one_of usage removed from the fixed_string deduction guides
      •  
    • refactor: quantity.h is not needed in constants.h (unit.h is enough)
      •  
    • refactor: SameDimension concept is not needed and can be inlined in DimensionOf
      •  
    • refactor: framework Unicode symbols are now spelled using their codes
      •  
    • refactor: QuantitySpecWithNoSpecifiers removed and kind_of definition simplified
      •  
    • refactor: treat_as_floating_point simplified and extended to use std::chrono::treat_as_floating_point_v
      •  
    • refactor: wrapped_type_t reuses std::indirectly_readable_traits
      •  
    • refactor: expr_fractions takes direct OneType type now instead of a trait
      •  
    • refactor: Unicode symbols description reworked based on the latest SG16 recommendations
      •  
    • refactor: Mutable concept applied to quantity and quantity_point
      •  
    • refactor: explicit cleanup for deduction guides of quantity and quantity_point
      •  
    • refactor: point_origin_interface::op- cleanup
      •  
    • refactor: QuantityLikeImpl refactored to conform to API Reference by @JohelEGP
      •  
    • refactor: get_complexity refactored to be 0-based and not account for a number of arguments in a list
      •  
    • refactor: get_complexity refactored to returned maximum complexity of an element (instead of the sum of elements)
      •  
    • refactor(test): derived_quantity refactored to child_quantity
      •  
    • fix: missing are_ingredients_convertible overloads added
      •  
    • fix: constraints for magnitude added for scaled_unit and fixed common_unit instantiating it incorrectly
      •  
    • fix: according to ISO 80000-16 % should always be prefixed with space
      •  
    • fix: extraneous space in unit symbol having only denominators removed
      •  
    • fix: explicit cast added to less for magnitudes to fix clang-arm64 conversion error
      •  
    • fix: common_unit handling fixed for some corner cases
      •  
    • fix: math functions constraints fixed
      •  
    • fix: operator*(M, U u) fixed for U being scaled_unit
      •  
    • fix: subsumption of QuantityKindSpec fixed
      •  
    • fix: ValuePreservingTo fixed to apply std::remove_cvref_t on FromRep
      •  
    • fix: compound assignment operations on quantities now behave the same as on the underlying representation types
      •  
    • fix: QuantityConvertibleTo used in quantity_point compound assignment
      •  
    • fix: convertible_kinds implementation fixed
      •  
    • fix(tests): freestanding build fixed
      •  
    • test: unit tests for the inverse of mag_constant added
      •  
    • test: Unicode symbols used in unit tests
      •  
    • test: more std::chrono tests added
      •  
    • test: commutativity tests added to ISQ
      •  
    • test: one kind_of test added to reference tests
      •  
    • test: pow<0> and pow<1> tests added for dimensions
      •  
    • test: more get_common_quantity_spec tests added
      •  
    • build: setting of some test_package CMake options enabled only for a cxx_modules build
      •  
    • ci: sudo apt update added for documentation.yml in hope that it will resolve missing system packages issue
      •  
    • ci: MSVC added to the CI
      •  
    • ci: the latest not-released docs will use \"HEAD\" as a version from now on
      •  
    • ci: documentation action should run on a new tag as well
      •  
    • ci: documentation action limited only to commits that change documentation files
      •  
    • ci: non-documentation actions should not run on tags
      •  
    • docs: missing systems added to the \"Project Structure\" chapter
      •  
    • docs: graphs of ISQ kind hierarchies improved
      •  
    • docs: category of the ISO meeting reports changed to \"WG21 Updates\"
      •  
    • docs: blog comments support added
      •  
    • docs: Part 1-5 articles of the ISQ series added
      •  
    • docs: \"Symbols of scaled units\" chapter added + minor updates to scaled and common units chapters
      •  
    • docs: conan profile updated to present gcc-14 instead of gcc-12 which is no longer supported
      •  
    • docs: \"Why derived units order is not preserved from the multiplication?\" chapter added to FAQ
      •  
    • docs: \"Many shades of the same unit\" extended with a note about the derived units order
      •  
    • docs: API Reference now presents index.html instead of full.hml
      •  
    "},{"location":"release_notes/#2.3.0","title":"2.3.0 September 27, 2024","text":"
       
    • (!) feat: delta and absolute construction helpers
      •  
    • (!) feat: Conan and CMake options changed as requested at ConanCenter code review
      •  
    • (!) feat: unit_can_be_prefixed removed - from now on all named units can be prefixed
      •  
    • feat: formatting functions for units and dimensions marked as constexpr to enable compile-time text formatting
      •  
    • feat: qp1.quantity_from(qp2) added
      •  
    • feat: non-member swap added for fixed_string
      •  
    • feat: simplified inplace_vector added
      •  
    • feat: text output for angular units improved (space before symbol removed)
      •  
    • feat: representation type template parameter added to value conversion functions
      •  
    • feat: all tags in the expression templates are now ordered by the type names
      •  
    • feat: convertibility of a quantity with a unit one with the raw value added
      •  
    • feat: import std; support added
      •  
    • feat: compute values for rational magnitude powers (thanks @chiphogg)
      •  
    • feat: value_cast<Representation, Unit>() complementary conversion function added
      •  
    • feat: hw_voltage example added
      •  
    • feat: MP_UNITS_IMPORT_STD and MP_UNITS_MODULES handled properly in test_package.cpp
      •  
    • feat: complex quantity character added
      •  
    • feat: iec::var unit added
      •  
    • feat: type_list_unique added
      •  
    • feat: for_each on std::tuple added
      •  
    • feat: common_unit support added
      •  
    • (!) refactor: quantity_point_like_traits now use numerical value instead of the quantity
      •  
    • (!) refactor: iec80000 system renamed to iec
      •  
    • (!) refactor: mag_pi is now mag<pi>
      •  
    • (!) refactor: common_XXX() functions renamed to get_common_XXX()
      •  
    • refactor: error messages-related improvements
      •  
    • refactor: [[nodiscard]] and consteval set for some magnitude-related functions
      •  
    • refactor: degree Celsius and Fahrenheit symbols text now use Unicode codepoints
      •  
    • refactor: dimension_symbol and units_symbol refactored to use inplace_vector
      •  
    • refactor: unit_symbol and dimension_symbol refactored for readability and consteval
      •  
    • refactor: binary operators of quantity and quantity_point are now hidden friends
      •  
    • refactor: tag types-related operators are now hidden friends as well
      •  
    • refactor: ValuePreservingTo concept added
      •  
    • refactor: perfect forwarding interfaces improved
      •  
    • refactor: Representation concepts now requires WeaklyRegular instead of std::regular
      •  
    • refactor: quantity_point default-constructibility removed from the quantity_from constraints
      •  
    • refactor: has_common_type_v simplified
      •  
    • refactor: is_power_of_quantity_spec and is_power_of_dim variable templates converted to concepts
      •  
    • refactor: unnecessary custom versions of is_specialization_of removed
      •  
    • refactor: is_derived_from_specialization_of_v added and applied to remove custom traits
      •  
    • fix: signatures of capacity functions of fixed_string fixed
      •  
    • fix: MP_UNITS_API_NO_CRTP handling fixed
      •  
    • fix: MP_UNITS_HOSTED branch added to core.h
      •  
    • fix: mkdocs dependencies fixed in the gitpod dockerfile
      •  
    • fix: MP_UNITS_API_CONTRACTS should have a priority over headers availability
      •  
    • fix: si.h and angular.h now properly include hacks.h to define MP_UNITS_HOSTED before its usage
      •  
    • fix: quantity scaling between different prefixes improved
      •  
    • fix: conversion operator to std::chrono types fixed
      •  
    • fix: std::format does not always use Char* as iterators
      •  
    • fix: complex_power & co fixed
      •  
    • fix: __cpp_deleted_function workaround for clang-19 added
      •  
    • test: conversion to chrono unit tests added
      •  
    • test: unit tests for creating a quantity from a volatile variable
      •  
    • test: increase tolerance for certain math tests to two epsilon by @burnpanck
      •  
    • test: std::complex-based quantities tests added
      •  
    • build: conanfile bumped to use catch2/3.7.0
      •  
    • build: conanfile bumped to use fmt/11.0.1
      •  
    • build: minimum required CMake version bumped to 3.25
      •  
    • build: duplicated cmake_minimum_required commands removed
      •  
    • build: minimum conan version set to 2.0.15
      •  
    • build: MSVC compilation enabled for the library part by @czjhoppe
      •  
    • build: Dockerfile updated for gitpod
      •  
    • build: generate() in test_package now correctly propagates project's options
      •  
    • build: target_include_directories is not needed anymore
      •  
    • build: target_compile_features now uses CMAKE_CXX_STANDARD
      •  
    • build: package_type is dynamically set in conanfile.py depending if we build modules or not
      •  
    • build(conan): packaging improved
      •  
    • ci: added test for upstream clang on macos-14, as an example for an arm64 platform by @burnpanck
      •  
    • style: pre-commit updated to clang-format-18.1.8
      •  
    • docs: \"Strong Angular System\" chapter added
      •  
    • docs: docs updated to use new spelling for Conan options
      •  
    • docs: \"Interface Introduction\" chapter updated
      •  
    • docs: St. Louis 2024 report added
      •  
    • docs: \"Radians and degrees support\" added
      •  
    • docs: Rework of \"Getting Started\" section
      •  
    • docs: \"API Reference\" support added (thanks @JohelEGP)
      •  
    • docs: \"Generating API reference\" chapter added
      •  
    • docs: minor formatting and spelling improvements to the \"CONTRIBUTING.md\"
      •  
    • docs: \"Unit symbols\" chapter added
      •  
    • docs: examples line numbers fixed
      •  
    • docs: \"Text Formatting\" tag removed from avg_speed example
      •  
    • docs: line breaks in mermaid graphs fixed
      •  
    • docs: 2.3.0 release added
      •  
    "},{"location":"release_notes/#2.2.1","title":"2.2.1 July 3, 2024","text":"
       
    • (!) feat: Conan and CMake options refactored
      •  
    "},{"location":"release_notes/#2.2.0","title":"2.2.0 June 14, 2024","text":"
       
    • (!) feat: C++ modules support added by @JohelEGP
      •  
    • (!) feat: New formatting specification implemented
      •  
    • (!) feat: has_unit_symbol support removed
      •  
    • (!) feat: ABI concerns resolved with introduction of u8 strings for symbols
      •  
    • (!) feat: API-related Conan, CMake, and preprocessor options redesigned
      •  
    • (!) feat: core.h removed
      •  
    • (!) feat: from now on units, dimensions, quantity specifications, and point origins have to be marked as final
      •  
    • feat: implicit point origins support added
      •  
    • feat: unit default point origin support added
      •  
    • feat: fma, isfinite, isinf, and isnan math function added by @NAThompson
      •  
    • feat: fma for quantity points added
      •  
    • feat: quantity_point support added for quantity_cast and value_cast
      •  
    • feat: value_cast<Unit, Representation> added
      •  
    • feat: value_cast<Quantity>(q), value_cast<Quantity>(qp) and value_cast<QuantityPoint>(qp) added by @burnpanck
      •  
    • feat: interconvertible(quantity_spec, quantity_spec) added
      •  
    • feat: qp.quantity_from_zero() added
      •  
    • feat: value_type type trait added
      •  
    • feat: do not print space between a number and percent or per_mille
      •  
    • feat: ppm parts per million added by @nebkat
      •  
    • feat: atan2 2-argument arctangent added by @nebkat
      •  
    • feat: fmod floating-point division remainder added by @nebkat
      •  
    • feat: remainder IEEE division remainder added by @nebkat
      •  
    • feat: std::format support added
      •  
    • feat: unit text output support added
      •  
    • feat: formatting error messages improved
      •  
    • feat: improve types readability by eliminating extraneous () in references, prefixes, and kind_of
      •  
    • feat: dimension and unit text output added
      •  
    • feat: some light and radiation ISQ quantities added
      •  
    • feat: allow configuring GSL library use
      •  
    • feat: freestanding support added
      •  
    • (!) refactor: zero_Fahrenheit renamed to zeroth_degree_Fahrenheit
      •  
    • (!) refactor: SI-related trigonometric functions moved to the si subnamespace
      •  
    • (!) refactor: math.h header file broke up to smaller pieces
      •  
    • (!) refactor: fixed_string interface refactored
      •  
    • (!) refactor: ReferenceOf does not take a dimension anymore
      •  
    • (!) refactor: 'o' replaced with '1' as a modifier for unit_symbol_solidus::one_denominator
      •  
    • (!) refactor: get_kind() now returns kind_of
      •  
    • (!) refactor: FMT macros moved to compat_macros.h
      •  
    • (!) refactor: fixed_string refactored to reflect the latest changes to P3094R2
      •  
    • (!) refactor: basic_symbol_text renamed to symbol_text
      •  
    • (!) refactor: ratio hidden as an implementation detail behind mag_ratio
      •  
    • (!) refactor: framework.h introduced
      •  
    • (!) refactor: type list tools made an implementation detail of the library
      •  
    • (!) refactor: header files with the entire system definitions moved up in the directory tree
      •  
    • (!) refactor: absolute_point_origin does not use CRTP anymore
      •  
    • refactor: system's units do not inherit from one another anymore
      •  
    • refactor: all units made final
      •  
    • refactor: math functions constraints refactored
      •  
    • refactor: si_quantities.h added to improve compile-times
      •  
    • refactor: validate_ascii_string refactored to is_basic_literal_character_set
      •  
    • refactor: underlying_type split to wrapped_type and value_type and used in code
      •  
    • refactor: code refactored to comply with clang-tidy
      •  
    • refactor: remove dependency on <ranges> header and switch to use an iterator-based copy algorithm
      •  
    • refactor: terminate replaced with abort and a header file added
      •  
    • refactor: most std::remove_const_t removed and some replaced with the GCC-specific workaround
      •  
    • refactor: not needed remove_reference_t and remove_cvref_t removed
      •  
    • refactor: binary operators of quantity and quantity_point are now hidden friends
      •  
    • fix: QuantityLike conversions required Q::rep instead of using one provided by quantity_like_traits
      •  
    • fix: quantity_spec[Unit] replaced with make_reference in value_cast
      •  
    • fix: ice_point is now defined with the integral offset from absolute_zero
      •  
    • fix: performance regression in sudo_cast fixed
      •  
    • fix: explicit object parameter support fixed
      •  
    • fix: missing version header file added to hacks.h
      •  
    • fix: quantity_cast to accept lvalue references (thanks @burnpanck)
      •  
    • fix: value_cast with lvalue references to quantity_point (thanks @burnpanck)
      •  
    • docs: project blog and first posts added
      •  
    • docs: project documentation layout refactored
      •  
    • docs: \"Interoperability with Other Libraries\" chapter added
      •  
    • docs: \"Framework Basics\" chapters updated and cleaned up
      •  
    • docs: smoot unit example added to the main page
      •  
    • docs: \"Code Example\" chapter renamed to \"Look and Feel\" and reordered in TOC to be after \"Quick Start\"
      •  
    • docs: \"Quick Start\" chapter reworked to be simpler and include quantity points
      •  
    • docs: \"Quantity points\" chapter extended
      •  
    • docs: \"The Affine Space\" chapter updated to reflect the recent design changes
      •  
    • docs: \"Working with Legacy interfaces\" chapter added
      •  
    • docs: \"Text Output\" chapter updated
      •  
    • docs: mkdocs social plugin enabled
      •  
    • docs: project logo and custom color scheme added
      •  
    • docs: minimum compiler requirements updated
      •  
    • docs: unit symbols admonition extended in the \"Quick Start\" chapter
      •  
    • docs: Cairo dependency described in the MkDocs section
      •  
    • docs: \"hello units\" example updated with dimensions output
      •  
    • docs: \"Text Output\" chapter updated with the recent formatting changes
      •  
    • docs: formatting grammar language changed to EBNF
      •  
    • docs: \"Project structure\" chapter expanded
      •  
    • docs: CITATION.cff updated
      •  
    • (!) build: Conan and CMake options refactored
      •  
    • (!) build: MP_UNITS_AS_SYSTEM_HEADERS renamed to MP_UNITS_BUILD_AS_SYSTEM_HEADERS
      •  
    • (!) build: MP_UNITS_BUILD_LA and MP_UNITS_IWYU CMake options now have _DEV_ in the name
      •  
    • build: gsl-lite updated to 0.41.0
      •  
    • build: catch2 updated to 3.5.1
      •  
    • build: fmt updated to 10.2.1
      •  
    • build: gitpod environment updated
      •  
    • build: check_cxx_feature_supported added
      •  
    • build: IWYU path handling fixed
      •  
    • build: IWYU enabled on GCC
      •  
    • build: CMAKE_EXPORT_COMPILE_COMMANDS flag enabled for the developer's build
      •  
    • build(conan): generate() now set cache_variables
      •  
    • build(conan): can_run check added before running tests
      •  
    • ci: Conan and CMake CI now use different cache names
      •  
    • ci: gcc-14 added
      •  
    • ci: clang-tidy CI added
      •  
    "},{"location":"release_notes/#2.1.1","title":"2.1.1 May 16, 2024","text":"
       
    • fix: unit tests compilation on gcc-14 fixed
      •  
    • fix: explicit this parameter support fixed
      •  
    "},{"location":"release_notes/#2.1.0","title":"2.1.0 December 9, 2023","text":"
       
    • (!) feat: inverse() support added for dimensions, quantity_spec, units, and references             (1 / s will now create quantity and not a Unit)
      •  
    • (!) feat: quantity_point does not provide zero() anymore
      •  
    • (!) feat: quantity_spec and its kind should not compare equal
      •  
    • (!) feat: mutating interface removed from fixed_string
      •  
    • (!) feat: common_type with a raw value is not needed anymore as for a long time now raw values are   not convertible to the dimensionless quantities
      •  
    • (!) feat: symbol_text definition simplified
      •  
    • (!) feat: users are now allowed to inherit their own types from absolute point origins
      •  
    • (!) feat: interoperability with other libraries redesigned
      •  
    • feat: basic_fixed_string(const CharT*, std::integral_constant<std::size_t, N>) constructor added
      •  
    • feat: isq::activity added and becquerel definition updated to benefit from it
      •  
    • feat: gray and sievert now have correct associated quantity kinds
      •  
    • feat: UnitCompatibleWith concept added and applied to in(U) and force_in(U) functions
      •  
    • feat: quantities can now be multiplied and divided by units (no parenthesis needed anymore)
      •  
    • feat: Magnitude / Unit operator added
      •  
    • feat: equality for dimensions now will allow derived classes as well (but not from derived_dimension)
      •  
    • feat: zero_Fahrenheit point origin added
      •  
    • feat: equivalent point origins handling improved
      •  
    • feat(example): unit symbols added to the currency example
      •  
    • (!) refactor: unit_symbol<fmt>(U) signature refactored and the resulting text can now also be used at runtime
      •  
    • (!) refactor: make_xxx factory functions replaced with two-parameter constructors
      •  
    • (!) refactor: unit_symbol changed to consteval
      •  
    • refactor: in(U) and force_in(U) now return auto to provide better diagnostics on clang
      •  
    • refactor: quantity operators constraints refactored
      •  
    • refactor: more type members added to fixed_string definition
      •  
    • refactor: unit_symbol_formatting enums now use std::int8_t as a representation type
      •  
    • fix: symbols of named dimensionless units with the ratio = 1 were not printed
      •  
    • fix: iterator is now properly updated for all cases in unit_symbol
      •  
    • fix: Fahrenheit conversion ratio was inverted
      •  
    • fix: CommonlyInvocableQuantities was overconstrained for the current library design
      •  
    • fix: are_ingredients_convertible now mandates explicit conversion for To dimensionless quantities
      •  
    • fix: quantity_point::point_for(PO) constraints fixed
      •  
    • fix(example): latitude and longitude fixed to include 0 for N and E respectively
      •  
    • ci: clang-17 enabled
      •  
    • ci: apple-clang-15 enabled
      •  
    • ci: Added C++23 builds to the CI matrix
      •  
    • docs: \"Getting Started\" chapters updated
      •  
    • docs: \"Basic Concepts\" and \"Interface Introduction\" chapters updated
      •  
    • docs: \"Design Overview\" chapter added and \"Concepts\" chapter reworked
      •  
    • docs: \"Output stream formatting\" chapter updated
      •  
    • docs: \"Default formatting\" chapter updated
      •  
    • docs: \"Derived unit symbols generation\" chapter added
      •  
    • docs: outdated affine space chapter updated
      •  
    • docs: CameCase concept identifiers FAQ added
      •  
    • docs: gravitational_potential_energy equation fixed on a graph
      •  
    • docs: YouTube video link updated to the C++ on Sea 2023
      •  
    • docs: ISO papers reference added to docs and README
      •  
    • docs: a representation type in a dimensionless quantity FAQ fixed
      •  
    • docs: titles added to some important admonitions
      •  
    • docs: \"Terms and Definitions\" slightly updated
      •  
    • docs: \"canonical unit\" added to glossary and its documentation in code was updated
      •  
    • docs: Design overview graph updated
      •  
    "},{"location":"release_notes/#2.0.0","title":"2.0.0 September 24, 2023","text":"
       
    • units namespace renamed to mp_units (#317)
      •  
    • header files in the <mp-units/...> rather then in <units/...> (#317)
      •  
    • the downcasting facility is removed (#383, #211, #32)
      •  
    • unified and simplified quantity creation (#274)
      •  
    • determining the best way to create a quantity (#413)
      •  
    • V2 quantity_point (#414)
      •  
    • introduction of quantity_spec to store not only dimension but also additional information about quantities (#405)
      •  
    • quantity now takes reference object, which aggregates quantity_spec and a unit and a representation type
      •  
    • units, prefixes, dimensions, quantity specifications, and references are passed as NTTPs to templates and provide arithmetic operations and comparison
      •  
    • expression templates consistently used in all derived types to increase the readability (#351, #166)
      •  
    • derived dimensions are now factors of only base dimensions (#281)
      •  
    • convertibility of derived quantities (#427)
      •  
    • dimensions, quantity specifications, units, and references are now composable, significantly reducing the number of definitions and resulting types
      •  
    • heavily simplified unit systems definitions (no need to define unnamed derived units, systems-specific dimensions, aliases for quantities, concepts, UDLs, ... anymore)
      •  
    • improved definition of all systems
      •  
    • support for ISO 80000 Part 3-6 quantities
      •  
    • faster than lightspeed constants (#169)
      •  
    • extensions to quantity formatting with fmt
      •  
    • quantity_kind removed
      •  
    • improved casting of unit with .in(Unit), .force_in(Unit) for quantity and quantity_spec
      •  
    • numerical value accessor safety improved with .numerical_value_in(Unit) and .force_numerical_value_in(Unit)
      •  
    • quantity can no longer be constructed with a raw value (#434)
      •  
    • Implicit construction of quantities from a value (#410)
      •  
    • quantity_point can no longer be constructed with just a quantity and an explicit PointOrigin is always needed
      •  
    • ceil and floor are dangerous (#432)
      •  
    • quecto, ronto, ronna, quetta new SI prefixes support
      •  
    • comparison against zero added (#487)
      •  
    • documentation rewritten from scratch
      •  
    • many smaller changes not possible to address with the previous design (#205, #210, #134)
      •  
    "},{"location":"release_notes/#0.8.0","title":"0.8.0 June 14, 2023","text":"
       
    • (!) refactor: common_quantity, common_quantity_for, common_quantity_point, common_quantity_kind, and common_quantity_point_kind removed
      •  
    • (!) refactor: named_derived_unit removed as it was not used
      •  
    • (!) refactor: derived_unit renamed to derived_scaled_unit
      •  
    • (!) refactor: unit renamed to derived_unit
      •  
    • (!) refactor: U::is_named removed from the unit types and replaced with NamedUnit concept
      •  
    • (!) refactor: PrefixFamily support removed
      •  
    • (!) refactor: mi(naut) renamed to nmi
      •  
    • (!) refactor: knot unit helper renamed to kn in FPS
      •  
    • (!) refactor: knot text symbol changed from \"knot\" to \"kn\"
      •  
    • refactor: quantity op+() and op-() reimplemented in terms of reference rather then quantity types
      •  
    • refactor(example): glide_computer now use dimensionless quantities with ranged_representation as rep
      •  
    • feat: HEP system support added (thanks @RalphSteinhagen)
      •  
    • feat: floor(), ceil(), and round() support added (thanks @hofbi)
      •  
    • feat: std::format support for compliant compilers added
      •  
    • feat: conversion helpers from mp-units to std::chrono types added
      •  
    • feat: math functions can now be safely used with user-defined types
      •  
    • feat: conversion from quantity_point to std::chrono::time_point added
      •  
    • feat: nautical_mile_per_hour and knot added to si::international system
      •  
    • (!) fix: add quantity_point::origin, like std::chrono::time_point::clock
      •  
    • fix: enable any prefixes for most of the named units (beside those that use prefixes already)
      •  
    • fix: hectare definition fixed to be a prefixed version of are + other units
      •  
    • fix: account for different dimensions in quantity_point_cast's constraint
      •  
    • fix: output stream operator now properly handles state
      •  
    • fix: fmt algorithms were overconstrained with forward_iterator
      •  
    • fix: CTAD for aliases fixed
      •  
    • fix: derived_ratio calculation
      •  
    • fix: fill_t assignment operator fixed
      •  
    • fix: improve downcast mode off
      •  
    • fix: radioactivity header compilation fixed
      •  
    • fix: si::hep::dim_momentum duplicated definition fixed
      •  
    • fix: fps can now coexist with international system
      •  
    • fix: public headers fixed to be standalone
      •  
    • test: standalone public headers tests added
      •  
    • (!) build: CMake generator in Conan is no longer obtained from an environment variable
      •  
    • (!) build: Required Conan version bumped to 1.48
      •  
    • (!) build: Conan 1.48 does not set CMAKE_BUILD_TYPE in the conan_toolchain.cmake anymore
      •  
    • build: AppleClang 13 support added (thanks @fdischner)
      •  
    • build: most of the conanfile.py refactored to be Conan 2.0 ready
      •  
    • build: validate() replaced with configure() to raise errors during conan install in Conan 1.X
      •  
    • build: minimum Conan version changed to 1.40
      •  
    • build: linear-algebra Conan repo is no needed anymore
      •  
    • build: Gitpod support added
      •  
    • build: clang-format-15 support added
      •  
    • build: export config to local build (#322)
      •  
    • build: fix export name of mp-units-system
      •  
    • build: fmt updated to 8.0.1
      •  
    • build: gsl-lite updated to 0.40.0
      •  
    • build: catch2 updated to 2.13.9
      •  
    • build: doxygen updated to 1.9.4
      •  
    • build: linear_algebra/0.7.0 switched to wg21-linear_algebra/0.7.2
      •  
    • ci: VS2022, gcc-11, clang-13, clang-14, and AppleClang 13 support added
      •  
    • ci: pre-commit support added (thanks @hofbi)
      •  
    • docs: Project documentation updated
      •  
    • docs: CITATION.cff file added
      •  
    • docs: CONTRIBUTING.md updated
      •  
    "},{"location":"release_notes/#0.7.0","title":"0.7.0 May 11, 2021","text":"
       
    • (!) refactor: ScalableNumber renamed to Representation
      •  
    • (!) refactor: output stream operators moved to the units/quantity_io.h header file
      •  
    • (!) refactor: Refactored the library file tree
      •  
    • (!) refactor: quantity::count() renamed to quantity::number()
      •  
    • (!) refactor: data system renamed to isq::iec80000 (quantity names renamed too)
      •  
    • (!) refactor: *deduced_unit renamed to *derived_unit
      •  
    • (!) refactor: got rid of a noble_derived_unit
      •  
    • refactor: quantity (kind) point updated to reflect latest changes to quantity
      •  
    • refactor: basic concepts, quantity and quantity_cast refactored
      •  
    • refactor: abs() definition refactored to be more explicit about the return type
      •  
    • feat: quantity (point) kind support added (thanks @johelegp)
      •  
    • feat: quantity references support added (thanks @johelegp)
      •  
    • feat: quantity aliases support addded
      •  
    • feat: interoperability with std::chrono::duration and other units libraries
      •  
    • feat: CTAD for dimensionless quantity added
      •  
    • feat: modulation_rate support added (thanks @go2sh)
      •  
    • feat: SI prefixes for isq::iec80000 support added (thanks @go2sh)
      •  
    • feat: a possibility to disable quantity UDLs support with UNITS_NO_LITERALS preprocessor define
      •  
    • feat: a support to define ISQ derived dimensions in terms of different number or order of components
      •  
    • perf: preconditions check do not influence the runtime performance of a Release build
      •  
    • perf: quantity_cast() generates less assembly instructions
      •  
    • perf: temporary string creation removed from quantity::op<<()
      •  
    • perf: value initialization for quantity value removed (left with a default initialization)
      •  
    • perf: limited the equivalent trait usage
      •  
    • perf: limited the C++ Standard Library headers usage
      •  
    • perf: rvalue references support added for constructors and getters
      •  
    • (!) fix: exp() has sense only for dimensionless quantities
      •  
    • (!) fix: dim_torque now properly divides by an angle (instead of multiply) + default unit name change
      •  
    • fix: quantity's operators fixed to behave like the underlying types do
      •  
    • fix: quantity_cast() fixed to work correctly with representation types not convertible from std::intmax_t
      •  
    • fix: ambiguous case for empty type list resolved
      •  
    • fix: downcasting facility for non-default-constructible types
      •  
    • fix: restore user-warnings within the library implementation
      •  
    • fix: the text symbol of foot_pound_force and foot_pound_force_per_second
      •  
    • fix: quantity modulo arithmetics fixed
      •  
    • (!) build: Conan testing version is now hosted on Artifactory
      •  
    • (!) build: Linear Algebra is now hosted on its Artifactory
      •  
    • (!) build: BUILD_DOCS CMake option renamed to UNITS_BUILD_DOCS
      •  
    • build: doxygen updated to 1.8.20
      •  
    • build: catch2 updated to 2.13.4
      •  
    • build: fmt updated to 7.1.3
      •  
    • build: ms-gsl replaced with gsl-lite/0.38.0
      •  
    • build: Conan generator switched to cmake_find_package_multi
      •  
    • build: Conan CMakeToolchain support added
      •  
    • build: CMake scripts cleanup
      •  
    • build: ccache support added
      •  
    • ci: CI switched from Travis CI to GitHub Actions
      •  
    "},{"location":"release_notes/#0.6.0","title":"0.6.0 September 13, 2020","text":"
       
    • feat: quantity_point support added (thanks @johelegp)
      •  
    • feat: Added angle as SI base dimension (thanks @kwikius)
      •  
    • feat: si::angular_velocity support added (thanks @mikeford3)
      •  
    • feat: FPS system added (thanks @mikeford3)
      •  
    • feat: Added support for mathematical function exp(quantity)
      •  
    • feat: Localization support for text output added (thanks @rbrugo)
      •  
    • feat: Added STL random number distribution wrappers (thanks @yasamoka)
      •  
    • (!) refactor: Refactored and cleaned up the library file tree
      •  
    • (!) refactor: q_* UDL renamed to _q_*
      •  
    • (!) refactor: UDLs with \"per\" in name renamed from *p* to *_per_*
      •  
    • (!) refactor: ratio changed to the NTTP kind
      •  
    • (!) refactor: exp and Exp renamed to exponent and Exponent
      •  
    • (!) refactor: Scalar concept renamed to ScalableNumber
      •  
    • (!) refactor: Dimensionless quantities redesigned to be of a quantity type
      •  
    • refactor: math.h function signatures refactored to use a Quantity concept (thanks @kwikius)
      •  
    • refactor: [[nodiscard]] added to many functions
      •  
    • fix: si::day unit symbol fixed to d (thanks @komputerwiz)
      •  
    • fix: si::mole unit symbol fixed to mol (thanks @mikeford3)
      •  
    • (!) build: gcc-9 is no longer supported (at least gcc-10 is required)
      •  
    • build: Visual Studio 16.7 support added
      •  
    • build: linear_algebra updated to 0.7.0/stable
      •  
    • build: fmt updated to 7.0.3
      •  
    • build: range-v3 updated to 0.11.0
      •  
    • build: catch2 updated to 2.13.0
      •  
    • build: doxygen updated to 1.8.18
      •  
    • build: ms-gsl 3.1.0 dependency added
      •  
    • build: Removed the dependency on a git submodule with common CMake scripts
      •  
    "},{"location":"release_notes/#0.5.0","title":"0.5.0 May 17, 2020","text":"
       
    • Major refactoring and rewrite of the library
      •  
    • Units are now independent from dimensions
      •  
    • Dimensions now depend on units (base or coherent units are provided in a class template)
      •  
    • Quantity gets a Dimension template parameter again (as unit does not provide information about   its dimension anymore)
      •  
    • Spaceship operator support added
      •  
    • Added official CGS system support
      •  
    • Added official data information system support
      •  
    • Repository file tree cleanup
      •  
    • ratio refactored to contain Exp template parameter (thanks a lot @oschonrock!)
      •  
    • SI fundamental constants added
      •  
    • q_ prefix applied to all the UDLs (thanks @kwikius)
      •  
    • unknown_unit renamed to unknown_coherent_unit
      •  
    • Project documentation greatly extended and switched to Sphinx
      •  
    • A few more usage examples added
      •  
    • ASCII-only output support added (thanks @yasamoka)
      •  
    • Representation values formatting extended (thanks @rbrugo)
      •  
    • Output streams formatting support added
      •  
    • Linear algebra from std::experimental::math support added
      •  
    • Named SI units and their dimensions added (thanks @rbrugo
      •  
    • libfmt updated to 6.2.0
      •  
    • Added absolute functions and epsilon to math.h (thanks @mikeford3)
      •  
    • Added a lot of prefixes to named units and introduced alias_unit (thanks @yasamoka)
      •  
    • Linking with Conan targets only when they exists (#98)
      •  
    • All physical dimensions and units put into physical namespace
      •  
    • CMake improvements
      •  
    • Velocity renamed to speed
      •  
     
    Many thanks to GitHub users @oschonrock, @kwikius, and @i-ky for their support in drafting a new library design.
    "},{"location":"release_notes/#0.4.0","title":"0.4.0 Nov 17, 2019","text":"
       
    • Support for derived dimensions in exp added
      •  
    • Added pow() and sqrt() operations on quantities
      •  
    • units removed from a std::experimental namespace
      •  
    • Downcasting facility refactored so the user does not have to write the boilerplate code anymore
      •  
    • From now on base dimensions should inherit from base_dimension class template
      •  
    • Added unit symbols definitions to base_dimension and derived units
      •  
    • Added support for operator<< on quantity
      •  
    • fmt support added
      •  
    • Derived unit factory helpers refactored
      •  
    • Refactored the way prefixed units are defined
      •  
    "},{"location":"release_notes/#0.3.1","title":"0.3.1 Sep 18, 2019","text":"
       
    • cmcstl2 dependency changed to range-v3 0.9.1
      •  
    "},{"location":"release_notes/#0.3.0","title":"0.3.0 Sep 16, 2019","text":"
       
    • The design as described on CppCon 2019 talk (https://youtu.be/0YW6yxkdhlU)
      •  
    • Applied the feedback from the Cologne evening session
      •  
    • upcasting_traits renamed to downcasting_traits
      •  
    • Dimension template parameter removed from quantity
      •  
    • units moved to a std::experimental namespace
      •  
    • Leading underscore prefix removed from UDLs
      •  
    • Added a few more derived dimensions
      •  
    • meter renamed to metre
      •  
    • Missing operator* added
      •  
    • Predefined dimensions moved to a dedicated directory
      •  
    • dimension_ prefix removed from names of derived dimensions
      •  
    • cmcstl2 library updated to 2019.09.19
      •  
    • base_dimension is a value provided as const& to the exp type
      •  
    • integrated with Compiler Explorer
      •  
    • gsl-lite dependency removed
      •  
    • Fractional dimension exponents support added
      •  
    • QuantityOf concept introduced
      •  
    • quantity_cast<U, Rep>() support added
      •  
    "},{"location":"release_notes/#0.2.0","title":"0.2.0 July 18, 2019","text":"
       
    • The design as described on C++Now 2019 talk (https://youtu.be/wKchCktZPHU)
      •  
    • Added C++20 features supported by gcc-9.1 (std::remove_cvref_t, down with typename, std::type_identity)
      •  
    • Compile-time performance optimizations (type_list, common_ratio, ratio, conditional_t)
      •  
    "},{"location":"release_notes/#0.1.0","title":"0.1.0 May 18, 2019","text":"
       
    • Initial library release
      •  
    • Begin semantic versioning
      •  
    • The last version to work with gcc-8
      •  
    "},{"location":"appendix/glossary/","title":"Glossary","text":""},{"location":"appendix/glossary/#iso-definitions","title":"ISO definitions","text":"
    Note
     
    The ISO terms provided below are only a few of many defined in the ISO/IEC Guide 99.
     quantity 
       
    • Property of a phenomenon, body, or substance, where the property has a magnitude that can   be expressed by means of a number and a reference.
      •  
    • A reference can be a measurement unit, a measurement procedure, a reference material,   or a combination of such.
      •  
    • A quantity as defined here is a scalar. However, a vector or a tensor, the components of   which are quantities, is also considered to be a quantity.
      •  
    • The concept \u2019quantity\u2019 may be generically divided into, e.g. \u2018physical quantity\u2019,   \u2018chemical quantity\u2019, and \u2018biological quantity\u2019, or \u2018base quantity\u2019   and \u2018derived quantity\u2019.
      •  
    • Examples of quantities are: length, radius, wavelength, energy, electric charge, etc.
      •  
     kind of quantity, kind 
       
    • Aspect common to mutually comparable quantities.
      •  
    • The division of the concept \u2018quantity\u2019 into several kinds is to some extent arbitrary, for example:
         
      • the quantities diameter, circumference, and wavelength are generally considered   to be quantities of the same kind, namely, of the kind of quantity called length,
        •  
      • the quantities heat, kinetic energy, and potential energy are generally considered   to be quantities of the same kind, namely of the kind of quantity called energy.
        •  
       
      •  
    • Quantities of the same kind within a given system of quantities   have the same quantity dimension. However, quantities   of the same dimension are not necessarily of the same kind.
         
      • For example, the quantities moment of force and energy are, by convention, not regarded   as being of the same kind, although they have the same dimension. Similarly for   heat capacity and entropy, as well as for number of entities, relative permeability,   and mass fraction.
        •  
       
      •  
     system of quantities 
       
    • Set of quantities together with a set of non-contradictory equations   relating those quantities.
      •  
    • Examples of systems of quantities are: the International System of Quantities,   the Imperial System, etc.
      •  
     base quantity 
       
    • Quantity in a conventionally chosen subset of a given   system of quantities, where no quantity in the   subset can be expressed in terms of the others.
      •  
    • Base quantities are referred to as being mutually independent since a base quantity   cannot be expressed as a product of powers of the other base quantities.
      •  
    • \u2018Number of entities\u2019 can be regarded as a base quantity in any   system of quantities.
      •  
     derived quantity 
       
    • Quantity, in a system of quantities, defined in   terms of the base quantities of that system.
      •  
     International System of Quantities, ISQ 
       
    • System of quantities based on the seven base quantities:   length, mass, time, electric current, thermodynamic temperature, amount of substance,   and luminous intensity.
      •  
    • This system of quantities is published in the ISO 80000 and IEC 80000 series Quantities and units.
      •  
    • The International System of Units (SI) is based on the ISQ.
      •  
     quantity dimension, dimension of a quantity, dimension 
       
    • Expression of the dependence of a quantity on the base quantities   of a system of quantities as a product of powers of factors corresponding   to the base quantities, omitting any numerical factor.
         
      • e.g. in the ISQ, the quantity dimension of force is denoted by \\(\\textsf{dim }F = \\mathsf{LMT}^{\u20132}\\).
        •  
       
      •  
    • A power of a factor is the factor raised to an exponent. Each factor is the dimension   of a base quantity.
      •  
    • In deriving the dimension of a quantity, no account is taken of its scalar, vector, or   tensor character.
      •  
    • In a given system of quantities:
         
      • quantities of the same kind have the same quantity dimension,
        •  
      • quantities of different quantity dimensions are always of different kinds,
        •  
      • quantities having the same quantity dimension are not necessarily of the same   kind.
        •  
       
      •  
    •  
      Symbols representing the dimensions of the base quantities in the ISQ are:
       Base quantity Symbol for dimension length \\(\\mathsf{L}\\) mass \\(\\mathsf{M}\\) time \\(\\mathsf{T}\\) electric current \\(\\mathsf{I}\\) thermodynamic temperature \\(\\mathsf{\u0398}\\) amount of substance \\(\\mathsf{N}\\) luminous intensity \\(\\mathsf{J}\\) 
      Thus, the dimension of a quantity \\(Q\\) is denoted by \\(\\textsf{dim }Q = \\mathsf{L}^\u03b1\\mathsf{M}^\u03b2\\mathsf{T}^\u03b3\\mathsf{I}^\u03b4\\mathsf{\u0398}^\u03b5\\mathsf{N}^\u03b6\\mathsf{J}^\u03b7\\) where the exponents, named dimensional exponents, are positive, negative, or zero.
       
      •  
     quantity of dimension one, dimensionless quantity 
       
    • quantity for which all the exponents of the factors corresponding to the     base quantities in its quantity dimension are zero.
      •  
    • The term \u201cdimensionless quantity\u201d is commonly used and is kept here for historical     reasons. It stems from the fact that all exponents are zero in the symbolic     representation of the dimension for such quantities.     The term \u201cquantity of dimension one\u201d reflects the convention in which the symbolic     representation of the dimension for such quantities is     the symbol \\(1\\).
      •  
    • The measurement units and values of quantities of     dimension one are numbers, but such quantities convey more information than a number.
      •  
    • Some quantities of dimension one are defined as the ratios of two     quantities of the same kind.
      •  
    • Numbers of entities are quantities of dimension one.
      •  
     measurement unit, unit of measurement, unit 
       
    • Real scalar quantity, defined and adopted by convention, with which any other   quantity of the same kind can be compared to express the ratio of the two   quantities as a number.
      •  
    • Measurement units are designated by conventionally assigned names and symbols.
      •  
    • Measurement units of quantities of the same quantity dimension   may be designated by the same name and symbol even when the quantities are   not of the same kind.
         
      • For example, joule per kelvin and J/K are respectively the name and symbol of both a   measurement unit of heat capacity and a measurement unit of entropy, which are generally   not considered to be quantities of the same kind.
        •  
       
      •  
    • However, in some cases special measurement unit names are restricted to be used with   quantities of specific kind only.
         
      • For example, the measurement unit \u2018second to the power minus one\u2019   (\\(\\mathsf{1/s}\\)) is called hertz (\\(\\mathsf{Hz}\\)) when used for frequencies and   becquerel (\\(\\mathsf{Bq}\\)) when used for activities of radionuclides. As another example,   the joule (\\(\\mathsf{J}\\)) is used as a unit of energy, but never as a unit of moment of   force, e.g. the newton metre (\\(\\mathsf{N\u00b7m}\\)).
        •  
       
      •  
    • Measurement units of quantities of dimension one are   numbers. In some cases, these measurement units are given special names, e.g. radian,   steradian, and decibel, or are expressed by quotients such as millimole per mole equal   to \\(10^{\u22123}\\) and microgram per kilogram equal to \\(10^{\u22129}\\).
      •  
     base unit 
       
    • Measurement unit that is adopted by convention for a base quantity.
      •  
    • In each coherent system of units, there is only one base unit   for each base quantity.
         
      • e.g. in the SI, the metre is the base unit of length. In the CGS systems,   the centimetre is the base unit of length.
        •  
       
      •  
    • A base unit may also serve for a derived quantity of the same   quantity dimension.
      •  
    • For number of entities, the number one, symbol \\(1\\), can be regarded as a base unit in   any system of units.
      •  
     derived unit 
       
    • Measurement unit for a derived quantity.
      •  
    • For example, the metre per second, symbol m/s, and the centimetre per second, symbol cm/s,   are derived units of speed in the SI. The kilometre per hour, symbol km/h, is a   measurement unit of speed outside the SI but accepted for use with   the SI. The knot, equal to one nautical mile per hour, is a measurement unit of speed   outside the SI.
      •  
     coherent derived unit 
       
    • Derived unit that, for a given system of quantities   and for a chosen set of base units, is a product of powers of   base units with no other proportionality factor than one.
      •  
    • A power of a base unit is the base unit raised to an exponent.
      •  
    • Coherence can be determined only with respect to a particular   system of quantities and a given set of base units.
         
      • For example, if the metre, the second, and the mole are base units, the metre per second is   the coherent derived unit of velocity when velocity is defined by the   quantity equation \\(v = \\mathsf{d}r/\\mathsf{d}t\\), and the mole per   cubic metre is the coherent derived unit of amount-of-substance concentration when   amount-of-substance concentration is defined by the quantity equation \\(c = n/V\\). The kilometre per hour and the knot, given as examples of derived units,   are not coherent derived units in such a system of quantities.
        •  
       
      •  
    • A derived unit can be coherent with respect to one   system of quantities but not to another.
         
      • For example, the centimetre per second is the coherent derived unit of speed in a CGS system   of units but is not a coherent derived unit in the SI.
        •  
       
      •  
    • The coherent derived unit for every derived quantity of dimension one   in a given system of units is the number one, symbol \\(1\\). The name and   symbol of the measurement unit one are generally not indicated.
      •  
     system of units 
       
    • Set of base units and derived units, together with   their multiples and submultiples, defined in accordance with given rules, for a given   system of quantities.
      •  
     coherent system of units 
       
    • System of units, based on a given system of quantities,   in which the measurement unit for each derived quantity is   a coherent derived unit.
      •  
    • A system of units can be coherent only with respect to a   system of quantities and the adopted base units.
      •  
    • For a coherent system of units, numerical value equations have   the same form, including numerical factors, as the corresponding   quantity equations.
      •  
     off-system measurement unit, off-system unit 
       
    • Measurement unit that does not belong to a given system of units.
      •  
    • For example, the electronvolt (about \\(1.602\\;18 \u00d7 10^{\u201319}\\;\\mathsf{J}\\)) is an   off-system measurement unit of energy with respect to the SI. Day, hour, minute   are off-system measurement units of time with respect to the SI.
      •  
     International System of Units, SI 
       
    • System of units, based on the International System of Quantities,   their names and symbols, including a series of prefixes and their names and symbols,   together with rules for their use, adopted by the General Conference on Weights and   Measures (CGPM).
      •  
     quantity value, value of a quantity, value 
       
    • Number and reference together expressing magnitude of a quantity.
         
      • For example, length of a given rod: \\(5.34\\;\\mathsf{m}\\) or \\(534\\;\\mathsf{cm}\\).
        •  
       
      •  
    • The number can be complex.
      •  
    • A quantity value can be presented in more than one way.
      •  
    • In the case of vector or tensor quantities, each component has a quantity value.
         
      • For example, force acting on a given particle, e.g. in Cartesian components   \\((F_x; F_y; F_z) = (\u221231.5; 43.2; 17.0)\\;\\mathsf{N}\\).
        •  
       
      •  
     numerical quantity value, numerical value of a quantity, numerical value 
       
    • Number in the expression of a quantity value, other than any number serving   as the reference
         
      • For example, in an amount-of-substance fraction equal to \\(3\\;\\mathsf{mmol/mol}\\), the numerical   quantity value is \\(3\\) and the unit is \\(\\mathsf{mmol/mol}\\). The unit \\(\\mathsf{mmol/mol}\\) is numerically equal to \\(0.001\\), but this number \\(0.001\\) is not part   of the numerical quantity value, which remains \\(3\\).
        •  
       
      •  
     quantity equation 
       
    • Mathematical relation between quantities in a given system of quantities,   independent of measure\u00adment units.
      •  
    • For example, \\(T = (1/2) mv^2\\) where \\(T\\) is the kinetic energy and \\(v\\) the speed   of a specified particle of mass \\(m\\).
      •  
     unit equation 
       
    • Mathematical relation between base units,   coher\u00adent derived units or other measurement units.
      •  
    • For example, \\(\\mathsf{J} := \\mathsf{kg}\\:\\mathsf{m}^2/\\mathsf{s}^2\\), where, \\(\\mathsf{J}\\),   \\(\\mathsf{kg}\\), \\(\\mathsf{m}\\), and \\(\\mathsf{s}\\) are the symbols for the joule, kilogram,   metre, and second, respectively. (The symbol \\(:=\\) denotes \u201cis by definition equal to\u201d   as given in the ISO 80000 and IEC 80000 series.). \\(1\\;\\mathsf{km/h} = (1/3.6)\\;\\mathsf{m/s}\\).
      •  
     numerical value equation, numerical quantity value equation 
       
    • Mathematical relation between numerical quantity values, based on   a given quantity equation and specified measurement units.
      •  
    • For example, in the quantity equation for kinetic energy of a particle,   \\(T = (1/2) mv^2\\), if \\(m = 2\\;\\mathsf{kg}\\) and \\(v = 3\\;\\mathsf{m/s}\\),   then \\({T} = (1/2)\\:\u00d7\\:2\\:\u00d7\\:3^2\\) is a numerical value equation giving the numerical value   \\(9\\) of \\(T\\) in joules.
      •  
    "},{"location":"appendix/glossary/#other-definitions","title":"Other definitions","text":"
    Info
     
    The below terms extend the official ISO glossary and are commonly referred to by the mp-units library.
     base dimension 
       
    • A dimension of a base quantity.
      •  
     derived dimension 
       
    • A dimension of a derived quantity.
      •  
    • Implemented as a symbolic expression being the result of the   dimension equation on base dimensions.
      •  
     dimension equation 
       
    • Mathematical relation between dimensions in a given   system of quantities, independent of measure\u00adment units.
      •  
     quantity kind hierarchy, quantity hierarchy 
       
    • Quantities of the same kind form a hierarchy that determines their:
         
      • convertibility (e.g. every width is a length, but width should not be   convertible to height)
        •  
      • common quantity type (e.g. width + height -> length)
        •  
       
      •  
     quantity character, character of a quantity, character 
       
    • Scalars, vectors and tensors are mathematical objects that can be used to denote   certain physical quantities and their values.   They are as such independent of the particular choice of a coordinate system,   whereas each scalar component of a vector or a tensor and each component vector   and component tensor depend on that choice.
      •  
    • A vector is a tensor of the first order and a scalar is a tensor of order zero.
      •  
    • For vectors and tensors, the components are quantities that can be   expressed as a product of a number and a unit.
      •  
    • Vectors and tensors can also be expressed as a numerical value vector or tensor,   respectively, multiplied by a unit.
      •  
    • Quantities of different characters support different set of operations.
         
      • For example, a quantity can be multiplied by another one only if any   of them has scalar character. Vectors and tensors can't be multiplied or divided,   but they support additional operations like dot and cross products, which   are not available for scalars.
        •  
       
      •  
    • The term \u2019character\u2019 was borrowed from the below quote:
      •  
     
    ISO 80000-1_2009
     
    In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
     quantity specification, quantity_spec 
       
    • An entity storing all the information about a specific quantity:
         
      • location in a quantity hierarchy
        •  
      • quantity equation
        •  
      • dimension of a quantity
        •  
      • quantity kind
        •  
      • quantity character
        •  
      • additional constraints (e.g. non-negative)
        •  
       
      •  
    • Dimension of a quantity is not enough to specify all the properties of   a quantity.
      •  
     unit with an associated quantity, associated unit 
       
    • Unit that is used to measure quantities of a specific kind in a given   system of units.
      •  
     quantity reference, reference 
       
    • According to its definition, quantity can be expressed by means of   a number and a reference
      •  
    • In the mp-units library, a reference describes all the required meta-information   associated with a specific quantity (quantity specification and   unit).
      •  
     canonical representation of a unit, canonical unit 
       
    • A canonical representation of a unit consists of:
         
      • a reference unit being the result of extraction of all the intermediate   derived units,
        •  
      • a magnitude being a product of all the prefixes and magnitudes of extracted scaled units.
        •  
       
      •  
    • All units having the same canonical unit are deemed equal.
      •  
    • All units having the same reference unit are convertible   (their magnitude may differ and is used during conversion).
      •  
     reference unit 
    See canonical representation of a unit
     absolute quantity point origin, absolute point origin 
       
    • An explicit point on an axis of values of a specific quantity type that serves   as an absolute reference point for all quantity points which definitions   are (explicitly or implicitly) based on it.
      •  
    • For example, mean sea level is commonly used as an absolute reference point to measure altitudes.
      •  
     relative quantity point origin, relative point origin 
       
    • An explicit, known at compile-time, point on an axis of values of a specific quantity   type serving as a reference for other quantities.
      •  
    • For example, an ice point is a quantity point with a value of \\(273.15\\;\\mathsf{K}\\) that   is used as the zero point of a degree Celsius scale.
      •  
     quantity point origin, point origin 
       
    • Either an absolute point origin or   a relative point origin.
      •  
     quantity point, absolute quantity 
       
    • An absolute quantity with respect to an origin.
      •  
    • For example, timestamp (as opposed to duration), altitude (as opposed to height),   absolute temperature (as opposed to temperature difference).
      •  
    "},{"location":"appendix/references/","title":"References","text":"ISO80000 
    ISO 80000-1:2009(E) \"Quantities and units \u2014 Part 1: General\", International Organization for Standardization.
     Quincey \"Angles in the SI: a detailed proposal for solving the problem, Quincey, Paul (1 October 2021). SIBrochure 
    The International System of Units (SI), International Bureau of Weights and Measures (20 May 2019), ISBN 978-92-822-2272-0.
    "},{"location":"blog/","title":"Blog","text":""},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/","title":"What's new in mp-units 2.0?","text":"
    After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from GitHub and Conan.
     
    The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe some of them in this post.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#why-20-if-10-was-never-released","title":"Why 2.0 if 1.0 was never released?","text":"
    Version 2 of the mp-units project is a huge change and a new quality for the users. We did not want to pretend that 2.0 is an evolutionary upgrade of the previous version of the project. It feels like a different product.
     
    We could start a new repo named \"mp-units-v2\" similarly to range-v3 but we decided not to go this path. We kept the same repo and made the scope of the changes and potential breakage explicit with a drastic bump in the project version.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-has-changed","title":"What has changed?","text":"
    The answer is \"nearly everything\". The whole library and its documentation were rewritten nearly from scratch.
     
    Here are the significant changes that the users can observe:
     
       
    •  
      Repository name
       
      If you didn't notice, the repository name was changed from \"mpusz/units\" to \"mpusz/mp-units\".
       
      •  
    •  
      Header files content and layout
       
      Previously, all the header files resided in the include/units directory. Now, they can be found in include/mp-units. The project file tree was significantly changed as well. Many files were moved to different subdirectories or renamed.
       
      •  
    •  
      Namespace
       
      Previously, all the definitions were provided in the units namespace, and now they are in the mp_units one.
       
      •  
    •  
      Abstractions, interfaces, definitions
       
      The interfaces of all of the types were refactored. We got unit symbols and a new way to construct a quantity and quantity_point. The readability of the generated types was improved thanks to the introduction of expression templates. Nearly all of the template arguments are now passed by values thanks to class NTTP extensions in C++20. As a result, unit definitions are much easier and terser. Also, the V2 has a powerful ability to model systems of quantities and provides definitions for many ISQ quantities.
       
      •  
    •  
      Conan 2.0
       
      Also, now we support Conan 2.0, which provides an updated way of handling dependencies.
       
      •  
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-is-gone","title":"What is gone?","text":"
    Some cornerstones of the initial design did not prove in practice and were removed while we moved to version 2.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#the-downcasting-facility","title":"The downcasting facility","text":"
    The first and the most important of such features was removing the downcasting facility. This feature is still a powerful metaprogramming technique that allows users to map long class template instantiations to nicely named, short, and easy-to-understand user's strong types.
     
    Such mapping works perfectly fine for 1-to-1 relationships. However, we often deal with N-to-1 connections in the quantities and units domain. Here are only a few such examples:
     
       
    • work and torque have the same dimension \\(L^2MT^{-2}\\),
      •  
    • becquerel and hertz have the same definition of \\(s^{-1}\\),
      •  
    • litre and cubic decimetre have the same factor.
      •  
     
    In the above examples, multiple entities \"wanted\" to register different names for identical class template instantiations, resulting in compile-time errors. We had to invent some hacks and workarounds to make it work, but we were never satisfied with the outcome.
     
    Additionally, this facility could easily lead to ODR violations or provide different results depending on which header files were included in the translation units. This was too vulnerable to be considered a good practice here.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-udls-anymore","title":"No UDLs anymore","text":"
    Over the years, we have learned that UDLs are not a good solution. More information on this subject can be found in the Why don't we use UDLs to create quantities? chapter.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-construction-of-a-quantity-from-a-raw-value","title":"No construction of a quantity from a raw value","text":"
    To improve safety, we no longer allow the construction of quantities from raw values. In the new design, we always need to explicitly specify a unit to create a quantity:
     
    quantity q1 = 42 * m;\nquantity<si::metre> = 2 * km;\nquantity q3(42, si::metre);\n
     
    The previous approach was reported to be error-prone under maintenance. More on this subject can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#new-look-and-feel","title":"New look and feel","text":"
    Here is a concise example showing you the new look and feel of the library:
     
    #include <mp-units/format.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n#include <format>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity<isq::speed[m / s]> avg_speed(quantity<si::metre> d,\n                                      quantity<si::second> t)\n{ return d / t; }\n\nint main()\n{\n  auto speed = avg_speed(220 * km, 2 * h);\n  std::println(\"{}\", speed);  // 30.5556 m/s\n}\n
     
    All of the changes we provided, although breaking ones, resulted in much better, easier, and safer abstractions. These offer a new quantity on the market and hopefully will be appreciated by our users.
     
    Please check our new documentation to learn about the latest version of the project and find out how to benefit from all the new cool stuff we have here.
    "},{"location":"blog/2023/12/09/mp-units-210-released/","title":"mp-units 2.1.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe the most important of them in this post.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#no-more-parenthesis-while-creating-quantities-with-derived-units","title":"No more parenthesis while creating quantities with derived units","text":"
    The V2 design introduced a way to create a quantity by multiplying a raw value and a unit:
     
    quantity q1 = 42 * m;\n
     
    However, this meant that when we wanted to create a quantity having a derived unit, we had to put parenthesis around the unit equation or create a custom value of the named unit:
     
    quantity q2 = 60 * (km / h);\n\nconstexpr auto kmph = km / h;\nquantity q3 = 60 * kmph;\n\nquantity q4 = 50 * (1 / s);\n
     
    With the new version, we removed this restriction, and now we can type:
     
    quantity q5 = 60 * km / h;\nquantity q6 = 50 / s;\n
     
    As a side effect, we introduced a  breaking change . We can't use the following definition of hertz anymore:
     
    inline constexpr struct hertz : named_unit<\"Hz\", 1 / second, kind_of<isq::frequency>> {} hertz;\n
     
    and have to type either:
     
    inline constexpr struct hertz : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\n
     
    or
     
    inline constexpr struct hertz : named_unit<\"Hz\", inverse(second), kind_of<isq::frequency>> {} hertz;\n
     
    To be consistent, we applied the same change to the dimensions and quantity specifications definitions. Now, to define a frequency we have to type:
     C++23C++20Portable 
    inline constexpr struct frequency : quantity_spec<inverse(period_duration)> {} frequency;\n
     
    inline constexpr struct frequency : quantity_spec<frequency, inverse(period_duration)> {} frequency;\n
     
    QUANTITY_SPEC(frequency, inverse(period_duration));\n
    "},{"location":"blog/2023/12/09/mp-units-210-released/#make_xxx-factory-functions-replaced-with-two-parameter-constructors","title":"make_xxx factory functions replaced with two-parameter constructors","text":"
    In the initial version of the V2 framework, if someone did not like the multiply syntax to create a quantity we provided the make_quantity() factory function. A similar approach was used for quantity_point creation.
     
    This version removes those ( breaking change ) and introduces two parameter constructors:
     
    quantity q(42, si::metre);\nquantity_point qp(q, mean_sea_level);\n
     
    The above change encourages a better design and results in a terser code.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#improved-definitions-of-becquerel-gray-and-sievert","title":"Improved definitions of becquerel, gray, and sievert","text":"
    In the initial V2 version, we lacked the definitions of the atomic and nuclear physics quantities, which resulted in simplified and unsafe definitions of becquerel, gray, and sievert units. We still do not model most of the quantities from this domain, but we've added the ones that are necessary for the definition of those units.
     
    Thanks to the above, the following expressions will not compile:
     
    quantity q1 = 1 * Hz + 1 * Bq;\nquantity<si::sievert> q2 = 42 * Gy;\n
    "},{"location":"blog/2023/12/09/mp-units-210-released/#compatibility-with-other-libraries-redesigned","title":"Compatibility with other libraries redesigned","text":"
    Another significant improvement in this version was redesigning the way we provide compatibility with other similar libraries. The interfaces of quantity_like_traits and quantity_point_like_traits were changed and extended to provide conversion not only from but also to entities from other libraries ( breaking change ).
     
    We've also introduced an innovative approach that allows us to specify if such conversions should happen implicitly or if they need to be forced explicitly.
     
    More on this subject can be found in the Interoperability with Other Libraries chapter.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#point-origins-can-now-be-derived-from-each-other","title":"Point origins can now be derived from each other","text":"
    Previously, each class derived from absolute_point_origin was considered a unique independent point origin. On the other hand, it was OK to derive multiple classes from the same relative_point_origin, and those were specifying the same point in the domain. We found this confusing and limiting. This is why, in this version, the absolute_point_origin uses a CRTP idiom to be able to detect between points that should be considered different from the ones that should be equivalent.
     
    If we derive from the same instantiation of absolute_point_origin we end up with an equivalent point origin. This change allows us to provide different names for the same temperature points:
     
    inline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<absolute_zero + 273.15 * kelvin> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\n
     
    Please note that this is a  breaking change  as well.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#unit-symbol-text-can-now-be-properly-used-at-runtime","title":"Unit symbol text can now be properly used at runtime","text":"
    The interface of the previous definition of unit_symbol function allowed the use of the returned buffer only at compile-time. This was too limiting as users often want to use unit symbols at runtime (e.g., print them to the console). The new version redesigned the interface of this function ( breaking change ) to return a buffer that can be properly used at both compilation and runtime:
     
    std::string_view unit1 = unit_symbol(m / s);\nstd::cout << unit1 << \"\\n\";     // m/s\nstd::string_view unit2 = unit_symbol<{.solidus = unit_symbol_solidus::never}>(m / s);\nstd::cout << unit2 << \"\\n\";     // m s\u207b\u00b9\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/","title":"mp-units 2.2.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    Among other features, this release provides long-awaited support for C++20 modules, redesigns and enhances text output formatting, and greatly simplifies quantity point usage. This post describes those and a few other smaller interesting improvements, while a much longer list of the most significant changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#c20-modules-and-project-structure-cleanup","title":"C++20 modules and project structure cleanup","text":"
    GitHub Issue #7 was our oldest open issue before this release. Not anymore. After 4.5 years, we finally closed it, even though the C++ modules' support is still really limited.
     
    Info
     
    To benefit from C++ modules, we need at least:
     
       
    • CMake 3.29.3
      •  
    • Ninja 1.11
      •  
    • clang-17
      •  
     
    In the upcoming months, hopefully, the situation will improve with the bug fixes in CMake, gcc-14, and MSVC.
     
    Note
     
    More requirements for C++ modules support can be found in the CMake's documentation.
     
    To enable the compilation and distribution of C++ modules, a cxx_modules Conan or MP_UNITS_BUILD_CXX_MODULES CMake option has to be enabled.
     
    With the above, the following C++ modules will be provided:
     
    flowchart TD\n    mp_units --- mp_units.systems --- mp_units.core
     C++ Module CMake Target Contents mp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems 
    The easiest way to use them is just to import mp_units; at the beginning of your translation unit (see the Quick Start chapter for some usage examples).
     
    Note
     
    C++20 modules support still have some issues when imported from the installed CMake target. See the following GitLab issue for more details.
     
    In this release, we also highly limited the number of CMake targets ( breaking change ). Now, they correspond exactly to the C++ modules they provide. This means that many smaller partial targets were removed. We also merged text output targets with the core library's definition.
     
    The table below specifies where we can now find the contents of previously available CMake targets:
     Before Now mp-units::utility mp-units::core mp-units::core-io mp-units::core mp-units::core-fmt mp-units::core mp-units::{system_name} mp-units::systems 
    While we were enabling C++ modules, we also had to refactor our header files slightly ( breaking change ). Some had to be split into smaller pieces (e.g., math.h), while others had to be moved to a different subdirectory (e.g., chrono.h).
     
    In version 2.2, the following headers have a new location or contents:
     Header File C++ Module Contents mp-units/math.h mp_units.core System-independent functions only mp-units/systems/si/math.h mp_units.systems Trigonometric functions using si::radian mp-units/systems/angular/math.h mp_units.systems Trigonometric functions using angular::radian mp-units/systems/si/chrono.h mp_units.systems std::chrono compatibility traits 
    Benefiting from this opportunity, we also cleaned up core and systems definitions ( breaking change ).
     
    Regarding the library's core, we removed core.h and exposed only one header framework.h that provides all of the library's framework so the user does not have to enumerate files like unit.h, quantity.h, and quantity_point.h anymore. Those headers are not gone, they were put to the mp-units/framework subheader. So they are still there if you really need them.
     
    Regarding the changes in systems definitions, we moved the wrapper header files with the entire system definition to the mp-units/systems subdirectory. Additionally, they now also include framework.h, so a system include is enough to use the library. Thanks to that our users don't have to write tedious code like the below anymore:
     NowBefore 
    #include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n\n// ...\n
     
    #include <mp-units/quantity_point.h>\n#include <mp-units/systems/cgs/cgs.h>\n#include <mp-units/systems/international/international.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n\n// ...\n
     
    Additionally, we merged all of the compatibility-related macros into one header file mp-units/compat_macros.h. This header file should be explicitly included before importing C++ modules if we want to benefit from the Wide Compatibility tools.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#better-control-over-the-librarys-api","title":"Better control over the library's API","text":"
    With this release, nearly all of the Conan and CMake build options were refactored with the intent of providing better control over the library's API.
     
    Previously, the library used the latest available feature set supported by a specific compiler. For example, quantity_spec definitions would use CRTP on an older compiler or provide a simpler API on a newer one thanks to the C++23 this deduction feature. This could lead to surprising results where the same code written by the user would compile fine on one compiler but not the other.
     
    From this release, all API extensions have their corresponding configuration options in Conan and CMake. With this, a user has full control over the API exposed by the library. Those options expose three values:
     
       
    • True - The feature is always enabled (the configuration error will happen if the compiler does   not support this feature)
      •  
    • False - The feature is disabled, and an older alternative is always used.
      •  
    • Auto - The feature is automatically enabled if the compiler supports it (old behavior).
      •  
     
    Additionally, some CMake options were renamed to better express the impact on our users ( breaking change ). For example, now CMake options include:
     
       
    • MP_UNITS_API_* - options affecting the library's API,
      •  
    • MP_UNITS_BUILD_* - options affecting the build process,
      •  
    • MP_UNITS_DEV_* - options primarily useful for the project developers or people who want to   compile our unit tests and examples.
      •  
    "},{"location":"blog/2024/06/14/mp-units-220-released/#configurable-contracts-checking","title":"Configurable contracts checking","text":"
    Before this release, the library always depended on gsl-lite to perform runtime contract and asserts checking. In this release we introduced new options to control if contract checking should be based on gsl-lite, ms-gsl, or may be completely disabled.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#freestanding-support","title":"Freestanding support","text":"
    From this release it is possible to configure the library in the freestanding mode. This limits the functionality and interface of the library to be compatible with the freestanding implementations.
     
    Info
     
    To learn more, please refer to the Build options chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#simplified-quantity-point-support","title":"Simplified quantity point support","text":"
    This release significantly simplifies the usage of quantity points and affine space abstractions in general.
     
    Previously, the user always had to define an explicit point origin even if the domain being modeled does not have such an explicit origin. Now, in such cases, we can benefit from the implicit point origins. For example:
     NowBefore 
    quantity_point price_usd{100 * USD};\n
     
    constexpr struct zero final : absolute_point_origin<currency> {} zero;\n\nquantity_point price_usd = zero + 100 * USD;\n
     
    As we can see above, the new design allows direct-initializing quantity_point class template from a quantity, but only if the former one is defined in terms of the implicit point origin. Otherwise, an explicit origin still always has to be provided during initialization.
     
    Also, we introduced the possibility of specifying a default point origin in the unit definition. With that, we could provide proper temperature scales without forcing the user to always use the origins explicitly. Also, a new member function, .quantity_from_zero(), was introduced that always returns the quantity from the unit's specific point origin or from the implicit point origin otherwise.
     NowBefore 
    quantity_point temp{20 * deg_C};\nstd::cout << \"Temperature: \" << temp << \" (\"\n          << temp.in(deg_F).quantity_from_zero() << \", \"\n          << temp.in(K).quantity_from_zero() << \")\\n\";\n
     
    quantity_point temp = si::zeroth_degree_Celsius + 20 * deg_C;\nstd::cout << \"Temperature: \" << temp << \" (\"\n          << temp.in(deg_F).quantity_from(usc::zeroth_degree_Fahrenheit) << \", \"\n          << temp.in(K).quantity_from(si::zeroth_kelvin) << \")\\n\";\n
     
    More information about the new design can be found in The Affine Space chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#unified-temperature-point-origins-names","title":"Unified temperature point origins names","text":"
    By omission, we had the following temperature point origins in the library:
     
       
    • si::zero_kelvin (for si::kelvin),
      •  
    • si::zeroth_degree_Celsius (for si::degree_Celsius),
      •  
    • usc::zero_Fahrenheit (for usc::degree_Fahrenheit).
      •  
     
    With this release, the last one was renamed to usc::zeroth_degree_Fahrenheit to be consistently named with its corresponding unit and with the si::zeroth_degree_Celsius ( breaking change ).
    "},{"location":"blog/2024/06/14/mp-units-220-released/#changes-to-units-definitions","title":"Changes to units definitions","text":"
    There were several known issues when units were deriving from each other (e.g., #512 and #537). We could either highly complicate the framework to allow these which could result in much longer compilation times or disallow inheriting from units at all. We chose the second option.
     
    With this release all of of the units must be marked as final. To enforce this we have changed the definition of the Unit<T> concept, which now requires type T to be final ( breaking change ).
     
    WG21 Study Group 16 (Unicode) raised concerns about potential ABI issues when different translation units are compiled with different ordinary literal encodings. Those issues were resolved with a change to units definitions ( breaking change ). It affects only units that specify both Unicode and ASCII symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal.
     
    This also means that the basic_symbol_text has fixed character types for both symbols. This is why it was renamed to symbol_text ( breaking change ).
     NowBefore 
    inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    inline constexpr struct ohm : named_unit<basic_symbol_text{\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    Note
     
    On C++20-compliant compilers it should be enough to type the following in the unit's definition:
     
    inline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/#changes-to-dimension-quantity-specification-and-point-origins-definitions","title":"Changes to dimension, quantity specification, and point origins definitions","text":"
    Similarly to units, now also all dimensions, quantity specifications, and point origins have to be marked final ( breaking change ).
     NowBefore 
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length final : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin  = absolute_zero;\ninline constexpr struct kelvin final : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point final : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\ninline constexpr struct degree_Celsius final : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n
     
    inline constexpr struct dim_length : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\ninline constexpr struct kelvin : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\ninline constexpr struct degree_Celsius : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n
     
    Please also note, that the absolute_point_origin does not use CRTP idiom anymore ( breaking change ).
    "},{"location":"blog/2024/06/14/mp-units-220-released/#improved-text-output","title":"Improved text output","text":"
    With this release, we can print not only whole quantities but also just their units or dimensions. Also, we fixed the std::format support so users can now enjoy full C++20 compatibility and don't have to use fmtlib anymore.
     
    We have also changed the grammar for quantities formatting ( breaking change ). It introduces the composition of underlying formatters that finally allows us to properly format user-defined representation types (assuming they have std::format support). Additionally, thanks to a new %? token, we can provide a custom format string that will properly print quantity of any unit.
     
    Here is a small preview of what is now available:
     
    using namespace mp_units::si::unit_symbols;\nusing namespace mp_units::international::unit_symbols;\nquantity q = (90. * km / h).in(mph);\n\nstd::cout << \"Number: \" << q.numerical_value_in(mph) << \"\\n\";\nstd::cout << \"Unit: \" << q.unit << \"\\n\";\nstd::cout << \"Dimension: \" << q.dimension << \"\\n\";\nstd::println(\"{::N[.2f]}\", q);\nstd::println(\"{:.4f} in {} of {}\", q.numerical_value_in(mph), q.unit, q.dimension);\nstd::println(\"{:%N in %U of %D:N[.4f]}\", q);\n
     
    Number: 55.9234\nUnit: mi/h\nDimension: LT\u207b\u00b9\n55.92 mi/h\n55.9234 in mi/h of LT\u207b\u00b9\n55.9234 in mi/h of LT\u207b\u00b9\n
     
    More on this subject can be found in the updated Text Output chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#improved-casts","title":"Improved casts","text":"
    We added a new conversion function. value_cast<Unit, Representation> forces the conversion of both a unit and representation type in one step and always ensures that the best precision is provided.
     
    Also, we have finally added proper implementations of value_cast and quantity_cast for quantity points.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#even-better-error-messages","title":"Even better error messages","text":"
    This release made a few small refactorings that, without changing the user-facing API, allowed us to improve the readability of the generated types that can be observed in the compilation errors.
     
    Example 1 (clang):
     NowBefore 
    error: no matching function for call to 'time_to_goal'\n   26 |   const quantity ttg = time_to_goal(half_marathon_distance, pace);\n      |                        ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre>{}, double>,\n                                                                  speed:auto = quantity<derived_unit<second, per<kilo_<metre>>>{}, double>]\n   13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n      |                            ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre> > >{{{}}}>, isq::speed>' evaluated to false\n   14 |                                         QuantityOf<isq::speed> auto speed)\n      |                                         ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n   61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n      |                                     ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> > >{}, struct speed{{{}}})' evaluated to false\n  147 |   QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n      |                                                                         ^\n1 error generated.\nCompiler returned: 1\n
     
    error: no matching function for call to 'time_to_goal'\n   26 |   const quantity ttg = time_to_goal(half_marathon_distance, pace);\n      |                        ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre{{}}>{}, double>,\n                                                                  speed:auto = quantity<derived_unit<second, per<kilo_<metre{{}}>>>{}, double>]\n   13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n      |                            ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre{{}}> > >{{{}}}>, isq::speed>' evaluated to false\n   14 |                                         QuantityOf<isq::speed> auto speed)\n      |                                         ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre{{}}> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n   61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n      |                                     ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> >{{}, {{}}}>{}, struct speed{{{}}})' evaluated to false\n  147 |   QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n      |                                                                         ^\n1 error generated.\nCompiler returned: 1\n
     
    Example 2 (gcc):
     NowBefore 
    error: no matching function for call to 'Box::Box(quantity<reference<isq::height, si::metre>(), int>, quantity<reference<horizontal_length, si::metre>(), int>,\n                                                  quantity<reference<isq::width, si::metre>(), int>)'\n   27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n      |                                                                           ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length, si::metre>()>, quantity<reference<isq::width, si::metre>()>,\n                                          quantity<reference<isq::height, si::metre>()>)'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |   ^~~\nnote:   no known conversion for argument 1 from 'quantity<reference<isq::height, si::metre>(),int>'\n        to 'quantity<reference<horizontal_length, si::metre>(),double>'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\n
     
    error: no matching function for call to 'Box::Box(quantity<reference<isq::height(), si::metre()>(), int>, quantity<reference<horizontal_length(), si::metre()>(), int>,\n                                                  quantity<reference<isq::width(), si::metre()>(), int>)'\n   27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n      |                                                                           ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length(), si::metre()>()>, quantity<reference<isq::width(), si::metre()>()>,\n                                          quantity<reference<isq::height(), si::metre()>()>)'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |   ^~~\nnote:   no known conversion for argument 1 from 'quantity<reference<isq::height(), si::metre()>(),int>'\n        to 'quantity<reference<horizontal_length(), si::metre()>(),double>'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/#mathh-header-changes","title":"math.h header changes","text":"
    This release provided lots of changes to the mp_units/math.h header file.
     
    First, we got several outstanding contributions:
     
       
    • fma, isfinite, isinf, and isnan math functions were added by @NAThompson,
      •  
    • ppm, atan2, fmod, and remainder were added by @nebkat.
      •  
     
    Thanks!
     
    Additionally, we changed the namespace for trigonometric functions using SI units. Now they are inside of the mp_units::si subnamespace and not in mp_units::isq like it was the case before ( breaking change ).
     
    Also, the header itself was split into smaller pieces that improve C++20 modules definitions.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#ratio-made-an-implementation-detail-of-the-library","title":"ratio made an implementation detail of the library","text":"
    We decided not to expose ratio and associated interfaces in the public part of the library ( breaking change ). Standardization of it could be problematic as we have std::ratio already.
     
    Alternatively, as in the public interface it was always only used with mag, we introduced a new helper called mag_ratio to provide the magnitude of the unit defined in terms of a rational conversion factor. Here is a comparison of the code with previous and current definitions:
     NowBefore 
    inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\ninline constexpr struct foot final : named_unit<\"ft\", mag_ratio<1, 3> * yard> {} foot;\n
     
    inline constexpr struct yard : named_unit<\"yd\", mag<ratio{9'144, 10'000}> * si::metre> {} yard;\ninline constexpr struct foot : named_unit<\"ft\", mag<ratio{1, 3}> * yard> {} foot;\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/","title":"mp-units 2.3.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    This release fine-tunes many key features of the library. This post describes the most interesting improvements, while a much longer list of the changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#cmake-and-conan-options-changed","title":"CMake and Conan options changed","text":"
    During the review on the ConanCenter, we got feedback that we should improve the handling of options for which value is automatically determined based on the current configuration. Instead of explicitly setting the auto value, we defer the choice between True/False until the configuration stage and set it there once all the settings are known. auto value for such option was removed ( breaking change ).
     
    If you didn't set any value at the command line for such options, everything stays the same for you. However, some changes are needed if you explicitly used auto like below:
     
    conan install . -o 'mp-units:std_format=auto' -s compiler.cppstd=23 -b missing\n
     
    Now you have to either skip such an option to keep automatic deduction:
     
    conan install . -s compiler.cppstd=23 -b missing\n
     
    or set it explicitly to True or False to force a specific configuration:
     
    conan install . -o 'mp-units:std_format=True' -s compiler.cppstd=23 -b missing\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/#msvc-compiler-support","title":"MSVC compiler support","text":"
    The MSVC compiler has the most bugs in the C++20 support from all our compilers. However, with this release, we could apply many workarounds to the library's code to make it work. \ud83c\udf89
     
    Please note those workarounds were only applied to the library's code and not to our unit tests and examples. Trying to build the entire project on MSVC will inevitably fail to compile unless the MSVC bugs are resolved. MSVC developers still have some work to do.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#representation-type-template-parameter-added-to-value-conversion-functions","title":"Representation type template parameter added to value conversion functions","text":"
    Previously, changing a representation type was only possible with a value_cast<NewRep>(q) non-member function while a change of unit was supported by all value_cast<NewU>(q), q.in(NewU), and q.force_in(NewU). The rationale for it was that passing an explicit type to a member function template requires a template disambiguator when we are dealing with a dependent name (e.g., quantity type is determined based on a template parameter).
     
    During a discussion in LEWGI at the St. Louis WG21 Meeting, we decided to provide such additional overloads despite possible issues when a dependent name is used. In such case, a user needs to provide a template disambiguator or switch back to using value_cast:
     
    // non-dependent name\nauto f(quantity<m, int> q)             { return q.in<double>(km); }\nauto g(quantity<m, int> q)             { return value_cast<double, km>(q); }\n\n// dependent name\nauto h(QuantityOf<isq::length> auto q) { return q.template in<double>(km); }\nauto i(QuantityOf<isq::length> auto q) { return value_cast<double, km>(q); }\n
     
    The table below provides all the value conversion functions in mp-units that may be run on x being the instance of either quantity or quantity_point:
     Forcing Representation Unit Member function Non-member function No Same u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x) or value_cast<T, u>(x)"},{"location":"blog/2024/09/27/mp-units-230-released/#quantity-reference-specifiers","title":"Quantity reference specifiers","text":"
    The features described in this chapter directly solve an issue raised on std-proposals reflector. As it was reported, the code below may look correct, but it provides an invalid result:
     
    quantity Volume = 1.0 * m3;\nquantity Temperature = 28.0 * deg_C;\nquantity n_ = 0.04401 * kg / mol;\nquantity R_boltzman = 8.314 * N * m / (K * mol);\nquantity mass = 40.0 * kg;\nquantity Pressure = R_boltzman * Temperature.in(K) * mass / n_ / Volume;\nstd::cout << Pressure << \"\\n\";\n
     
    The problem is related to the accidental usage of a quantity rather than quantity_point for Temperature. This means that after conversion to kelvins, we will get 28 K instead of the expected 301.15 K, corrupting all further calculations.
     
    A correct code should use a quantity_point:
     
    quantity_point Temperature(28.0 * deg_C);\n
     
    This might be an obvious thing for domain experts, but new users of the library may not be aware of the affine space abstractions and how they influence temperature handling.
     
    After a lengthy discussion on handling such scenarios, we decided to:
     
       
    • make the above code deprecated ( breaking change ),
      •  
    • provide an alternative way to create a quantity with the delta quantity construction helper.
      •  
     
    Here are the main points of this new design:
     
       
    1. All references/units that specify point origin in their definition (i.e., si::kelvin, \u00a0 \u00a0si::degree_Celsius, and usc::degree_Fahrenheit) are excluded from the multiply syntax  ( breaking change ).
      2.  
    2.  
      A new delta quantity construction helper is introduced:
       
         
      • delta<m>(42) results with a quantity<si::metre, int>,
        •  
      • delta<deg_C>(5) results with a quantity<si::deg_C, int>.
        •  
       
      3.  
    3.  
      A new absolute quantity point construction helper is introduced:
       
         
      • absolute<m>(42) results with a quantity_point<si::metre, zeroth_point_origin<kind_of<isq::length>>{}, int>,
        •  
      • absolute<deg_C>(5) results with a quantity<si::metre, si::ice_point, int>.
        •  
       
      4.  
     
    Info
     
    Please note that si::kelvin is also excluded from the multiply syntax to prevent the following surprising issues:
     NowBefore 
    quantity q = delta<K>(300);\nquantity_point qp = absolute<K>(300);\nstatic_assert(q.in(deg_C) != qp.in(deg_C).quantity_from_zero());\n
     
    quantity q(300 * K);\nquantity_point qp(300 * K);\nstatic_assert(q.in(deg_C) != qp.in(deg_C).quantity_from_zero());\n
     
    We believe that the code enforced with new utilities makes it much easier to understand what happens here.
     
    With such changes to the interface design, the offending code will not compile as initially written. Users will be forced to think more about what they write. To enable the compilation, the users have to create explicitly:
     
       
    •  
      a quantity_point (the intended abstraction in this example) with any of the below syntaxes:
       
      quantity_point Temperature = absolute<deg_C>(28.0);\nauto Temperature = absolute<deg_C>(28.0);\nquantity_point Temperature(delta<deg_C>(28.0));\n
       
      •  
    •  
      a quantity (an incorrect abstraction in this example) with:
       
      quantity Temperature = delta<deg_C>(28.0);\nauto Temperature = delta<deg_C>(28.0);\n
       
      •  
     
    Thanks to the new design, we can immediately see what happens here and why the result might be incorrect in the second case.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#quantity_point_like_traits-are-based-on-numerical-value-instead-of-a-quantity","title":"quantity_point_like_traits are based on numerical value instead of a quantity","text":"
    In this release, we decided to fine-tune the traits that customize the conversion between custom quantity point types and the ones provided with mp-units ( breaking change ).
     
    Previously, such type traits were based on the quantity type. This was inconsistent with quantity_like_traits, that is working on raw values. Also, there are cases where a custom quantity point abstraction is not modelled with a quantity type. In such cases, the previous approach required additional types to be introduced for no good reason.
     NowBefore 
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<quantity<reference, rep>> to_quantity(Timestamp ts)\n  {\n    return ts.seconds * si::second;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_quantity(quantity<reference, rep> q)\n  {\n    return Timestamp(q.numerical_value_ref_in(si::second));\n  }\n};\n
     
    Note
     
    The old behavior is deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#magpi","title":"mag<pi>","text":"
    With this release, we introduced a new strongly-typed constant to create a magnitude involving scaling by pi. The solution used before was not consistent with magnitudes of integral values and also was leaking a floating-point value of std::numbers::pi_v<long double> to the resulting magnitude type. With the new approach, this is no longer the case, and the user-facing interface is more consistent:
     NowBefore 
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag<pi> / mag<180> * si::radian> {} degree;\n
     
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag_pi / mag<180> * si::radian> {} degree;\n
     
    Note
     
    The old mag_pi helper is marked as deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#common-units","title":"Common units","text":"
    Adding or subtracting two quantities of different units will force the library to find a common unit for those. This is to prevent data truncation. For the cases when one of the units is an integral multiple of the another, the resulting quantity will use a \"smaller\" one in its result. For example:
     
    static_assert((1 * kg + 1 * g).unit == g);\nstatic_assert((1 * km + 1 * mm).unit == mm);\nstatic_assert((1 * yd + 1 * mi).unit == yd);\n
     
    However, in many cases an arithmetic on quantities of different units will result in a yet another unit. This happens when none of the source units is an integral multiple of another. In such cases, the library returns a special type that denotes that we are dealing with a common unit of such an equation.
     
    Previously we returned a scaled unit calculated against our arbitrarily appointed reference unit. This resulted often in a long and messy type exposing the prime-factorized magnitude of the unit (implementation detail). In this release, we introduced a new common_unit wrapper for such cases:
     NowBefore 
    quantity q = 1 * km + 1 * mi;  // quantity<common_unit<international::mile, si::kilo_<si::metre>>{}, int>\n
     
    quantity q = 1 * km + 1 * mi;  // quantity<scaled_unit<magnitude<power_v<2, 3>{}, power_v<5, -3>{}>{}, si::metre>{}, int>\n
     
    Note
     
    A user should never explicitly instantiate a common_unit class template. The library's framework will do it based on the provided quantity equation.
     
    Such units need special printing rules for their symbols. As they represent a minimum set of common units resulting from the addition or subtraction of multiple quantities, from this release, we print all of them as a scaled version of the source unit. Previously we were printing them relative to some arbitrary reference unit (implementation detail) that often was not spelled by the user at all in the source code. For example the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\n
     
    will print:
     NowBefore 
    40771 ([1/25146] mi = [1/15625] km)\n108167 ([1/50292] mi = [1/57875] nmi)\n23 ([1/5] km/h = [1/18] m/s)\n
     
    40771 [8/125] m\n108167 [4/125] m\n23 [1/18] m/s\n
     
    Thanks to the above, it might be easier for the user to reason about the magnitude of the resulting unit and its impact on the value stored in the quantity.
     
    Info
     
    In order to provide common_unit strong type unit wrapper we had to rename all the common_XXX() functions to get_common_XXX() ( breaking change ).
    "},{"location":"blog/2024/09/27/mp-units-230-released/#superpowers-of-the-unit-one","title":"Superpowers of the unit one","text":"
    In this release, we also added a long-awaited change. From now on a quantity of a unit one can be:
     
       
    • implicitly constructed from the raw value,
      •  
    • explicitly converted to a raw value,
      •  
    • compared to a raw value.
      •  
     NowBefore 
    quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n  legacy(static_cast<int>(q));\n
     
    quantity<one> inc(quantity<one> q) { return q + 1 * one; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42 * one); q != 0 * one)\n  legacy(q.numerical_value_in(one));\n
     
    This property also expands to usual arithmetic operators.
     
    With the above change, we can now achieve the same results in a terser way:
     NowBefore 
    static_assert(10 * km / (5 * km) == 2);\nconst quantity gain = 1. / index;\n
     
    static_assert(10 * km / (5 * km) == 2 * one);\nconst quantity gain = 1. / index * one;\n
     
    Note
     
    Those rules do not apply to all the dimensionless quantities. It would be unsafe and misleading to allow such operations on units with a magnitude different than 1 (e.g., percent or radian).
    "},{"location":"blog/2024/09/27/mp-units-230-released/#import-std-support","title":"import std; support","text":"
    This release brings experimental support for import std;. The only compiler that supports it for now is clang-18+. Until all the compilers start to support it and CMake removes the experimental tag from this feature, we will also keep it experimental.
     
    As all of the C++ compilers are buggy for now, it is not allowed to bring the same definitions through the import std; and regular header files. This applies not only to the current project but also to all its dependencies. This is why, in order to use it with mp-units, we need to disable all the dependencies as well (enforced with conanfile.py). It means that we have to use std::format (instead of fmtlib) and remove functions contract checking.
     
    With the above assumptions, we can refactor our smoot example to:
     
    import mp_units;\nimport std;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/#unit_can_be_prefixed-removed","title":"unit_can_be_prefixed removed","text":"
    Previously, the unit_can_be_prefixed type trait was used to limit the possibility to prefix some units that are officially known as non-prefixable (e.g., hour, minute).
     
    It turned out that it is not easy to determine whether some units can be prefixed. For example, for degree Celsius, the ISO 80000-5 standard explicitly states:
     
    Prefixes are not allowed in combination with the unit \u00b0C.
     
    On the other hand this NIST page says:
     
    Prefix symbols may be used with the unit symbol \u00baC and prefix names may be used with the unit name \u201cdegree Celsius.\u201d For example, 12 m\u00baC (12 millidegrees Celsius) is acceptable.
     
    It seems that it is also a common engineering practice.
     
    To prevent such issues, we decided to simplify the library's design and remove the unit_can_be_prefixed type trait ( breaking change ).
     
    From now on, every named unit in the library can be prefixed with the SI or IEC prefix.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#iec80000-system-renamed-to-iec","title":"iec80000 system renamed to iec","text":"
    As we mentioned IEC already, in this release, we decided to rename the name of the system and its corresponding namespace from iec80000 to iec ( breaking change ). This involves renaming of a defining header file and of the namespace it provides.
     
    With this change it should be easier to type the namespace name. This name is also more correct for some quantities and units that are introduced by IEC but not necessarily in the ISO/IEC 80000 series of documents (e.g., iec::var).
     
    Note
     
    The old iec80000 namespace in iec8000.h is marked as deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#error-messages-related-improvements","title":"Error messages-related improvements","text":"
    The readability of compile-time error messages is always a challenge for generic C++ libraries. However, for quantities and units library, generating readable errors is the most important requirement. If you do not make errors, you do not need such a library in your project .
     
    This is why we put lots of effort into improving here. Besides submitting compiler bugs to improve on their part, we also try to do our best here.
     
    Some compilers do not present the type resulting from calling a function within a template argument. This ends up with statements like get_quantity_spec(si::second{}) in the error message. Some less experienced users of the library may not know what this mean, and then why the conversion error happens.
     
    To improve this, we injected additional helper concepts into the definitions. It results with a bit longer but a more readable error in the end.
     
    For example:
     NowBefore 
    error: no matching member function for call to 'in'\n   15 | const quantity time_to_goal = (distance * speed).in(s);\n      |                               ~~~~~~~~~~~~~~~~~~~^~\nnote: candidate template ignored: constraints not satisfied [with ToU = struct second]\n  221 |   [[nodiscard]] constexpr QuantityOf<quantity_spec> auto in(ToU) const\n      |                                                          ^\nnote: because 'detail::UnitCompatibleWith<si::second, unit, quantity_spec>' evaluated to false\n  219 |   template<detail::UnitCompatibleWith<unit, quantity_spec> ToU>\n      |            ^\nnote: because '!AssociatedUnit<si::second>' evaluated to false\n  164 |   (!AssociatedUnit<U> || UnitOf<U, QS>) && detail::UnitConvertibleTo<FromU, U{}>;\n      |    ^\nnote: and 'UnitOf<si::second, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  164 |   (!AssociatedUnit<U> || UnitOf<U, QS>) && detail::UnitConvertibleTo<FromU, U{}>;\n      |                          ^\nnote: because 'detail::QuantitySpecConvertibleTo<get_quantity_spec(si::second{}), kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  141 |                  detail::QuantitySpecConvertibleTo<get_quantity_spec(U{}), QS> &&\n      |                  ^\nnote: because 'implicitly_convertible(kind_of_<struct time>{}, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{})' evaluated to false\n  151 |   implicitly_convertible(From, To);\n      |   ^\n1 error generated.\nCompiler returned: 1\n
     
    error: no matching member function for call to 'in'\n   15 | const quantity time_to_goal = (distance * speed).in(s);\n      |                               ~~~~~~~~~~~~~~~~~~~^~\nnote: candidate template ignored: constraints not satisfied [with U = struct second]\n  185 |   [[nodiscard]] constexpr QuantityOf<quantity_spec> auto in(U) const\n      |                                                          ^\nnote: because 'detail::UnitCompatibleWith<si::second, unit, quantity_spec>' evaluated to false\n  183 |   template<detail::UnitCompatibleWith<unit, quantity_spec> U>\n      |            ^\nnote: because '!AssociatedUnit<si::second>' evaluated to false\n  207 |   (!AssociatedUnit<U> || UnitOf<U, QS>)&&(detail::have_same_canonical_reference_unit(U{}, U2));\n      |    ^\nnote: and 'UnitOf<si::second, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  207 |   (!AssociatedUnit<U> || UnitOf<U, QS>)&&(detail::have_same_canonical_reference_unit(U{}, U2));\n      |                          ^\nnote: because 'implicitly_convertible(get_quantity_spec(si::second{}), kind_of_<derived_quantity_spec<power<length, 2>, per<time> > >{})' evaluated to false\n  187 |   implicitly_convertible(get_quantity_spec(U{}), QS) &&\n      |   ^\n1 error generated.\nCompiler returned: 1\n
     
    Note
     
    The above error messages were stripped a bit of the additional information (file name, namespace name, nested curlies) to provide better readability.
    "},{"location":"blog/2024/11/05/mp-units-240-released/","title":"mp-units 2.4.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    This release was unexpected. We planned a significant new feature to happen next, but while preparing for it, and also while writing API Reference documentation, we made so many vital fixes and improvements that we decided that they deserve a dedicated release first.
     
    This post describes the most significant improvements while a much longer list of the changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#isq-quantities-cleanup","title":"ISQ quantities cleanup","text":"
    Initially, we kept quantities defined in \"IEC 80000-13: Information science and technology\" in a standalone iec80000 namespace, which was renamed to iec in the previous release. It turned out that this was incorrect. Those quantities are also a part of the ISQ. This is why, in this release, we moved all of them to the isq namespace ( breaking change ).
     
    From now on, iec namespace does not provide any quantities and serves purely as a system of units definition. It contains binary prefixes (based on the powers of two) and some units introduced by IEC (e.g., var, erlang, bit, or `baud).
     
    Note
     
    The quantities in iec namespace are now deprecated and will be removed in future releases.
     
    Also, it turns out that the latest ISO 80000-3 revision makes a small cleanup to the phase_speed and group_speed quantities. Those were always defined as scalar quantities but also had alternative names phase_velocity and group_velocity. This is misleading as velocity is typically considered a vector quantity. It is why those XXX_velocity aliases were removed from the ISO standard and from mp-units library ( breaking change ).
    "},{"location":"blog/2024/11/05/mp-units-240-released/#units-equality","title":"Units equality","text":"
    Previously we assumed that units like J, N m, and kg m\u00b2/s\u00b2 are equal. In some cases, this might not be entirely correct. Some quantities require a specific derived unit instead of a unit with a special name. For example:
     
       
    • N m should be used for moment of force (instead of J),
      •  
    • V A should be used for apparent power (instead of W).
      •  
     
    This is why, starting from this release units like J, N m, and kg m\u00b2/s\u00b2 will not compare equal ( breaking change ). However, they are deemed equivalent:
     
    static_assert(equivalent(J, N * m));\nstatic_assert(equivalent(W, V * A));\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#portable-text-output","title":"Portable text output","text":"
    From the very beginning, the text output of symbols could be formatted in two different ways:
     
       
    • Unicode,
      •  
    • portable using so-called ASCII alternatives.
      •  
     
    mp-units used the terms \"Unicode\" or \"ASCII\" and 'U' or 'A' formatting options for them. Even though those terms are widely understood in the C++ community, they are technically incorrect.
     
    During the recent SG16 meeting, we looked for proper alternatives and ended up with the \"portable\" and \"UTF-8\" terms ( breaking change ).
     
    From now on, we will provide the following:
     
       
    • text_encoding::utf8, symbol_text<N, M>::utf8(), and U formatting option,
      •  
    • text_encoding::portable, symbol_text<N, M>::portable(), and P formatting option.
      •  
     
    Note
     
    The old identifiers and formatting options are now deprecated and will be removed in future releases.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#char_traits-removed-from-fixed_string","title":"char_traits removed from fixed_string","text":"
    During the same SG16 meeting, the room was strongly against providing char_traits for fixed_string. This is why char_traits support was removed in this release ( breaking change ).
    "},{"location":"blog/2024/11/05/mp-units-240-released/#improved-units-text-output","title":"Improved units' text output","text":"
    In the previous release, we introduced common unit abstraction. Initially, all its components were printed in parenthesis which contained a list of all the scaled units separated with =. After some feedback, we decided to change it to a new syntax.
     
    For example, the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\n
     
    will print:
     NowBefore 
    40771 EQUIV{[1/25146 mi], [1/15625 km]}\n108167 EQUIV{[1/50292 mi], [1/57875 nmi]}\n23 EQUIV{[1/5 km/h], [1/18 m/s]}\n
     
    40771 ([1/25146] mi = [1/15625] km)\n108167 ([1/50292] mi = [1/57875] nmi)\n23 ([1/5] km/h = [1/18] m/s)\n
     
    As we can see above, the scaled units output changed as well. Now, the entire scaled unit is encapsulated within [...] brackets to better denote its scope.
     
    Additionally, small magnitudes of scaled units do not use the power of 10, and also scaled units do not have a composition priority over the derived units anymore.
     
    As a result of those changes, the following:
     
    constexpr Unit auto L_per_100km = L / (mag<100> * km);\nstd::cout << 6.7 * L_per_100km << \"\\n\";\n
     
    prints:
     NowBefore 
    6.7 L/[100 km]\n
     
    6.7 \u00d7 10\u207b\u00b2 l/km\n
     
    One more change that we can see above is that litre now use 'L' instead of 'l' for its symbol. The latter one too often is confused with the number 1.
     
    The next improvement adds proper formatting support for magnitudes. All of the formatting options that were working before for the unit symbols now also work for magnitudes.
     
    For example:
     
    using enum text_encoding;\nusing enum unit_symbol_solidus;\nusing usf = unit_symbol_formatting;\n\nstatic_assert(unit_symbol(mag<1> / (mag<2> * mag<pi>)*metre) == \"[2\u207b\u00b9 \ud835\udf0b\u207b\u00b9 m]\");\nstatic_assert(unit_symbol<usf{.solidus = always}>(mag<1> / (mag<2> * mag<pi>)*metre) == \"[1/(2 \ud835\udf0b) m]\");\nstatic_assert(unit_symbol<usf{.encoding = portable, .solidus = always}>(mag<1> / (mag<2> * mag<pi>)*metre) ==\n              \"[1/(2 pi) m]\");\n
     
    As we can see above, the library also learned how to print magnitude symbols. This required a change in the mag_constant definition. Now, it takes a magnitude symbol and has to be final like for other similar types in the library ( breaking change ):
     
    inline constexpr struct pi final : mag_constant<symbol_text{u8\"\u03c0\", \"pi\"}, std::numbers::pi_v<long double>> {} pi;\ninline constexpr auto \u03c0 = pi;\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#unicode-identifiers","title":"Unicode identifiers","text":"
    The example above introduced something interesting: a \u03c0 identifier for a variable. With the latest changes to the C++ language, we can officially use Unicode symbols as identifiers in the C++ code.
     
    In this release, we've added Unicode identifiers support not only for \u03c0 magnitude constant but also for unit symbols.
     
    Now we can type the following:
     With UTF-8 glyphsPortable 
    quantity resistance = 60 * k\u03a9;\nquantity capacitance = 100 * \u00b5F;\n
     
    quantity resistance = 60 * kohm;\nquantity capacitance = 100 * uF;\n
     
    This might make the source code easier to understand, but typing those identifiers can be tricky. Sometimes, the best solution to type it might be a copy-paste approach. If we do not like this idea, we can still use old portable identifiers for those as well.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#convertibility-with-quantitylike-and-quantitypointlike-entities","title":"Convertibility with QuantityLike and QuantityPointLike entities","text":"
    In this release, we decided to fine-tune further the traits that customize the conversion between custom quantity and quantity point types and the ones provided with mp-units ( breaking change ).
     
    Previously, to_numerical_value and from_numerical_value returned a type wrapped in a special tag type describing the conversion type (explicit or implicit).
     
    This was a novel and experimental approach. Finally, we decided not to do it and used a bit more verbose but a more standard solution. From now on, we need to provide two additional static data members of type bool:
     
       
    • explicit_import - true means that the conversion to the mp-units abstraction is explicit,
      •  
    • explicit_export - true means that the conversion from the mp-units abstraction is   explicit.
      •  
     NowBefore 
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr rep to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr Timestamp from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#symbolic-constants-implementation-should-be-implementation-defined","title":"Symbolic constants implementation should be implementation-defined","text":"
    In the process of writing API Reference, we decided to hide all the metadata associated with symbolic constants - tag types used to define units, dimensions, quantity specification, etc. ( breaking change ).
     
    All the types and values exposed by such types are needed only in the implementation details of the library. Users should not need them. Hiding those and making them implementation-defined gives other vendors the freedom to choose different ways to implement features of this library in their codebases.
     
    Important
     
    Based on Hyrum's Law some users may depend on this information already, and this release will break their code.
     
    If that is the case for you, we would love to hear about your use case and its rationale. It may mean that we should either:
     
       
    • extend the library's functionality to support your use case out of the box and keep those   members hidden,
      •  
    • restore public visibility of such members and enforce this in the API Reference so that all   the users of various library implementations may use them in the same way as you.
      •  
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/","title":"Bringing Quantity-Safety To The Next Level","text":"
    All quantities and units libraries need to be unit-safe. Most of the libraries on the market do this correctly. Some of them are also dimension-safe, which adds another level of protection for their users.
     
    mp-units is probably the only library on the market that additionally is quantity-safe. This gives a new quality and possibilities. I've described the major idea behind it, implementation details, and benefits to the users in the series of posts about the International System of Quantities.
     
    However, this is only the beginning. We've always planned more and worked on the extensions in our free time. In this post, I will describe:
     
       
    • What a quantity character is?
      •  
    • The importance of using proper representation types for the quantities.
      •  
    • The power of providing character-specific operations for the quantities.
      •  
    • Discuss implementation challenges and possible solutions.
      •  
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#quantity-characters","title":"Quantity characters","text":"
    A quantity character determines the properties and operations that can be performed on the numerical value of a quantity.
     
    Quantities defined by the ISQ may be of the following characters:
     
       
    • real scalar (e.g., time, width, speed, apparent power),
      •  
    • complex scalar (e.g., voltage phasor, complex power, impedance),
      •  
    • vector (e.g., displacement, velocity, force),
      •  
    • tensor (e.g., moment of inertia, stress, strain).
      •  
     
    From the beginning, mp-units V2 was meant to properly support quantities of various characters. By default, all quantity types are scalars, but we can set any other quantity character in a quantity_spec definition. For example:
     
    inline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\n
     
    Character of derived quantities is inherited from the quantity equation taking into account the operations and their ingredients. For example the below velocity quantity will automatically get a vector character without the need to explicitly state it in the definition:
     
    inline constexpr struct velocity final : quantity_spec<displacement / duration> {} velocity;\n
     
    Similarly, the below will yield a speed quantity of a scalar character:
     
    inline constexpr struct speed final : quantity_spec<magnitude(velocity)> {} speed;\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#representation-types","title":"Representation types","text":"
    mp-units V2 requires providing representation types compatible with a specific character set in its quantity_spec definition:
     
    template<Reference auto R, RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    For example, this allows us to check that vector representation type is used to construct a velocity quantity and to ensure that speed gets a scalar:
     
    quantity q = vector{1, 2, 3} * m / s;\nquantity velocity = isq::velocity(q);\n// quantity speed = isq::speed(q);     // Compile-time error\n
     
    Another example here may be a complex power quantity that should use a representation type modeling a complex number, but apparent power, active power, and reactive power should get scalars.
     
    As we can see above, in the case of q, we can use any representation type with a quantity kind that just specify a unit (simple quantities). However, we need to provide a compatible representation type when we want to use strongly-typed quantities and be quantity-safe.
     
    Such checks already prevent many simple but common errors of mixing similar quantities in a specific domain.
     
    Info
     
    It is a common engineering practice to use fundamental types for vector quantities when we know the direction of the vector. For example, in many cases, we use double to express velocity or acceleration. In such cases, negative values mean moving backward or decelerating. This is why we also decided to allow such use cases in the library. A scalar representation type that provides abs() member or non-member function or works with std::abs() is considered a one-dimensional vector type:
     
    quantity speed = isq::speed(60 * km / h);\nquantity velocity = isq::velocity(60 * km / h);\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#character-specific-operations","title":"Character-specific operations","text":"
    Checking the representation type is only the first step in bringing additional safety. The real power comes with implementing character-specific operations.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#current-state-of-the-art","title":"Current state of the art","text":"
    Most units libraries on the market (not only for C++) provide only regular arithmetic operations for scalars and don't constrain them for quantities of other characters. They also do not offer any character-specific operations.
     
    For example, let's look closer into vector quantities. Most of the libraries on the market will happily accept the following or similar code:
     
    auto force = get_force();\nauto length = get_length();\nauto work = force * length;\n
     
    They will also accept the following line:
     
    auto moment_of_force = force * length;\n
     
    Does it mean that moment of force and work are the same quantities? Of course not! It is just how naive most libraries are today.
     
    But first, to defend them, I must admit that the behavior above is partially OK. force * length could yield some specific quantity, but it is definitely not work or moment of force.
     
    There are two problems here:
     
       
    1. Libraries on the market are not aware of the characters of the quantities being used in the equation.    This means they can't prevent scalar arithmetic operations from being performed on vector quantities.    This typically leads to compile-time errors when a proper linear algebra representation type is    used in a quantity, as most linear algebra libraries will not overload operator* for vectors,    and those that do, treat it as a dot product, which returns a scalar.
      2.  
    2. None of the libraries allows us to constrain the return type of such multiplication with    a specific quantity type to specify exactly what we want to achieve. Most of them allow for replacing    auto with a type that describes just a unit, or, at best, the dimension. This means that all of    them are unit-safe, and some are also dimension-safe. However, this is not helpful here and does    not allow the library to do any additional compile-time checks on the resulting quantities.    The fact that we named the results as work or moment_of_force does not mean anything to    the compiler or the library being used.
      3.  
     
    This isn't good.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#benefits-of-quantity-safe-library","title":"Benefits of quantity-safe library","text":"
    As we've stated in the beginning, mp-units, besides being unit-safe and dimension-safe, is also quantity-safe. Let's see what it means.
     
    Note
     
    The features described below are planned for the next major release of the library and are not available on the master branch as of today.
     
    First, we repeat what other libraries did:
     
    quantity force = get_force();\nquantity length = get_length();\nquantity q1 = force * length;\n
     
    The code compiles as long as length is a scalar quantity with a scalar representation type. We can always multiply or divide a vector quantity (e.g., force) by a scalar one.
     
    However, things stop compiling when we want to convert the obtained result to a specific quantity type:
     
    // quantity moment_of_force = isq::moment_of_force(q1);  // Compile-time error\n// quantity work = isq::work(q1);                        // Compile-time error\n
     
    Neither moment of force nor work quantity can be created from a scalar length. We need very specific vector quantities of kind length to do that:
     
    quantity displacement = get_displacement();\nquantity position_vector = get_position_vector();\n
     
    Now, if we try to multiply the variables as before, we will end up with a compilation error:
     
    // quantity q2 = force * displacement;                   // Compile-time error\n// quantity q3 = force * position_vector;                // Compile-time error\n
     
    Multiplication on vectors is mathematically not defined. We have to use proper operations:
     
    quantity q2 = scalar_product(force, displacement);\nquantity q3 = scalar_product(force, position_vector);\nquantity q4 = vector_product(force, displacement);\nquantity q5 = vector_product(force, position_vector);\n
     
    All of the above compile and result in some quantities. After that, we can try to convert those results to our required quantities:
     
    quantity work = isq::work(q2).in[J];\n// quantity work = isq::work(q3);                        // Compile-time error\n// quantity work = isq::work(q4);                        // Compile-time error\n// quantity work = isq::work(q5);                        // Compile-time error\n
     
    Important
     
    It is essential to realize that just like multiplication and division are for scalars, vector and scalar products are for vectors. We never want to accept a quantity that accidentally was created with multiplication instead of division of its arguments or with the scalar product instead of a vector product, right?
     
    So we are done with work. Let's create a moment of force quantity as well. It might be surprising to many that none of the following code compiles:
     
    // quantity moment_of_force = isq::moment_of_force(q2);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q3);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q4);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q5);  // Compile-time error\n
     
    Do you know why it does not compile? Please try to think about it for a minute and figure out what is the problem before checking the answer below.
     !!! Spoiler alert !!! 
    Vector product is anti-commutative. Similarly to the division for scalars, for a vector product it is important to decide which quantity we put on the left and right-hand side of the operation.
     
    To make it compile, we need to reverse the arguments of a vector_product() operation:
     
    quantity q6 = vector_product(position_vector, force);\nquantity moment_of_force = isq::moment_of_force(q6);\n
     
    Do you start to see the need for such checks at compile-time already? 
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#explicit-conversions-are-not-really-needed","title":"Explicit conversions are not really needed","text":"
    You may be worried by the fact that we needed explicit quantity conversions above and that the code without them compiled fine. It might look like a safety pitfall, but it is really not an issue.
     
    The code above used a quantity CTAD placeholder which works a bit like auto. It accepts any quantity and deduced proper type for it. And all of the above operations resulted in some quantities, but often not the ones we were interested in.
     
    In the production code, we deal with strong types in many places (members in classes, function arguments and return types, etc.). In generic code, we should use concepts to constrain template parameters. This will be enough to guarantee quantity-safety.
     
    For example:
     
    void func1(quantity<isq::work[J]> w);\nvoid func2(QuantityOf<isq::moment_of_force> auto mof);\n\nfunc1(q2);\nfunc2(q6);\n// func1(q6);  // Compile-time error\n// func2(q2);  // Compile-time error\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#peeking-under-the-hood","title":"Peeking under the hood","text":"
    Let's look at the definitions of work and moment of force quantities to understand how and why the above works:
     
    inline constexpr struct work final : quantity_spec<scalar_product(force, displacement)> {} work;\ninline constexpr struct moment_of_force final : quantity_spec<vector_product(position_vector, force)> {} moment_of_force;\n
     
    scalar_product() and vector_product() functions are overloaded not only for quantity but also for quantity_spec types. The results of such operations are symbolic expressions that identify those operations. When used as a quantity recipe in a quantity_spec definition, they tell the library which derived quantities may be implicitly converted to our quantity.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#what-do-other-libraries-do","title":"What do other libraries do?","text":"
    I am probably not wrong in stating that none of the major C++ units libraries on the market provides vector or complex operations on quantities. This is why none of them will work when a proper representation type will be provided to a quantity. Trying to do any operations on a quantity with a linear algebra vector as its representation type will fail to compile.
     
    This is also mostly true for other programming languages. A great exception, and in fact the only library that I know which provides such operations, is Python's Pint (thanks to NumPy support).
     
    As other libraries do not support quantities of a vector type, they require users to create homogenous vectors of quantities and do all of the linear algebra operations with a 3rd party library. This approach can't be quantity-safe!
     
    In such scenarios, the units library can't detect if an external linear algebra library performs a scalar or vector product operation. It only observes the individual multiplications on scalar ingredients of an external vector type. This is actually why such multiplication operations are provided in other units libraries in the first place.
     
    Let's compare those approaches:
     Quantity-SafeAlso Quantity-SafeOther units libraries 
    quantity displacement_1 = isq::displacement(la::vector{1, 2, 3} * m);\nquantity displacement_2 = isq::displacement(la::vector{2, 1, 0} * m);\nquantity displacement = displacement_1 + displacement_2;\nquantity force = isq::force(la::vector{42, 42, 42} * N);\nquantity work = isq::work(scalar_product(force, displacement));\n
     
    quantity displacement_1 = la::vector{1, 2, 3} * m;\nquantity displacement_2 = la::vector{2, 1, 0} * m;\nquantity displacement = displacement_1 + displacement_2;\nquantity force = la::vector{42, 42, 42} * N;\nquantity<isq::work[J]> work = scalar_product(force, displacement);\n
     
    la::vector<quantity<si::metre>> displacement_1 = la::vector{1 * m, 2 * m, 3 * m};\nla::vector<quantity<si::metre>> displacement_2 = la::vector{2 * m, 1 * m, 0 * m};\nla::vector<quantity<si::metre>> displacement = displacement_1 + displacement_2;\nla::vector<quantity<si::newton>> force = la::vector{42 * N, 42 * N, 42 * N};\nquantity<si::joule> work = la::scalar_product(force, displacement);\n
     
    Of course, someone could argue that incorrect use of a vector product operation above would also be safe as it will not compile as the return type differs. Yes, it is true. However, please remember that there are more cases where errors may happen.
     
    For example, an external linear algebra library will not protect us from providing arguments to a vector product in an invalid order.
     
    Also, our work quantity will never be able to detect if what we are trying to assign to it is a result of a scalar product of two vector quantities of displacement and force, or maybe just some naive multiplication of scalar quantities that accidentally matched the dimensionality of the expected result.
     
    Please also remember that the quantity characters are not only about linear algebra. For example, in the case of complex quantities, we want to ensure that only:
     
       
    • the real part of a complex power is assigned to an active power,
      •  
    • the imaginary part of a complex power is assigned to an reactive power,
      •  
    • the modulus of a complex power is assigned to an apparent power.
      •  
     
    Mixing the above is a fatal error in power systems engineering.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#implementation-challenges","title":"Implementation challenges","text":"
    I had planned to implement the above features for a few years now but never had enough time to do it. Now, I am close to finishing the work. However, I've discovered a few interesting issues on the way, and I have to solve them before putting my code on the mainline and releasing the next mp-units version.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#modeling-magnitudes","title":"Modeling magnitudes","text":"
    Let's dig in a bit more into proper modelling of position vector and displacement quantities. First, we have to think to which scalar quantities their magnitude should convert to:
     
       
    • a magnitude of a position vector is equivalent to a radial distance quantity,
      •  
    • a magnitude of a displacement is a special case of a distance quantity.
      •  
     
    Taking the above into account, we should refactor our tree of quantities of kind length into the following:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- displacement[\"<b>displacement</b><br>{vector}\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    radial_distance --- position_vector[\"<b>position_vector</b><br>{vector}\"]\n    length --- wavelength[\"<b>wavelength</b>\"]
     
    Having the above, we can look a bit closer into how velocity and speed are defined in the ISQ:
     
    ISO 80000-3: Space and time
     
    velocity - vector quantity giving the rate of change of a position vector.
     
    speed - magnitude of the velocity.
     
    Change of a position vector is nothing else than a displacement. This means that velocity and speed can be defined as follows:
     
    inline constexpr struct velocity final : quantity_spec<displacement / duration> {} velocity;\ninline constexpr struct speed final : quantity_spec<magnitude(velocity)> {} speed;\n
     
    This is compatible with the ISQ definitions. However, we should check what it means from the engineering point of view. Let's assume that we want to calculate speed directly from a distance traveled and duration, without using any vector quantities like displacement or velocity:
     
    quantity<isq::distance[m]> distance = 42 * m;\nquantity<isq::duration[s]> duration = 2 * s;\n// quantity<isq::speed[m / s]> speed = distance / duration;  // Compile-time error\n
     
    The above does not compile because distance quantity is not implicitly convertible to magnitude(displacement). This is the same case as stating that not every length is a distance. We need to cast here explicitly. To fix it, we can do any of the below:
     
    quantity<isq::speed[m / s]> speed1 = isq::speed(distance / duration);\nquantity<isq::speed[m / s]> speed2 = magnitude(isq::displacement)(distance) / duration;\n
     
    Also, the following will work:
     
    quantity length_kind = 42 * m;\nquantity<isq::speed[m / s]> speed3 = length_kind / duration;\n
     
    If we do not specify a specific quantity type and just use an SI unit, then we deal with the kind of quantity. Such quantity can behave like any quantity from the hierarchy tree with the same character, so it is also the same as magnitude(isq::displacement).
     
    Question
     
    Is it good enough from the engineering and usability point of views? If you would like to share your thoughts, please provide your comments below the article.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#more-about-displacement-and-position-vector","title":"More about displacement and position vector","text":"
    As we've stated above, a change of position vector is a displacement. Let's try to calculate it here:
     
    quantity pos1 = isq::position_vector(vector{1, 2} * m);\nquantity pos2 = isq::position_vector(vector{2, 3} * m);\nquantity q7 = pos2 - pos1;\n// quantity<isq::displacement[m], vector> displacement = q7;  // Compile-time error\n// quantity displacement = isq::displacement(q7);             // Compile-time error\nquantity displacement = quantity_cast<isq::displacement>(q7);\n
     
    Again, the above might be surprising and considered a usability issue. Let me describe why the code behaves like that.
     
    As of today, the result of an addition or subtraction of two quantities is their common quantity type. When subtracting two position vectors we end up with a position vector. Looking at the above hierarchy tree, we can easily see that position vector and displacement are on different branches. This prevents implicit and explicit conversions between those. The only one allowed to force such a conversion is an explicit cast.
     
    If we think more about it, this makes a lot of sense. Position vector is not a special case of displacement or vice versa. Those should not be convertible. We do not want the code to compile when we accidentally pass a position vector to the numerator of the equation for velocity, right? What does calculating the velocity for a position vector mean?
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#affine-spaces-within-quantity-trees","title":"Affine spaces within quantity trees","text":"
    Also, let's look at the type of variable q7. We know that subtracting two quantities of the same type results in a quantity of the same type. This is also the case when we do it for position vectors. We will see the same resulting type when we add two position vectors as well. But wait... What does it actually mean to add two position vectors?
     
    Looks familiar? Yes, we can clearly see that we are dealing with yet another case of the affine space. This time, it is hidden within the quantities hierarchy tree. This also means that adding a position vector and a displacement should result in a position vector. Let's try to do it:
     
    quantity q8 = pos1 + displacement;                       // Often a compile-time error\n
     
    Unfortunately, this often fails on the very first step, even before assigning the result to the position vector quantity. The reason for this is that in the hierarchy tree, the first common node for position vector and displacement is distance, which is a scalar quantity. Trying to use a vector representation type for a scalar quantity yields an error as a result of already existing checks described in the Representation types chapter.
     
    However, the code will compile if we use the same representation type for scalar and vector quantity (e.g., int or double may be used as a vector representation type for a well-known axis). In this case, we will end up with:
     
    // quantity<isq::position_vector[m], vector> pos3 = q8;       // Compile-time error\nquantity<isq::position_vector[m], vector> pos3 = isq::position_vector(q8);\n
     
    We need to convert a distance explicitly to a position vector quantity to move \"down\" over a branch in a hierarchy tree.
     
    It is important to note that there are more quantities that may behave the same. For example, altitude/height and time/duration may also form similar affine spaces. More similar examples can be found in other hierarchy trees.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#extending-arithmetic-on-quantity-specifications","title":"Extending arithmetic on quantity specifications","text":"
    mp-units provided support for multiplication and division of quantity_spec from the beginning. It was needed to obtain derived quantities. Adding support for quantity characters also added special operations (e.g., magnitude(), scalar_product(), etc.) on quantity_spec arguments. If we want to support such affine space abstractions, we must also add support for addition and subtraction, which may yield different results.
     
    For example:
     
    static_assert(isq::length + isq::length == isq::length);\nstatic_assert(isq::height + isq::width == isq::length);\nstatic_assert(isq::altitude + isq::height == isq::altitude);\nstatic_assert(isq::height + isq::altitude == isq::altitude);\n\nstatic_assert(isq::length - isq::length == isq::length);\nstatic_assert(isq::height - isq::width == isq::length);\nstatic_assert(isq::altitude - isq::height == isq::altitude);\nstatic_assert(isq::altitude - isq::altitude == isq::height);\n
     
    Also, some operations should not compile. For example:
     
    // auto qs1 = isq::altitude + isq::altitude;  // Compile-time error\n// auto qs2 = isq::height - isq::altitude;    // Compile-time error\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#defining-affine-space-abstractions-in-a-quantity_spec","title":"Defining affine space abstractions in a quantity_spec","text":"
    We can add support for the above by adding point_for<QuantitySpec> attribute to the quantity_spec definition:
     
    inline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct altitude final : quantity_spec<length, point_for<height>> {} altitude;\ninline constexpr struct displacement final : quantity_spec<distance, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<radial_distance, point_for<displacement>, quantity_character::vector> {} position_vector;\n
     
    Thanks to the above, the library always knows a \"delta\" quantity for a \"point\" type. I've implemented this logic, got great results, and thought I was done. But next, I realized that I need to update a few more things.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#adding-support-to-quantity_point","title":"Adding support to quantity_point","text":"
    quantity_point is intended to model \"point\" quantities and return \"delta\" quantities on subtraction or by calling .quantity_from...() family of member functions. This is possible and can be done. I've finished most of the implementation already. However, two interesting questions arise:
     
       
    1. Should isq::altitude be reserved only for quantity_point and not available for    \"regular\"\u00a0quantity types?
      2.  
    2. Should isq::height apply only to quantity?
      3.  
     
    I think that question #1 makes a lot of sense. If we realize that quantity always represents \"delta\" quantities, what would a quantity of isq::altitude mean? However, forcing the usage of quantity_point might be too strict here. Some users are not familiar or comfortable with this abstraction. Also, we can't multiply or divide quantity points.
     
    Question
     
    Does anyone know a derived quantity built with altitude or time instant? If so, please let me know in the comments, as limiting \"point\" quantity_spec to quantity_point would prevent forming such derived quantities.
     
    Question #2 is also interesting. However, in this case, I think that the answer should be \"NO\". I can imagine a series of height measurements. Every physical measurement can be modeled as a quantity_point, so a quantity_point of height might make sense.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#opening-can-of-worms","title":"Opening can of worms","text":"
    So far, so good. I thought I was done here and could continue my work on symbolic expressions for vector and complex quantities. However, I've realized that I've opened a can of worms. What about the convertibility of quantity_spec? How should common_quantity_spec() behave?
     
    Let's start with conversions. It might seem easy. isq::altitude and isq::height should not be convertible to each other. But more questions arise:
     
       
    1. Should it be possible to quantity_cast from isq::altitude to isq::height or vice versa?
      2.  
    2. Should isq::height be convertible to isq::length?
      3.  
    3. Should isq::length be explicitly convertible to isq::height?
      4.  
    4. Should isq::altitude be convertible to isq::length?
      5.  
    5. Should isq::length be explicitly convertible to isq::altitude?
      6.  
     
    The need for #1 will always probably mean an error in program logic, so quantity_cast could not work for such entities. This would be an exception to our conversion rules that always allow casting between branches of one tree.
     
    The answer to questions #2 and #3 is \"YES\".
     
    We might be tempted to say \"NO\" to questions #4 and #5 as isq::altitude is defined as \"point\" while isq::length is not specified as such. However, I've just realized that it is not the case.
     
    The proper answer to questions #4 and #5 is \"It depends\". If we are dealing with a quantity_point then converting from isq::altitude to isq::length or the other way around should work. However, it would probably be a bad idea for a quantity type.
     
    It turns out that common_quantity_spec() is similar. It is probably safe to state that it should not compile for isq::altitude and isq::height arguments. This means that we will not be able to compare such quantities as well. As those are different abstractions, preventing that might be an excellent idea.
     
    Again, it gets tricky if we consider passing isq::length and isq::altitude to it. For quantity_point it probably should work fine and fail to compile for quantity.
     
    The above means that to determine the conversion rules and common quantity specifications, we need to know the context in which the quantity_spec is being used. This sucks!
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#should-we-get-rid-of-a-quantity_point","title":"Should we get rid of a quantity_point?","text":"
    There are at least two ways of solving the above issue. In any case, we need to introduce a wrapper over the quantity_spec to denote it is being used in a \"point\" abstraction.
     
    A simpler solution could be implicitly amending the Reference provided to the quantity_point class template with point<...>. So, for example, we would have the following members in quantity_point<isq::altitude[m]>:
     
       
    • qp::quantity_spec == point<isq::altitude>,
      •  
    • qp::reference of a type reference<point<isq::altitude>, si::metre>.
      •  
     
    This should work but might be a bit confusing as members of the class template would not exactly contain the types of template parameters.
     
    A better solution might be removing a dedicated quantity_point abstraction and providing both functionalities through the quantity class template. I still haven't figured out the best syntax. Please let me know if you have good ideas in the comments below. Here are some rough ideas:
     Before After quantity_spec quantity<si::metre> quantity<si::metre> kind_of<isq::length> quantity_point<si::metre> quantity<point<si::metre>> point<kind_of<isq::length>> quantity_point<si::metre, mean_sea_level> quantity<point<si::metre, mean_sea_level>> point<kind_of<isq::length>> quantity<isq::height[m]> quantity<isq::height[m]> isq::height quantity_point<isq::height[m]> quantity<point<isq::height[m]>> point<isq::height> quantity_point<isq::altitude[m]> quantity<point<isq::altitude[m]>> point<isq::altitude> quantity_point<isq::altitude[m], mean_sea_level> quantity<point<isq::altitude[m], mean_sea_level>> point<isq::altitude> 
    I am still undecided about whether we should pursue this option, which would involve a huge design change in the library. It may even require bumping the library major version to V3.
     
    On the bright side, it would limit the number of abstractions in the library. It would also make the library more consistent with standards like ISO/IEC 80000, which talk about quantities and do not mention quantity points at all. This could also be useful before we start our work on the next big task - logarithmic quantities and units.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/","title":"Introducing absolute quantities","text":"
    This post introduces a new abstraction called an absolute quantity. It complements affine space abstractions (point and delta) and will most probably be a new default in the library when we release V3.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#affine-space-in-a-nutshell","title":"Affine space in a nutshell","text":"
    So far mp-units and other quantities and units libraries have been modeling two kinds of abstractions:
     
       
    1.  
      Points (modeled with quantity_point class template)
       
         
      • can be interpolated,
        •  
      • can be subtracted,
        •  
      • can't be added,
        •  
      • can't be multiplied or divided by another quantity or scalar,
        •  
      • some of them could be specified as non-negative,
        •  
      • specified relative to some absolute or relative point origin,
        •  
      • conversion to offset units (e.g., degree Celsius) accounts for offset.
        •  
       
      2.  
    2.  
      Deltas (modeled with quantity class template)
       
         
      • can be interpolated,
        •  
      • can be subtracted,
        •  
      • can be added,
        •  
      • can be multiplied and divided by another quantity and scalar,
        •  
      • may be negative as there is always a chance that we will subtract a larger value   from a smaller one,
        •  
      • don't use point origins in its definition,
        •  
      • conversion to offset units (e.g., degree Celsius) ignores the offset (just the conversion   factor is used).
        •  
       
      3.  
     
    Info
     
    More information on this subject can be found in the Affine Space chapter.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#issues","title":"Issues","text":"
    A current affine space implementation works well for many essential use cases. However, it also produces some issues.
     
       
    1. We can't print quantity points as, at least for today, we do not have the means to properly    describe the user-provided origin in the text output.
      2.  
    2. Quantity points are hard to use in physical equations to denote not-delta values.
      3.  
     
    To make both of the above work, a user needs to convert the quantity point to quantity with either qp.quantity_from_zero() or qp.quantity_from(some_origin) member functions.
     
    quantity_point m1(2 * kg);\nquantity_point m2(3 * kg);\nquantity_point m = m1 + m2.quantity_from_zero();\nquantity d_v = 30 * km / h;\nquantity E_k = m.quantity_from_zero() * pow<2>(d_v) / 2;\n\nstd::cout << \"Mass: \" << m.quantity_from_zero() << \"\\n\";\nstd::cout << \"Velocity: \" << d_v << \"\\n\";\nstd::cout << \"Kinetic energy: \" << E_k.in<double>(J) << \"\\n\";\n
     
    This is quite inconvenient and is a common reason for avoiding quantity point abstraction in many equations in source code where it would be a good fit otherwise.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#absolute-quantities","title":"Absolute quantities","text":"
    Despite the above drawbacks, affine space points are necessary to model some abstractions (e.g., temperatures in degrees Celsius, tared mass measurements, altitudes above some reference point, etc.) and do it really well. Constrained affine space arithmetic (e.g., preventing accidental addition of points) also improves the safety of our programs. This is why it is a very valuable abstraction and should be used even more often than now.
     
    To improve the user experience and open the doors for new features in the future, we are considering adding a third abstraction for absolute quantities. In terms of properties, an absolute quantity will lie between points and deltas.
     Feature Point Absolute Delta Interpolation Subtraction Addition Multiply/Divide May be non-negative Relative to origin Absolute & relative Absolute (implicit only) Can use offset units Conversion to offset units With offset No offset Text output 
    As we can see above, absolute quantities have only two limitations, and both are connected to the offset units' usage. They can't use those because they must remain absolute instead of being measured relative to some custom origin.
     
    It is also vital to notice that there will be no way to provide a custom origin for absolute quantities, even if it is defined in terms of absolute_point_origin. Those quantities are meant to model abstractions with well-established and unambiguous zero origins. If we allow passing absolute point origins, we could define two quantities of the same type measured according to different not-related origins, which would be too confusing.
     
    The above also allows us to print them, as we do not need any special text to describe their origin.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#interfaces-refactoring","title":"Interfaces refactoring","text":"
    As I mentioned in my previous post, we are seriously considering removing quantity_point class template and replacing it with a quantity_spec point wrapper. For example, quantity_point<isq::altitude[m]> will become quantity<point<isq::altitude[m]>>.
     
    I initially planned quantity<isq::mass> to be the same as quantity<delta<isq::mass>>, but it turns out that deltas probably should not be the default. It is consistent with how we write physical expressions on paper, right? Delta symbol (\u2206) is always \"verbose\" in our equations, it would be nice for the C++ code to do the same. So, deltas will always need to be explicit.
     
    And this brings us to absolute quantities. They should actually be the default we are looking for. This is what we write as quantities in most of the physical equations. This is why we will not need any specifier to denote them.
     
    For example:
     
    inline constexpr struct tare final : relative_point_origin<quantity_point{2 * kg}> {} tare;\n\nquantity<point<isq::mass>>       m1(10 * kg);         // point quantity with an implicit point origin\nquantity<point<isq::mass, tare>> m2 = tare + 8 * kg;  // point quantity with an explicit relative point origin\nquantity<isq::mass> \u00a0 \u00a0 \u00a0 \u00a0      m3 = 15 * kg;        // absolute quantity (e.g., non-negative)\nquantity<delta<isq::mass>>       m13 = m1 - m3;       // delta quantity (e.g., may be negative)\nquantity<delta<isq::mass>>       m23 = m2 - m3;       // delta quantity (e.g., may be negative)\n
     
    With the above, the initial example may be refactored to:
     
    quantity m1 = 2 * kg;\nquantity m2 = 3 * kg;\nquantity m = m1 + m2;\nquantity d_v = delta<km / h>(30);\nquantity E_k = m * pow<2>(d_v) / 2;\n\nstd::cout << \"Mass: \" << m << \"\\n\";\nstd::cout << \"Velocity: \" << d_v << \"\\n\";\nstd::cout << \"Kinetic energy: \" << E_k.in<double>(J) << \"\\n\";\n
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#arithmetic","title":"Arithmetic","text":"
    Affine space arithmetic is well-defined. However, we are adding a new type to the library that lands between points and deltas. This is why we must agree on the arithmetic for all possible combinations.
     
    Let's try to define them here, assuming that points and absolute values share a common origin.
     
    Note
     
    If points and absolute values do not share a common absolute point origin the operation should fail to compile.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#addition","title":"Addition","text":"
    In case of addition, a more constrained type is preserved (except for adding two points, which is undefined):
     Lhs \\ Rhs Point Absolute Delta Point Point Point Absolute Point Absolute Absolute Delta Point Absolute Delta"},{"location":"blog/2025/06/16/introducing-absolute-quantities/#subtraction","title":"Subtraction","text":"
    Subtraction is more tricky. To verify the logic below, it might be helpful to ask whether a result may be negative when two arguments are non-negative. If the answer is true, the result should be a delta quantity.
     Lhs \\ Rhs Point Absolute Delta Point Delta Point Point Absolute Delta Delta Absolute Delta Delta Delta"},{"location":"blog/2025/06/16/introducing-absolute-quantities/#new-opportunities","title":"New opportunities","text":"
    The new syntax simplifies API as one quantity class template will now serve all quantity variations (possibly even more in the future). It also allows us to model quantities that were impossible to express before without some workarounds.
     
    For example, we can now correctly calculate Carnot engine efficiency with any of the following:
     
    quantity temp_cold = 300. * K;\nquantity temp_hot = 500. * K;\nquantity carnot_eff_1 = 1. - temp_cold / temp_hot;\nquantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot;\n
     
    In the above code, we can easily create absolute or delta values of temperatures and do arithmetics on them. Previously, we had to create deltas from both points artificially with:
     
    quantity temp_cold = point<K>(300.);\nquantity temp_hot = point<K>(500.);\nquantity carnot_eff_1 = 1. - temp_cold.quantity_from_zero() / temp_hot.quantity_from_zero();\nquantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot.quantity_from_zero();\n
     
    It worked but was far from being physically pure and pretty.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#summary","title":"Summary","text":"
    We believe that adding absolute quantities will be a major improvement in the library that will allow us to more correctly model physical equations making them terser and easier to understand at the same time.
     
    We plan to deliver the features mentioned in this post as a part of mp-units V3.
     
    Please share your feedback.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/","title":"International System of Quantities (ISQ): Part 1 - Introduction","text":"
    This post starts a series of articles about the International System of Quantities (ISQ). In this series, we will describe:
     
       
    • What is ISQ?
      •  
    • Which engineering problems does ISQ help to solve and how?
      •  
    • How to model and implement it in the programming language?
      •  
    • What is missing in the ISQ, and why is that a problem?
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#terms-and-definitions","title":"Terms and Definitions","text":"
    From our experience, many people, including experts in the domain, often tend to name things differently, or sometimes they use the same term while having a different meaning in mind. This is why it is essential to stick to one well-defined glossary of terms for metrology.
     
    The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM:
     
       
    • International Organization for Standardization (ISO),
      •  
    • International Bureau of Weights and Measures (BIPM).
      •  
     
    The above are identical and contain the same set of definitions. We provide both to point out that the biggest institutions in standardizing metrology agree on the same vocabulary.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#systems-of-quantities-vs-systems-of-units","title":"Systems of Quantities vs Systems of Units","text":"
    Here are the official definitions from our vocabulary:
     
    System of quantities
     
    A system of quantities is a set of quantities together with a set of noncontradictory equations relating those quantities.
     
    System of units
     
    A system of units is a set of base units and derived units, together with their multiples and submultiples, defined in accordance with given rules, for a given system of quantities.
     
    From the definition above, we can find out that the systems of quantities and units form a hierarchy:
     
    flowchart TD\n    system_of_quantities[\"System of Quantities\"]\n    system_of_quantities --- system_of_units1[System of Units #1]\n    system_of_quantities --- system_of_units2[System of Units #2]\n    system_of_quantities --- system_of_units3[System of Units #3]
     
    System of quantities defines quantities commonly used in engineering (e.g., length, time, mass, speed, energy, power, etc.) and relations between them. It does not assign any specific units to those quantities, though.
     
    Systems of units are the ones that assign units of measurement to quantities from a specific system of quantities they chose to model. Different systems of units are free to chose whatever they find suitable for specific quantities and do not have to be consistent/compatible with other such systems. For example:
     
       
    • SI decided to measure length in meters, mass in kilograms, and time in seconds,
      •  
    • CGS decided to measure length in centimeters, mass in grams, and time in seconds.
      •  
     
    Both systems of units above agree on the unit of time, but chose different units for other quantities. In the above example, SI chose a non-prefixed unit of metre for a base quantity of length while CGS chose a scaled centimetre. On the other hand, SI chose a scaled kilogram over the gram used in the CGS. Those decisions also result in a need for different coherent units for derived quantities. For example:
     Quantity SI CGS length metre (m) centimetre (cm) mass kilogram (kg) gram (g) time second (s) second (s) force newton (N) dyne energy joule (J) erg pressure pascal (Pa) barye 
    Often, there is no way to state which one is correct or which one is wrong. Each system of units has the freedom to choose whichever unit suits its engineering requirements and constraints the best for a specific quantity.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#isq-vs-si","title":"ISQ vs SI","text":"
    Some of the systems of quantities and units have been used more over the years and have become more popular than others. Here are the official descriptions of the most popular systems used in engineering today:
     
    International System of Quantities (ISQ)
     
    The International System of Quantities (ISQ) is a system of quantities based on the seven base quantities: length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity.
     
    International System of Units (SI)
     
    The International System of Units (SI) is a system of units, based on the International System of Quantities, their names and symbols, including a series of prefixes and their names and symbols, together with rules for their use, adopted by the General Conference on Weights and Measures (CGPM).
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#the-international-system-of-quantities-isq-standardization","title":"The International System of Quantities (ISQ) standardization","text":"
    The set of quantities constituting the ISQ is defined in the series of ISO 80000 and IEC 80000 standards under the general title \"Quantities and units\".
     
    ISO 80000:
     
       
    • Part 1: General
      •  
    • Part 2: Mathematical signs and symbols to be used in the natural sciences and technology
      •  
    • Part 3: Space and time
      •  
    • Part 4: Mechanics
      •  
    • Part 5: Thermodynamics
      •  
    • Part 7: Light
      •  
    • Part 8: Acoustics
      •  
    • Part 9: Physical chemistry and molecular physics
      •  
    • Part 10: Atomic and nuclear physics
      •  
    • Part 11: Characteristic numbers
      •  
    • Part 12: Condensed matter physics
      •  
     
    IEC 80000:
     
       
    • Part 6: Electromagnetism
      •  
    • Part 13: Information science and technology
      •  
    • Part 15: Logarithmic and related quantities, and their units
      •  
    • Part 16: Printing and writing rules
      •  
    • Part 17: Time dependency
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will describe typical issues with libraries that do not model systems of quantities.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/","title":"International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used","text":"
    This article is the next one in our series about the ISQ. After introducing the basic terms and systems, this article will talk about the issues we face when we base the quantities and units library on just units or dimensions.
     
    Note
     
    The issues described in this article do not apply to the mp-units library. Its interfaces, even if when we decide only to use simple quantities that only use units, those are still backed up by quantity kinds under the framework's hood.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#limitations-of-units-only-solutions","title":"Limitations of units-only solutions","text":"
    Units-only is not a good design for a quantities and units library. It works to some extent, but plenty of use cases can't be addressed, and for those that somehow work, we miss important safety improvements provided by additional abstractions in this article series.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#no-way-to-specify-a-quantity-type-in-generic-interfaces","title":"No way to specify a quantity type in generic interfaces","text":"
    A common requirement in the domain is to write unit-agnostic generic interfaces. For example, let's try to implement a generic avg_speed function template that takes a quantity of any unit and produces the result. If we call it with distance in km and time in h, we will get km/h as a result, but if we call it with mi and h, we expect mi/h to be returned.
     
    template<Unit auto U1, typename Rep1, Unit auto U2, typename Rep2>\nauto avg_speed(quantity<U1, Rep1> distance, quantity<U2, Rep2> time)\n{\n  return distance / time;\n}\n\nquantity speed = avg_speed(120 * km, 2 * h);\n
     
    This function works but does not provide any type safety to the users. The function arguments can be easily reordered on the call site. Also, we do not get any information about the return type of the function or any safety measures to ensure that the function logic actually returns a quantity of speed.
     
    To improve safety, with a units-only library, we have to write the function in the following way:
     
    template<typename Rep1, typename Rep2>\nquantity<si::metre / si::second, decltype(Rep1{} / Rep2{})> avg_speed(quantity<si::metre, Rep1> distance,\n                                                                      quantity<si::second, Rep2> time)\n{\n  return distance / time;\n}\n\navg_speed(120 * km, 2 * h).in(km / h);\n
     
    Despite being safer, the above code decreased the performance because we always pay for the conversion at the function's input and output.
     
    Moreover, in a good library, the above code should not compile. The reason for this is that even though the conversion from km to m and from h to s is considered value-preserving, it is not true in the opposite direction. When we try to convert the result stored in an integral type from the unit of m/s to km/h, we will inevitably lose some data.
     
    We could try to provide concepts like ScaledUnitOf<si::metre> that would take a set of units while trying to constrain them somehow, but it leads to even more problems with the unit definitions. For example, are Hz and Bq just scaled versions of 1/s? If we constrain the interface to just prefixed units, then litre and a cubic metre or kilometre and mile will be incompatible. What about radian and steradian or a litre per 100 kilometre (popular unit of a fuel consumption) and a squared metre? Should those be compatible?
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#disjoint-units-of-the-same-quantity-type-do-not-work","title":"Disjoint units of the same quantity type do not work","text":"
    Sometimes, we need to define several units describing the same quantity but which should not convert to each other in the library's framework. A typical example here is currency. A user may want to define EURO and USD as units of currency, so both of them can be used for such quantities. However, it is impossible to predefine one fixed conversion factor for those, as a currency exchange rate varies over time, and the library's framework can't provide such an information as an input to the built-in conversion function. User's application may have more information in this domain and handle such a conversion at runtime with custom logic (e.g., using an additional time point function argument). If we would like to model that in a unit-only solution, how can we specify that EURO and USD are units of quantities of currency, but are not convertible to each other?
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#dimensions-to-the-rescue","title":"Dimensions to the rescue?","text":"
    To resolve the above issues, most of the libraries on the market introduce dimension abstraction. Thanks to that, we could solve the first issue of the previous chapter with:
     
    QuantityOf<dim_speed> auto avg_speed(QuantityOf<dim_length> auto distance,\n                                     QuantityOf<dim_time> auto time)\n{\n  return distance / time;\n}\n
     
    and the second one by specifying that both EURO and USD are units of dim_currency. This is a significant improvement but still has some issues.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#limitations-of-dimensions","title":"Limitations of dimensions","text":"
    Let's first look at the above solution again. A domain expert seeing this code will immediately say there is no such thing as a speed dimension. The ISQ specifies only 7 dimensions with unique symbols assigned, and the dimensions of all the ISQ quantities are created as a vector product of those. For example, a quantity of speed has a dimension of \\(L^1T^{-1}\\). So, to be physically correct, the above code should be rewritten as:
     
    QuantityOf<dim_length / dim_time> auto avg_speed(QuantityOf<dim_length> auto distance,\n                                                 QuantityOf<dim_time> auto time)\n{\n  return distance / time;\n}\n
     
    Most of the libraries on the market ignore this fact and try to model distinct quantities through their dimensions, giving a false sense of safety. A dimension is not enough to describe a quantity. This has been known for a long time now. The \"Measurement Data (Archive Report)\" report from 1996 says explicitly:
     
    Measurement Data (Archive Report)
     
    Dimensional analysis does not adequately model the semantics of measurement data.
     
    In the following chapters, we will see a few use cases that can't be solved with an approach that only relies on units or dimensions.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#si-units-of-quantities-of-the-same-dimension-but-different-kinds","title":"SI units of quantities of the same dimension but different kinds","text":"
    The SI provides several units for distinct quantities of the same dimension but different kinds. For example:
     
       
    • hertz (Hz) is a unit of frequency and becquerel (Bq) is a unit of activity.   Both are defined as \\(s^{-1}\\), and have the same dimension of \\(T^{-1}\\).
      •  
    • gray (Gy) is a unit of absorbed dose and sievert (Sv) is a unit of dose equivalent.   Both are defined as \\(m^2 s^{-2}\\), and have the same dimension of \\(L^2T^{-2}\\)
      •  
    • radian (rad) is a unit of plane angle defined as \\(m/m\\), and   steradian (sr) is a unit of solid angle defined as \\(m^2/m^2\\).   Both are quantities of dimension one, which also has its own units like one (1) and percent (%).
      •  
     
    There are many more similar examples in the ISO/IEC 80000 series. For example, storage capacity quantity can be measured in units of one, bit, octet, and byte.
     
    The above conflicts can't be solved with dimensions, and they yield many safety issues. For example, we can ask ourselves what should be the result of the following:
     
       
    1. quantity q = 1 * Hz + 1 * Bq;
      2.  
    2. quantity<Gy> q = 42 * Sv;
      3.  
    3. bool b = (1 * rad + 1 * bit) == 2 * sr;
      4.  
     
    None of the above code should compile, but most of the libraries on the market happily accept it and provide meaningless results. Some of them decide not to define one or more of the above units at all to avoid potential safety issues. For example, the Au library does not define Sv to avoid mixing it up with Gy.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#derived-quantities-of-the-same-dimension-but-different-kinds","title":"Derived quantities of the same dimension but different kinds","text":"
    Even if some quantities do not have a specially assigned unit, they may still have a totally different physical meaning even if they share the same dimension:
     
       
    • work vs. moment of force both of the same dimension \\(L^2MT^{-2}\\),
      •  
    • fuel consumption expressed in \\(\\frac{l}{100\\;km}\\) vs. area expressed in \\(m^2\\) both of the same   dimension \\(L^2\\).
      •  
     
    Again, we don't want to accidentally mix those.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#various-quantities-of-the-same-dimension-and-kinds","title":"Various quantities of the same dimension and kinds","text":"
    Even if we somehow address all the above, there are plenty of use cases that still can't be safely implemented with such abstractions.
     
    Let's consider that we want to implement a freight transport application to position cargo in the container. In majority of the products on the market we will end up with something like:
     
    class Box {\n  length length_;\n  length width_;\n  length height_;\npublic:\n  Box(length l, length w, length h): length_(l), width_(w), height_(h) {}\n  area floor() const { return length_ * width_; }\n  // ...\n};\n
     
    Box my_box(2 * m, 3 * m, 1 * m);\n
     
    Such interfaces are not much safer than just using plain fundamental types (e.g., double). One of the main reasons of using a quantities and units library was to introduce strong-type interfaces to prevent such issues. In this scenario, we need to be able to discriminate between length, width, and height of the package.
     
    A similar but also really important use case is in aviation. The current altitude is a totally different quantity than the distance to the destination. The same is true for forward speed and sink rate. We do not want to accidentally mix those.
     
    When we deal with energy, we should be able to implicitly construct it from a proper product of any mass, length, and time. However, when we want to calculate gravitational potential energy, we may not want it to be implicitly initialized from any expression of matching dimensions. Such an implicit construction should be allowed only if we multiply a mass with acceleration of free fall and height. All other conversions should have an explicit annotation to make it clear that something potentially unsafe is being done in the code. Also, we should not be able to assign a potential energy to a quantity of kinetic energy. However, both of them (possibly accumulated with each other) should be convertible to a mechanical energy quantity.
     
    mass m = 1 * kg;\nlength l = 1 * m;\ntime t = 1 * s;\nacceleration_of_free_fall g = 9.81 * m / s2;\nheight h = 1 * m;\nspeed v = 1 * m / s;\nenergy e = m * pow<2>(l) / pow<2>(t);                     // OK\npotential_energy ep1 = e;                                 // should not compile\npotential_energy ep2 = static_cast<potential_energy>(e);  // OK\npotential_energy ep3 = m * g * h;                         // OK\nkinetic_energy ek1 = m * pow<2>(v) / 2;                   // OK\nkinetic_energy ek2 = ep3 + ek1;                           // should not compile\nmechanical_energy me = ep3 + ek1;                         // OK\n
     
    Yet another example comes from the audio industry. In the audio software, we want to treat specific counts (e.g., beats, samples) as separate quantities. We could assign dedicated base dimensions to them. However, if we divide them by duration, we should obtain a quantity convertible to frequency and even be able to express the result in a unit of Hz. With the dedicated dimensions approach, this wouldn't work as the dimension of frequency is just \\(T^{-1}\\), which would not match the results of our dimensional equations. This is why we can't assign dedicated dimensions to such counts.
     
    The last example that we want to mention here comes from finance. This time, we need to model currency volume as a special quantity of currency. currency volume can be obtained by multiplying currency by the dimensionless market quantity. Of course, both currency and currency volume should be expressed in the same units (e.g., USD).
     
    None of the above scenarios can be addressed with just units and dimensions. We need a better abstraction to safely implement them.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will introduce the main ideas behind the International System of Quantities and describe how we can model it in the programming language.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/","title":"International System of Quantities (ISQ): Part 3 - Modeling ISQ","text":"
    The physical units libraries on the market typically only focus on modeling one or more systems of units. However, as we have learned, this is not the only system kind to model. Another, and maybe even more important, is a system of quantities. The most important example here is the International System of Quantities (ISQ) defined by ISO/IEC 80000.
     
    This article continues our series about the International System of Quantities. This time, we will learn about the main ideas behind the ISQ and describe how it can be modelled in a programming language.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"
    Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. Let's repeat briefly some of the problems described in more detail in the previous article. For example, let's see the following implementation:
     
    class Box {\n  area base_;\n  length height_;\npublic:\n  Box(length l, length w, length h) : base_(l * w), height_(h) {}\n  // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\n
     
    How do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do. 
     
    Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are distinct quantities.
     
    A similar issue is related to figuring out what should be the result of:
     
    auto res = 1 * Hz + 1 * Bq + 1 * Bd;\n
     
    where:
     
       
    • Hz (hertz) - unit of frequency,
      •  
    • Bq (becquerel) - unit of activity,
      •  
    • Bd (baud) - unit of modulation rate.
      •  
     
    All of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
     
    If the above example seems too abstract, let's consider Gy (gray - unit of absorbed dose) and Sv (sievert - unit of dose equivalent), or radian and steradian. All of those quantities have the same dimensions.
     
    Another example here is fuel consumption (fuel volume divided by distance, e.g., 6.7 l/100km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
     
    It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"
    As it was described in the previous article, dimension is not enough to describe a quantity. We need a better abstraction to ensure the safety of our calculations. It turns out that ISO/IEC 80000 comes with the answer:
     
    ISO 80000-1:2009
     
       
    • Quantities may be grouped together into categories of quantities that are   mutually comparable.
      •  
    • Mutually comparable quantities are called quantities of the same kind.
      •  
    • Two or more quantities cannot be added or subtracted unless they belong to the same category   of mutually comparable quantities.
      •  
    • Quantities of the same kind within a given system of quantities have the same quantity   dimension.
      •  
    • Quantities of the same dimension are not necessarily of the same kind.
      •  
     
    ISO Guide also explicitly states:
     
    ISO Guide
     
    Measurement units of quantities of the same quantity dimension may be designated by the same name and symbol even when the quantities are not of the same kind. For example, joule per kelvin and J/K are respectively the name and symbol of both a measurement unit of heat capacity and a measurement unit of entropy, which are generally not considered to be quantities of the same kind. However, in some cases special measurement unit names are restricted to be used with quantities of specific kind only. For example, the measurement unit \u2018second to the power minus one\u2019 (1/s) is called hertz (Hz) when used for frequencies and becquerel (Bq) when used for activities of radionuclides. As another example, the joule (J) is used as a unit of energy, but never as a unit of moment of force, i.e. the newton metre (N \u00b7 m).
     
    The above quotes from ISO provide answers to all the issues mentioned above and in the previous article.
     
    More than one quantity may be defined for the same dimension:
     
       
    • quantities of different kinds (e.g., frequency, modulation rate, activity).
      •  
    • quantities of the same kind (e.g., length, width, altitude, distance, radius,   wavelength, position vector).
      •  
     
    Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are of different kinds, the expression provided above should not compile.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"
    ISO/IEC 80000 specifies hundreds of different quantities. Plenty of various kinds are provided, and often, each kind contains more than one quantity. It turns out that such quantities form a hierarchy of quantities of the same kind.
     
    For example, here are all quantities of the kind length provided in the ISO 80000-3:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    Each of the above quantities expresses some kind of length, and each can be measured with meters, which is the unit defined by the SI for quantities of length. However, each has different properties, usage, and sometimes even a different character (position vector and displacement are vector quantities).
     
    Forming such a hierarchy helps us define arithmetics and conversion rules for various quantities of the same kind.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#converting-between-quantities-of-the-same-kind","title":"Converting between quantities of the same kind","text":"
    Based on the hierarchy above, we can define the following quantity conversion rules:
     
       
    1.  
      Implicit conversions
       
         
      • Every width is a length.
        •  
      • Every radius is a width.
        •  
       
      static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\n
       
      Implicit conversions are allowed on copy-initialization:
       
      void foo(quantity<isq::length[m]> q);\n
       
      quantity<isq::width[m]> q1 = 42 * m;\nquantity<isq::length[m]> q2 = q1;  // implicit quantity conversion\nfoo(q1);                           // implicit quantity conversion\n
       
      2.  
    2.  
      Explicit conversions
       
         
      • Not every length is a width.
        •  
      • Not every width is a radius.
        •  
       
      static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\n
       
      Explicit conversions are forced by passing the quantity to a call operator of a quantity_spec type:
       
      void foo(quantity<isq::height[m]> q);\n
       
      quantity<isq::length[m]> q1 = 42 * m;\nquantity<isq::height[m]> q2 = isq::height(q1);  // explicit quantity conversion\nfoo(isq::height(q1));                           // explicit quantity conversion\n
       
      3.  
    3.  
      Explicit casts
       
         
      • height is never a width, and vice versa.
        •  
      • Both height and width are quantities of kind length.
        •  
       
      static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\n
       
      Explicit casts are forced with a dedicated quantity_cast function:
       
      void foo(quantity<isq::height[m]> q);\n
       
      quantity<isq::width[m]> q1 = 42 * m;\nquantity<isq::height[m]> q2 = quantity_cast<isq::height>(q1);  // explicit quantity cast\nfoo(quantity_cast<isq::height>(q1));                           // explicit quantity cast\n
       
      4.  
    4.  
      No conversion
       
         
      • time has nothing in common with length.
        •  
       
      static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\n
       
      Even the explicit casts will not force such a conversion:
       
      void foo(quantity<isq::length[m]>);\n
       
      quantity<isq::length[m]> q1 = 42 * s;    // Compile-time error\nfoo(quantity_cast<isq::length>(42 * s)); // Compile-time error\n
       
      5.  
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#comparing-adding-and-subtracting-quantities-of-the-same-kind","title":"Comparing, adding, and subtracting quantities of the same kind","text":"
    ISO/IEC 80000 explicitly states that width and height are quantities of the same kind, and as such they:
     
       
    • are mutually comparable,
      •  
    • can be added and subtracted.
      •  
     
    This means that we should be allowed to compare any quantities from the same tree (as long as their underlying representation types are comparable):
     
    static_assert(isq::radius(1 * m) == isq::height(1 * m));\n
     
    Also, based on our hierarchy above, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
     
    static_assert((isq::width(1 * m) + isq::height(1 * m)).quantity_spec == isq::length);\nstatic_assert((isq::thickness(1 * m) + isq::radius(1 * m)).quantity_spec == isq::width);\nstatic_assert((isq::distance(1 * m) + isq::path_length(1 * m)).quantity_spec == isq::path_length);\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#modeling-a-quantity-kind","title":"Modeling a quantity kind","text":"
    In the quantities and units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
     
    To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
     
    Important
     
    isq::length and kind_of<isq::length> are two different things.
     
    Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
     
    static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\n
     
    Additionally, the result of operations on quantity kinds is also a quantity kind:
     
    static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\n
     
    However, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
     
    static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\n
     
    Info
     
    Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
     
    static_assert(get_kind(isq::width) == kind_of<isq::length>);\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#how-do-systems-of-units-benefit-from-the-isq-and-quantity-kinds","title":"How do systems of units benefit from the ISQ and quantity kinds?","text":"
    Modeling a system of units is the most essential feature and a selling point of every physical units library. Thanks to that, the library can protect users from assigning, adding, subtracting, or comparing incompatible units and provide automated conversion factors between various compatible units.
     
    Probably all the libraries in the wild model the SI (or at least most of it), and many of them provide support for additional units belonging to various other systems (e.g., imperial).
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of units are based on systems of quantities","text":"
    Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. In order to create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
     
    The SI is explicitly stated to be based on the ISQ. Among others, it defines seven base units, one for each base quantity of ISQ. In the library, this is expressed by associating a quantity kind to a unit being defined:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\n
     
    The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
     
    Note
     
    For some systems of units (e.g., natural units), a unit may not have an associated quantity type. For example, if we define the speed of light constant as c = 1, we can define a system where both length and time will be measured in seconds, and speed will be a quantity measured with the unit one. In such case, the definition will look as follows:
     
    inline constexpr struct second final : named_unit<\"s\"> {} second;\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"
    Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation \\(s^{-1}\\). However, it also explicitly states:
     
    SI
     
    The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
     
    This is why it is important for the library to allow constraining such units to be used only with a specific quantity kind:
     
    inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\n
     
    With the above, hertz can only be used for frequencies, while becquerel should only be used for quantities of activity:
     
    quantity<isq::frequency[Hz]> q1 = 60 * Bq;   // Compile-time error\nquantity<isq::activity[Hz]> q2;              // Compile-time error\nquantity<isq::frequency[Hz]> q3 = 60 * Hz;   // OK\nstd::cout << q3.in(Bq) << \"\\n\";              // Compile-time error\n
     
    We know already that quantities of different kinds can't be compared, added, and subtracted. The following equation will not compile thanks to constraining derived units to be valid for specific kinds only:
     
    auto q = 1 * Hz + 1 * Bq;   // Fails to compile\n
     
    All of the above features improve the safety of our library and the products that are using it.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will present how we can implement our ISQ model in a C++ programming language and we will point out some of the first issues that stand in our way.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/","title":"International System of Quantities (ISQ): Part 4 - Implementing ISQ","text":"
    Up until now, we have introduced the International System of Quantities and described how we can model its main aspects. This article will present how to implement those models in a programming language, and we will point out some of the first issues that stand in our way.
     
    In the previous article, we have already introduced a notion of quantity kind, provided kind_of<> specifier, and described how it helps in the modeling of the system of units (e.g., SI).
     
    Now, it is time to see how we can implement hierarchies of quantities of the same kind.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-length","title":"Modeling a hierarchy of kind length","text":"
    First, let's start with something easy - hierarchy of kind length. ISO 80000-3 does a good job of describing all relations between quantities in this case.
     
    We've seen this tree already:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    This is how we can model it in C++:
     
    inline constexpr struct dim_length final          : base_dimension<\"L\"> {} dim_length;\n\ninline constexpr struct length final              : quantity_spec<dim_length> {} length;\ninline constexpr struct width final               : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final              : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final           : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final            : quantity_spec<width> {} diameter;\ninline constexpr struct radius final              : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final         : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final            : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final     : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final          : quantity_spec<length> {} wavelength;\ninline constexpr struct displacement final        : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final     : quantity_spec<displacement> {} position_vector;\n
     
    Thanks to the expressivity and power of C++ templates, we can specify all quantity properties in one line of code. In the above code:
     
       
    • length takes the base dimension to indicate that we are creating a base quantity that will serve   as a root for a tree of quantities of the same kind,
      •  
    • width and following quantities are branches and leaves of this tree with the parent always   provided as the first argument to quantity_spec class template,
      •  
    • breadth is an alias name for the same quantity as width.
      •  
     
    Note
     
    Some quantities may be specified to have complex scalar, vector, or tensor character (e.g., displacement). The quantity character can be set with the last parameter of quantity_spec.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-energy","title":"Modeling a hierarchy of kind energy","text":"
    Base quantities are simple. It is more complicated when we start modeling derived quantities. Let's try to model the hierarchy for energy.
     
    When we look into the ISO/IEC 80000 standards, this task immediately stops being as easy as the previous one. Derived quantity equations often do not automatically form a hierarchy tree, and ISO/IEC standards do not provide a clear answer to inter-quantity dependencies. This is why it is often not obvious what such a tree should look like.
     
    Even more, ISO explicitly states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    Let's try anyway. The below presents some arbitrary hierarchy of derived quantities of kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    potential_energy --- gravitational_potential_energy[\"<b>gravitational_potential_energy</b><br><i>(mass * acceleration_of_free_fall * height)</i>\"]\n    potential_energy --- elastic_potential_energy[\"<b>elastic_potential_energy</b><br><i>(spring_constant * amount_of_compression<sup>2</sup>)</i>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b><br><i>(mass * speed<sup>2</sup>)</i>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    As we can see above, besides what we've already seen for length hierarchy, derived quantities may provide specific recipes that can be used to create them implicitly:
     
       
    •  
      energy is the most generic one and thus can be created from base quantities of mass,   length, and time. As those are also the roots of quantities of their kinds and all other   quantities from their trees are implicitly convertible to them, it means that an energy can be   implicitly constructed from any quantity of mass, length, and time:
       
      static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\n
       
      •  
    •  
      mechanical energy is a more \"specialized\" quantity than energy (not every energy is   a mechanical energy). It is why an explicit cast is needed to convert from either energy or   the results of its quantity equation:
       
      static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     isq::mechanical_energy));\n
       
      •  
    •  
      gravitational potential energy is not only even more specialized one but additionally,   it is special in a way that it provides its own \"constrained\"   quantity equation. Maybe not every   mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every   mass * acceleration_of_free_fall * height is.
       
      static_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n                                     gravitational_potential_energy));\n
       
      •  
     
    And here is the C++ code for it:
     
    inline constexpr struct energy final                         : quantity_spec<mass* pow<2>(length) / pow<2>(time)> {} energy;\ninline constexpr struct mechanical_energy final              : quantity_spec<energy> {} mechanical_energy;                                                            // differs from ISO 80000\ninline constexpr struct potential_energy final               : quantity_spec<mechanical_energy> {} potential_energy;                                                  // differs from ISO 80000\ninline constexpr struct gravitational_potential_energy final : quantity_spec<potential_energy, mass * acceleration_of_free_fall * height> {} potential_energy;        // not in ISO 80000\ninline constexpr struct elastic_potential_energy final       : quantity_spec<potential_energy, spring_constant * pow<2>(amount_of_compression)> {} potential_energy;  // not in ISO 80000\ninline constexpr struct kinetic_energy final                 : quantity_spec<mechanical_energy, mass* pow<2>(speed)> {} kinetic_energy;                               // differs from ISO 80000\ninline constexpr struct enthalpy final                       : quantity_spec<energy> {} enthalpy;                                                                     // differs from ISO 80000\ninline constexpr struct internal_energy final                : quantity_spec<enthalpy> {} internal_energy;                                                            // differs from ISO 80000\ninline constexpr auto thermodynamic_energy = internal_energy;\ninline constexpr struct Helmholtz_energy final               : quantity_spec<internal_energy> {} Helmholtz_energy;\ninline constexpr auto Helmholtz_function = Helmholtz_energy;\ninline constexpr struct Gibbs_energy final                   : quantity_spec<enthalpy> {} Gibbs_energy;\ninline constexpr auto Gibbs_function = Gibbs_energy;\n
     
    Again, the first parameter of quantity_spec determines the position in the tree. If a second argument is provided, it denotes a recipe for this quantity.
     
    With the above simple definitions we've automatically addressed our energy-related issues from the Various quantities of the same dimension and kinds chapter of the \"Part 2\" article.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-dimensionless","title":"Modeling a hierarchy of kind dimensionless","text":"
    As the last example for this article, let's try to model and implement quantities of dimension one, often also called dimensionless quantities. This quantity hierarchy contains more than one quantity kind and more than one unit in its tree:
     
    flowchart TD\n    dimensionless[\"<b>dimensionless</b><br>[one]\"]\n    dimensionless --- rotation[\"<b>rotation</b>\"]\n    dimensionless --- thermodynamic_efficiency[\"<b>thermodynamic_efficiency</b><br><i>(work / heat)</i>\"]\n    dimensionless --- angular_measure[\"<b>angular_measure</b><br><i>(arc_length / radius)</i><br>[rad]\"]\n    angular_measure --- rotational_displacement[\"<b>rotational_displacement</b><br><i>(path_length / radius)</i>\"]\n    angular_measure --- phase_angle[\"<b>phase_angle</b>\"]\n    dimensionless --- solid_angular_measure[\"<b>solid_angular_measure</b><br><i>(area / pow<2>(radius))</i><br>[sr]\"]\n    dimensionless --- drag_factor[\"<b>drag_factor</b><br><i>(drag_force / (mass_density * pow<2>(speed) * area))</i>\"]\n    dimensionless --- storage_capacity[\"<b>storage_capacity</b><br>[bit]\"] --- equivalent_binary_storage_capacity[\"<b>equivalent_binary_storage_capacity</b>\"]\n    dimensionless --- ...
     
    To enable such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
     
    inline constexpr struct dimensionless final            : quantity_spec<detail::derived_quantity_spec<>{}> {} dimensionless;\ninline constexpr struct rotation final                 : quantity_spec<dimensionless> {} rotation;\ninline constexpr struct thermodynamic_efficiency final : quantity_spec<dimensionless, work / heat> {} efficiency;\ninline constexpr struct angular_measure final          : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct rotational_displacement final  : quantity_spec<angular_measure, path_length / radius> {} rotational_displacement;\ninline constexpr struct phase_angle final              : quantity_spec<angular_measure> {} phase_angle;\ninline constexpr struct solid_angular_measure final    : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct drag_factor final              : quantity_spec<dimensionless, drag_force / (mass_density * pow<2>(speed) * area)> {} drag_factor;\ninline constexpr struct storage_capacity final         : quantity_spec<dimensionless, is_kind> {} storage_capacity;\n
     
    With the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
     
    inline constexpr struct radian final    : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final       : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\n
     
    but still allow the usage of one and its scaled versions for such quantities.
     
    Note
     
    dimensionless is a special quantity which serves as an identity element in quantity equations. It is predefined in the library's framework and there is no way for the user to define it or something similar to it.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will present how our ISQ model helps to address the remaining issues described in the Part 2 of our series.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/","title":"International System of Quantities (ISQ): Part 5 - Benefits","text":"
    In the previous articles, we introduced the International System of Quantities, described how we can model and implement it in a programming language, and presented the issues of software that does not use such abstraction to implement a units library.
     
    Some of the issues raised in Part 2 of our series were addressed in Part 3 already. This article will present how our ISQ model elegantly addresses the remaining problems.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#generic-but-safe-interfaces","title":"Generic but safe interfaces","text":"
    Let's start with the implementation of a generic utility function that would calculate the average speed based on provided arguments. The resulting quantity should use a derived unit of the provided arguments (e.g., km/h for km and h, m/s for m and s, ...).
     
    With C++ concepts backed up with ISQ quantities, we can simply type it as:
     
    constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    The above constrains the algorithm to proper quantity types and ensures that a quantity of speed is returned. The latter is essential not only for the users to better understand what the function does but also serves as a unit test for our implementation. It ensures that our quantity equations are correct in the implementation part of the function, and we indeed return a quantity of speed.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#non-convertible-units-of-currency","title":"Non-convertible units of currency","text":"
    Our second example was about disjoint units of currency. We want to use various units of currency but we can't provide compile-time known conversion factors between those as such ratios are only known at runtime.
     
    First, we define:
     
       
    • a new dimension for currency and a quantity type based on it,
      •  
    • set of disjoint units of currency for its quantity kind.
      •  
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct euro final : named_unit<\"EUR\", kind_of<currency>> {} euro;\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto EUR = euro;\ninline constexpr auto USD = us_dollar;\n\n}\n\nstatic_assert(!std::equality_comparable_with<quantity<euro, int>, quantity<us_dollar, int>>);\n
     
    Next, we can provide a custom currency exchange facility that accounts for a specific point in time:
     
    template<Unit auto From, Unit auto To>\n[[nodiscard]] double exchange_rate(std::chrono::sys_seconds timestamp)\n{\n  // user-provided logic...\n}\n\ntemplate<UnitOf<currency> auto To, QuantityOf<currency> From>\nQuantityOf<currency> auto exchange_to(From q, std::chrono::sys_seconds timestamp)\n{\n  const auto rate =\n    static_cast<From::rep>(exchange_rate<From::unit, To>(timestamp) * q.numerical_value_in(q.unit));\n  return rate * From::quantity_spec[To];\n}\n
     
    Finally, we can use our simple model in the following way:
     
    using namespace unit_symbols;\nusing namespace std::chrono;\n\nconst auto yesterday = time_point_cast<seconds>(system_clock::now() - hours{24});\nconst quantity price_usd = 100 * USD;\nconst quantity price_euro = exchange_to<euro>(price_usd, yesterday);\n\nstd::cout << price_usd << \" -> \" << price_euro << \"\\n\";\n// std::cout << price_usd + price_euro << \"\\n\";  // does not compile\n
     
    Note
     
    It would be better to model the above prices as quantity points, but this is a subject for a different article .
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#derived-quantities-of-the-same-dimension-but-different-kinds","title":"Derived quantities of the same dimension but different kinds","text":"
    Until now, the issues discussed have not actually required modeling of the ISQ. The introduction of physical dimensions would be enough, and indeed, this is what most of the libraries on the market do. However, we have more exciting challenges to solve as well.
     
    The next issue was related to different quantities having the same dimension. In many cases, we want to prevent conversions and any other compatibility between such distinct quantities.
     
    Let's try to implement our fuel consumption example. First, we define the quantity type and a handy identifier for a derived unit that we want to use:
     
    inline constexpr struct fuel_consumption final : quantity_spec<isq::volume / isq::length> {} fuel_consumption;\ninline constexpr auto L_per_100km = si::litre / (mag<100> * si::kilo<si::metre>);\n\nstatic_assert(fuel_consumption != isq::area);\nstatic_assert(fuel_consumption.dimension == isq::area.dimension);\n
     
    Next, we define two quantities. The first one is based only on a derived unit of L/[100 km], while the second uses a strongly typed quantity type:
     
    quantity q1 = 5.8 * L_per_100km;\nquantity q2 = fuel_consumption(6.7 * L_per_100km);\nstd::println(\"Fuel consumptions: {}, {}\", q1, q2);\n\nstatic_assert(implicitly_convertible(q1.quantity_spec, isq::area));\nstatic_assert(!implicitly_convertible(q2.quantity_spec, isq::area));\nstatic_assert(!explicitly_convertible(q2.quantity_spec, isq::area));\nstatic_assert(!castable(q2.quantity_spec, isq::area));\n
     
    As we can see, with just units (especially derived ones) and dimensions, we often can't achieve the same level of safety as with adequately modeled hierarchies of quantities. Only in case of q2 we can prevent incorrect conversions to a different quantity of the same dimension.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#various-quantities-of-the-same-dimension-and-kinds","title":"Various quantities of the same dimension and kinds","text":"
    In the previous example, area and fuel consumption were quantities of the same dimension but of different kinds. In engineering, there are also many cases where we need to model distinct quantities of the same kind.
     
    Let's try to improve the safety of our Box example.
     
    First, we need to extend our ISQ definitions by the horizontal length quantity and a horizontal area derived from it:
     
    inline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\ninline constexpr struct horizontal_area final : quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n
     
    Note
     
    isq::length denotes any quantity of length (not only the horizontal one).
     
    static_assert(implicitly_convertible(horizontal_length, isq::length));\nstatic_assert(!implicitly_convertible(isq::length, horizontal_length));\n\nstatic_assert(implicitly_convertible(horizontal_area, isq::area));\nstatic_assert(!implicitly_convertible(isq::area, horizontal_area));\n\nstatic_assert(implicitly_convertible(isq::length * isq::length, isq::area));\nstatic_assert(!implicitly_convertible(isq::length * isq::length, horizontal_area));\n\nstatic_assert(implicitly_convertible(horizontal_length * isq::width, isq::area));\nstatic_assert(implicitly_convertible(horizontal_length * isq::width, horizontal_area));\n
     
    With simple two lines of definition, we made the above logic automatically work without needing additional customization for special cases. Based on hierarchies of derived quantities and their recipes, the proposed model automatically inherits the properties of base quantities involved in the recipe. This makes the composition of derived quantities very easy, which is not true for alternative solutions based on tag types that do not compose their properties.
     
    Now we can refactor our Box to benefit from the introduced safe abstractions:
     
    class Box {\n  quantity<horizontal_length[m]> length_;\n  quantity<isq::width[m]> width_;\n  quantity<isq::height[m]> height_;\npublic:\n  Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n    length_(l), width_(w), height_(h)\n  {}\n\n  quantity<horizontal_area[m2]> floor() const { return length_ * width_; }\n  // ...\n};\n
     
    It is important to note that the safety can be enforced only when a user provides typed quantities as arguments to the functions:
     
    Box my_box1(2 * m, 3 * m, 1 * m);\nBox my_box2(2 * horizontal_length[m], 3 * isq::width[m], 1 * isq::height[m]);\nBox my_box3(horizontal_length(2 * m), isq::width(3 * m), isq::height(1 * m));\n
     
    Important
     
    It is up to the user to decide when and where to care about explicit quantity types and when to prefer simple unit-only mode.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#various-kinds-of-dimensionless-quantities","title":"Various kinds of dimensionless quantities","text":"
    Most of the quantities hierarchies describe only one kind. There are some exceptions, though. One of them is a hierarchy of dimensionless quantities. This tree defines quantities that denote:
     
       
    • counts (e.g., storage capacity),
      •  
    • ratios (e.g., efficiency),
      •  
    • angles (e.g., angular measure, solid angular measure),
      •  
    • scaled numbers.
      •  
     
    Each of the above could form a separate tree of mutually comparable quantities. However, all of them have a common property. Every quantity from this tree, despite often being measured in a dedicated unit (e.g., bit, rad, sr), should also be able to be measured in a unit one.
     
    We've seen how to model such a hierarchy in a previous article in our series. This time, we will see a simplified part of a concrete, real-life example for this use case.
     
    We often need to provide strong types for different counts in the digital signal processing domain. Abstractions like samples, beats, MIDI clock, and others should not be possible to be intermixed with each other:
     
    namespace ni {\n\ninline constexpr struct SampleCount final : quantity_spec<dimensionless, is_kind> {} SampleCount;\ninline constexpr struct UnitSampleAmount final : quantity_spec<dimensionless, is_kind> {} UnitSampleAmount;\ninline constexpr struct MIDIClock final : quantity_spec<dimensionless, is_kind> {} MIDIClock;\ninline constexpr struct BeatCount final : quantity_spec<dimensionless, is_kind> {} BeatCount;\n
     
    We should also be able to create derived quantities from those. For example, when we divide such a quantity by time we should get a new strong quantity that can be measured in both a dedicated unit (e.g., Smpl/s for sample rate) and hertz:
     
    inline constexpr struct SampleDuration final : quantity_spec<isq::period_duration> {} SampleDuration;\ninline constexpr struct SamplingRate final : quantity_spec<isq::frequency, SampleCount / SampleDuration> {} SamplingRate;\n\ninline constexpr auto Amplitude = UnitSampleAmount;\ninline constexpr auto Level = UnitSampleAmount;\ninline constexpr struct Power final : quantity_spec<Level * Level> {} Power;\n\ninline constexpr struct BeatDuration final : quantity_spec<isq::period_duration> {} BeatDuration;\ninline constexpr struct Tempo final : quantity_spec<isq::frequency, BeatCount / BeatDuration> {} Tempo;\n
     
    We can also define a collection of units associated with specific quantity kinds and their symbols:
     
    inline constexpr struct Sample final : named_unit<\"Smpl\", one, kind_of<SampleCount>> {} Sample;\ninline constexpr struct SampleValue final : named_unit<\"PCM\", one, kind_of<UnitSampleAmount>> {} SampleValue;\ninline constexpr struct MIDIPulse final : named_unit<\"p\", one, kind_of<MIDIClock>> {} MIDIPulse;\n\ninline constexpr struct QuarterNote final : named_unit<\"q\", one, kind_of<BeatCount>> {} QuarterNote;\ninline constexpr struct HalfNote final : named_unit<\"h\", mag<2> * QuarterNote> {} HalfNote;\ninline constexpr struct DottedHalfNote final : named_unit<\"h.\", mag<3> * QuarterNote> {} DottedHalfNote;\ninline constexpr struct WholeNote final : named_unit<\"w\", mag<4> * QuarterNote> {} WholeNote;\ninline constexpr struct EightNote final : named_unit<\"8th\", mag_ratio<1, 2> * QuarterNote> {} EightNote;\ninline constexpr struct DottedQuarterNote final : named_unit<\"q.\", mag<3> * EightNote> {} DottedQuarterNote;\ninline constexpr struct QuarterNoteTriplet final : named_unit<\"qt\", mag_ratio<1, 3> * HalfNote> {} QuarterNoteTriplet;\ninline constexpr struct SixteenthNote final : named_unit<\"16th\", mag_ratio<1, 2> * EightNote> {} SixteenthNote;\ninline constexpr struct DottedEightNote final : named_unit<\"q.\", mag<3> * SixteenthNote> {} DottedEightNote;\n\ninline constexpr auto Beat = QuarterNote;\n\ninline constexpr struct BeatsPerMinute final : named_unit<\"bpm\", Beat / si::minute> {} BeatsPerMinute;\ninline constexpr struct MIDIPulsePerQuarter final : named_unit<\"ppqn\", MIDIPulse / QuarterNote> {} MIDIPulsePerQuarter;\n\nnamespace unit_symbols {\n\ninline constexpr auto Smpl = Sample;\ninline constexpr auto pcm = SampleValue;\ninline constexpr auto p = MIDIPulse;\n\ninline constexpr auto n_wd = 3 * HalfNote;\ninline constexpr auto n_w = WholeNote;\ninline constexpr auto n_hd = DottedHalfNote;\ninline constexpr auto n_h = HalfNote;\ninline constexpr auto n_qd = DottedQuarterNote;\ninline constexpr auto n_q = QuarterNote;\ninline constexpr auto n_qt = QuarterNoteTriplet;\ninline constexpr auto n_8thd = DottedEightNote;\ninline constexpr auto n_8th = EightNote;\ninline constexpr auto n_16th = SixteenthNote;\n\n}\n\n}  // namespace ni\n
     
    With the above, we can safely work with each quantity and use SI or domain-specific units as needed:
     
    using namespace ni::unit_symbols;\nusing namespace mp_units::si::unit_symbols;\n\nconst auto sr1 = ni::GetSampleRate();\nconst auto sr2 = 48'000.f * Smpl / s;\n\nconst auto samples = 512 * Smpl;\n\nconst auto sampleTime1 = (samples / sr1).in(s);\nconst auto sampleTime2 = (samples / sr2).in(ms);\n\nconst auto sampleDuration1 = (1 / sr1).in(ms);\nconst auto sampleDuration2 = (1 / sr2).in(ms);\n\nconst auto rampTime = 35.f * ms;\nconst auto rampSamples1 = (rampTime * sr1).force_in<int>(Smpl);\nconst auto rampSamples2 = (rampTime * sr2).force_in<int>(Smpl);\n\nstd::println(\"Sample rate 1 is: {}\", sr1);\nstd::println(\"Sample rate 2 is: {}\", sr2);\n\nstd::println(\"{} @ {} is {::N[.5f]}\", samples, sr1, sampleTime1);\nstd::println(\"{} @ {} is {::N[.5f]}\", samples, sr2, sampleTime2);\n\nstd::println(\"One sample @ {} is {::N[.5f]}\", sr1, sampleDuration1);\nstd::println(\"One sample @ {} is {::N[.5f]}\", sr2, sampleDuration2);\n\nstd::println(\"{} is {} @ {}\", rampTime, rampSamples1, sr1);\nstd::println(\"{} is {} @ {}\", rampTime, rampSamples2, sr2);\n
     
    The above prints:
     
    Sample rate 1 is: 44100 Hz\nSample rate 2 is: 48000 Smpl/s\n512 Smpl @ 44100 Hz is 0.01161 s\n512 Smpl @ 48000 Smpl/s is 10.66667 ms\nOne sample @ 44100 Hz is 0.02268 ms\nOne sample @ 48000 Smpl/s is 0.02083 ms\n35 ms is 1543 Smpl @ 44100 Hz\n35 ms is 1680 Smpl @ 48000 Smpl/s\n
     
    We can also do a bit more advanced computations to get the following:
     
    auto sampleValue = -0.4f * pcm;\nauto power1 = sampleValue * sampleValue;\nauto power2 = -0.2 * pow<2>(pcm);\n\nauto tempo = ni::GetTempo();\nauto reverbBeats = 1 * n_qd;\nauto reverbTime = reverbBeats / tempo;\n\nauto pulsePerQuarter = value_cast<float>(ni::GetPPQN());\nauto transportPosition = ni::GetTransportPos();\nauto transportBeats = (transportPosition / pulsePerQuarter).in(n_q);\nauto transportTime = (transportBeats / tempo).in(s);\n\nstd::println(\"SampleValue is: {}\", sampleValue);\nstd::println(\"Power 1 is: {}\", power1);\nstd::println(\"Power 2 is: {}\", power2);\n\nstd::println(\"Tempo is: {}\", tempo);\nstd::println(\"Reverb Beats is: {}\", reverbBeats);\nstd::println(\"Reverb Time is: {}\", reverbTime.in(s));\nstd::println(\"Pulse Per Quarter is: {}\", pulsePerQuarter);\nstd::println(\"Transport Position is: {}\", transportPosition);\nstd::println(\"Transport Beats is: {}\", transportBeats);\nstd::println(\"Transport Time is: {}\", transportTime);\n
     
    which prints:
     
    SampleValue is: -0.4 PCM\nPower 1 is: 0.16000001 PCM\u00b2\nPower 2 is: -0.2 PCM\u00b2\nTempo is: 110 bpm\nReverb Beats is: 1 q.\nReverb Time is: 0.8181818 s\nPulse Per Quarter is: 960 ppqn\nTransport Position is: 15836 p\nTransport Beats is: 16.495832 q\nTransport Time is: 8.997726 s\n
     
    Info
     
    More about this example can be found in \"Exploration of Strongly-typed Units in C++: A Case Study from Digital Audio\" CppCon 2023 talk by Roth Michaels.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will discuss the challenges and issues related to the modeling of the ISQ with a programming language.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/","title":"International System of Quantities (ISQ): Part 6 - Challenges","text":"
    This article might be the last one from our series. This time, we will discuss the challenges and issues with modeling of the ISQ in software.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#ambiguity","title":"Ambiguity","text":"
    Some quantity names are ambiguous. It is not a problem of ISQ but of the English language and the way we communicate things. When I say: \"Every width is a length, but not every length is a width\" most people understand this right away. However, the same people trying to model our 3D box problem try to do it as follows:
     
    class Box {\n  quantity<isq::length[m]> length_;\n  quantity<isq::width[m]> width_;\n  quantity<isq::height[m]> height_;\npublic:\n  // ...\n};\n
     
    This looks correct at first sight. Only when we think about the sentence mentioned above will we realize that this implementation has a problem. We intended to specify three orthogonal dimensions of the box, each of which will be a strong quantity that is not convertible to others. But we've failed.
     
    When we look at the tree of quantities of length we immediately see that both width and height are special lengths so they are convertible to it.
     
    To implement our task correctly, we had to define and use a new quantity of kind length:
     
    inline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n
     
    We do not propose adding horizontal length to ISO 80000-3. There are probably other similar cases as well, but so far, this was the most common and obvious one we've encountered.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#no-common-quantities","title":"No common quantities","text":"
    ISO 80000-1:2009 explicitly states:
     
    Quote
     
    Two or more quantities cannot be added or subtracted unless they belong to the same category of mutually comparable quantities.
     
    This means that we should be able to add and subtract any quantities as long as they belong to the same kind. However, ISO/IEC documents do not provide any rules or even hints about what should be the result of such operations.
     
    If it is possible to add radius and distance, then what quantity should be provided in return? Undoubtedly, the resulting quantity type can't be the same as any of the arguments. It is not a radius or distance. It is some closer unspecified length, though.
     
    Info
     
    Finding the correct solution took us many months of experimentation and implementation. Based on the hierarchy tree of quantities, we can define conversion rules and what a common quantity should be.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-consistency","title":"Lack of consistency","text":"
    The documents of ISO/IEC 80000 are not 100% consistent, and programming languages do not like inconsistencies.
     
    For example:
     
       
    • time is mentioned as a base quantity of ISQ in ISO 80000-1 chapter 4.5.
      •  
    •  
      ISO 80000-3 \"Space and time\", does not define a quantity of time. It provides a duration   quantity (item 3-9) with symbol t, and states in the Remarks section:
       
      Quote
       
      Duration is often just called time.
       
      •  
    •  
      Other parts (e.g., IEC 80000-6 \"Electromagnetism\") often say:
       
      Quote
       
      ... t is time (ISO 80000-3)
       
      •  
     
    To be consistent, ISO/IEC should either:
     
       
    • change ISO 80000-1 chapter 4.5 and all references in other parts to use duration (unlikely),
      •  
    • or add time as an alias name to duration in the definition 3-9 of ISO 80000-3.
      •  
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-definitions","title":"Lack of definitions","text":"
    ISQ defines derived quantities in terms of other quantities provided in the series. However, some definitions mention quantities that are not defined in the ISQ at all.
     
    For example, weight is defined as \\(F_\\textsf{g} = m\\;g\\), where \\(m\\) is the mass of the body (item 4-1 of ISO 80000-4 \"Mechanics\"), and \\(g\\) is the local acceleration of free fall (ISO 80000-3).
     
    The problem here is that ISO 80000-3 never defines a quantity with a symbol \\(g\\) or named as a local acceleration of free fall. The closest one we have is acceleration (item 3-11) with a symbol \\(a\\).
     
    Info
     
    To have a proper definition of weight in mp-units that is not defined in terms of just any kind of acceleration, we have added isq::acceleration_of_free_fall in our definitions as an extension to the original ISQ set of quantities.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#not-engineering-friendly","title":"Not engineering-friendly","text":"
    Many quantities have proper physical definitions, but they are sometimes not engineering-friendly.
     
    For example, velocity is defined as a rate of change of position vector \\(v = \\frac{\\textsf{d}r}{\\textsf{d}t}\\), where \\(r\\) denotes the position vector (item 3\u20111.10) and \\(t\\) the duration (item 3\u20119).
     
    Next, a speed quantity is defined as the magnitude of velocity. Despite being physically correct, requiring every speed to be derived from the vector quantity of velocity in software would be inconvenient. If this was the only case, people would always need to use vector representations of position vectors to talk about speeds, which differs from what we do in practice. In practice, we divide any kind of length by time to get some kind of speed.
     
    ISO 80000-3 provides length, height, distance and other quantities of kind length that when divided by duration can serve really well to calculate speed.
     
    Info
     
    This is why in mp-units, we decided to divert from the official definition of speed and define it as:
     
    inline constexpr struct speed : quantity_spec<speed, length / time> {} speed;\n
     
    This allows us to create a quantity of kind speed from any quantity of length divided by time.
     
    Additionally, it is essential to note that for the needs of our library, defining velocity as position_vector / duration would be wrong. We miss the delta part here. Even though it is not mentioned in ISO 80000-3, the delta of position vectors is actually a displacement. This is why our velocity is defined as:
     
    inline constexpr struct velocity : quantity_spec<speed, displacement / duration> {} velocity;\n
     
    Please also note that velocity is defined as a more specialized quantity of speed.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#affine-space-agnostic","title":"Affine space agnostic","text":"
    The affine space is a powerful abstraction, allowing us to model some problems safer or more accurately. It has two types of entities:
     
       
    • point - a position specified with coordinate values (e.g., location, address, etc.),
      •  
    • displacement vector - the difference between two points (e.g., shift, offset, displacement,   duration, etc.).
      •  
     
    Vectors support all the arithmetics operations, but points have some limitations. It is not possible to:
     
       
    • add two points,
      •  
    • subtract a point from a vector,
      •  
    • multiply nor divide points with anything else.
      •  
     
    ISO/IEC series does not acknowledge this abstraction even though it would be really useful in some cases. Let's discuss the following two examples.
     
    What does it mean to add two altitudes? It is not meaningful. On the other hand, subtracting those should not result in an altitude, but in a quantity of height. Adding or subtracting height to/from altitude results in altitude. Subtracting altitude from height is meaningless again. Those quantities clearly model affine space. Maybe this is why ISQ defines them as one quantity type height/depth/altitude?
     
    What does it mean to add two position vectors? It is not meaningful again. However, subtracting those results in a displacement as we noted in the previous chapter. Adding or subtracting displacement to/from position vector results in another position vector, and subtracting position vector from displacement does not have physical sense. Again, those quantities perfectly model affine space. However, this time, those are defined as separate and independent quantities (i.e., displacement is not modeled as delta position vector or position vector is not modeled as a displacement from the origin of a coordinate system).
     
    Info
     
    Currently, mp-units does not enforce the affine space behavior for such quantities. Today, subtracting two altitudes result in an altitude and subtracting two position vectors result in a position vector. However, we plan to support automatic conversion to a proper quantity type on subtraction and addition shortly.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#non-negative-quantities","title":"Non-negative quantities","text":"
    Some quantities in the ISQ are defined as non-negative. This is a really interesting property that may be checked at runtime to increase safety. However, the number of such quantities is minimal. From a few hundred quantities provided by the ISO/IEC series, only the following have this property mentioned explicitly:
     
       
    • width/breadth,
      •  
    • thickness,
      •  
    • diameter,
      •  
    • radius.
      •  
     
    If height was defined separately from altitude, it could probably also join this group.
     
    Let's think a bit more about this. What does it mean that a quantity is non-negative? Indeed, it is hard to imagine something of a negative width or radius. However, if we subtract two widths, the second one may be larger. This will result in a negative quantity of width, violating our precondition. So, is it non-negative or not?
     
    Again, we have to talk about the affine space abstractions. Every empirical measurement can be expressed as a point. Such points for some quantities may be non-negative indeed.
     
    Non-negative quantities do not end on the ones provided above. For example, speed is a good example here as well. In general, all magnitudes of vector quantities will also have this property.
     
    When subtracting two points, we end up with a delta/displacement type, which may be negative even for quantities listed as non-negative in the ISQ. As stated in the previous chapter, having affine space abstractions acknowledged in ISQ would greatly help here.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-quantity-recipes","title":"Lack of quantity recipes","text":"
    Definition of many derived quantities provides their recipes in the form of quantity equations (e.g., weight equation in the previous chapter). However, some of them do not. Instead, they often provide a very generic description.
     
    For example, force is defined as:
     
    Quote
     
    vector (ISO 80000-2) quantity describing interaction between bodies or particles.
     
    This is not helpful for programming languages that like explicit definitions. Different vendors may interpret the above differently, which will result in different implementations that will not be compatible with each other.
     
    As the derived quantity of force has to be a vector quantity, it has to be defined in terms of at least one other vector quantity. We have a few to choose from:
     
       
    • displacement (\\(\\Delta{r}\\)),
      •  
    • velocity (\\(v\\)),
      •  
    • acceleration (\\(a\\)).
      •  
     
    It is not stated explicitly in ISQ which one of those should be used and how.
     
    Info
     
    In mp-units we decided to define force as \\(F = m\\;a\\).
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-generic-quantities-and-name-conflicts","title":"Lack of generic quantities and name conflicts","text":"
    In the previous chapter, we complained about some definitions needing to be more complex or generic. On the other hand, we also lack some generic quantities in ISQ that could serve as a root for a quantity hierarchy tree.
     
    For example:
     
       
    • ISO 80000-4 \"Mechanics\" defines power <mechanics> as \\(P = F\\;v\\) (scalar product of force \\(F\\)   (item 4-9.1) acting to a body and its velocity \\(v\\) (ISO 80000-3)),
      •  
    • ISO 80000-6 \"Electromagnetism\" defines power as \\(p = u\\;i\\) (scalar quantity given by the   product of instantaneous voltage \\(u\\) (item 6-11.3) and instantaneous electric current \\(i\\)   (item 6-1)).
      •  
     
    First, the above definitions have somehow conflicting names which makes it hard for the programming languages to name them consistently by different vendors.
     
    Info
     
    In mp-units, we chose mechanical_power and electromagnetism_power for those.
     
    Second, we do not have any other more generic definition of power to put above those in the tree. Not having it makes it hard to answer what should be the result of:
     
    quantity q = isq::mechanical_power(42 * W) + isq::electromagnetism_power(60 * W);\n
     
    Info
     
    To solve the above problem, we have added isq::power in mp-units, that has a really generic definition of:
     
    inline constexpr struct power : quantity_spec<mass* pow<2>(length) / pow<3>(time)> {} power;\n
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#invalid-definitions-order","title":"Invalid definitions order","text":"
    Energy is defined a bit better than power, but still not without issues.
     
    The first time ISQ mentions energy is in the ISO 80000-4 \"Mechanics\". It defines potential energy, kinetic energy, and a mechanical energy as the sum of the first two. Right after that a mechanical work/work is defined.
     
    Then ISO 80000-5 \"Thermodynamics\" defines energy <thermodynamics> as:
     
    Quote
     
    ability of a system to do work (ISO 80000-4).
     
    Next, internal energy/thermodynamic energy is defined in terms of the change of heat.
     
    From the above, it seems that what is called energy <thermodynamics> should actually be the root of our tree and probably be provided in Part 4 before the mechanical energy is defined.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#hierarchies-of-derived-quantities","title":"Hierarchies of derived quantities","text":"
    Derived quantities of the same kind are often independently defined in the ISQ. The ISO/IEC 80000 series often does not suggest any hierarchy between those. Even more, it states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    Because of this, it is unknown or ambiguous how to form a hierarchy tree for such quantities.
     
    To get some sense of the complexity here, let's look again at our tree of quantities of a kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    Not being exact means that every vendor may implement it differently. This will result in:
     
       
    •  
      different convertibility rules among quantities:
       
      static_assert(implicitly_convertible(isq::potential_energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mechanical_energy, isq::potential_energy));\n
       
      •  
    •  
      different common quantities resulting from the arithmetics on various quantities of the same   kind:
       
      static_assert((isq::potential_energy(1 * J) + isq::kinetic_energy(1 * J)).quantity_spec == isq::mechanical_energy);\n
       
      •  
     
    It would be great if ISQ could provide specific division of quantities into kinds and more information about the position of each quantity within the hierarchy of quantities of the same kind.
     
    Important
     
    We can try to do this by ourselves, but it is tough. Probably no one, for sure we are not, is an expert in all the fields of ISO/IEC 80000 applicability.
     
    We need the help of subject matter experts who will help us build those trees for their domains and then verify that everything works as expected.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#the-same-or-a-different-kind","title":"The same or a different kind?","text":"
    Some quantities are more complicated than others. For example, power has:
     
       
    • real scalar quantities expressed in:
         
      • W (watts) (e.g., mechanical power, active power),
        •  
      • VA (volt-ampere) (e.g., apparent power),
        •  
      • var (e.g., reactive power),
        •  
       
      •  
    • complex scalar quantities expressed in VA (volt-ampere) (e.g., complex power).
      •  
     
    How should we model this? Maybe those should be two or three independent trees of quantities, each having its own unit?
     
    flowchart TD\n    power[\"<b>power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[W]\"]\n    power --- mechanical_power[\"<b>mechanical_power</b><br><i>(scalar_product(force, velocity))</i>\"]\n    power --- electromagnetism_power[\"<b>electromagnetism_power</b> | <b>instantaneous_power</b><br><i>(instantaneous_voltage * instantaneous_electric_current)</i>\"]\n    power --- active_power[\"<b>active_power</b><br><i>(1 / period * instantaneous_power * time)<br>(re(complex_power))</i>\"]\n\n    nonactive_power[\"<b>nonactive_power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[VA]\"]\n    nonactive_power --- reactive_power[\"<b>reactive_power</b><br><i>(im(complex_power))</i><br>[var]\"]\n\n    complex_power[\"<b>complex_power</b><br>{complex}<br><i>(voltage_phasor * electric_current_phasor)<br>(active_power + j * reactive_power)</i><br>[VA]\"]\n    complex_power --- apparent_power[\"<b>apparent_power</b><br><i>(voltage * electric_current)<br>(mod(complex_power))</i>\"]
     
    This will mean that we will not be able to add or compare active power, reactive power, and apparent power, which probably makes a lot of sense. However, it also means that the following will fail to compile:
     
    quantity apparent = isq::apparent_power(100 * VA);\nquantity active = isq::active_power(60 * W);\nquantity<isq::nonactive_power[VA]> q = sqrt(pow<2>(apparent) - pow<2>(active)); // Compile-time error\n
     
    Also the following will not work:
     
    quantity active = isq::active_power(60 * W);\nquantity reactive = isq::reactive_power(40 * var);\nquantity<isq::apparent_power[VA]> q = sqrt(pow<2>(active) + pow<2>(reactive)); // Compile-time error\n
     
    If we want the above to work maybe we need to implement the tree as follows?
     
    flowchart TD\n    power[\"<b>power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[W]\"]\n    power --- mechanical_power[\"<b>mechanical_power</b><br><i>(scalar_product(force, velocity))</i>\"]\n    power --- electromagnetism_power[\"<b>electromagnetism_power</b> | <b>instantaneous_power</b><br><i>(instantaneous_voltage * instantaneous_electric_current)</i>\"]\n    power --- apparent_power[\"<b>apparent_power</b><br><i>(voltage * electric_current)<br>(mod(complex_power))</i><br>[VA]\"]\n    apparent_power --- active_power[\"<b>active_power</b><br><i>(1 / period * instantaneous_power * time)<br>(re(complex_power))</i>\"]\n    apparent_power --- nonactive_power[\"<b>nonactive_power</b><br><i>(sqrt(apparent_power<sup>2</sup> - active_power<sup>2</sup>))</i><br>\"]\n    nonactive_power --- reactive_power[\"<b>reactive_power</b><br><i>(im(complex_power))</i><br>[var]\"]\n    apparent_power --- complex_power[\"<b>complex_power</b><br>{complex}<br><i>(voltage_phasor * electric_current_phasor)<br>(active_power + j * reactive_power)</i>\"]
     
    However, the above allows direct addition and comparison of active power and nonactive power, and also will not complain if someone will try to use watt (W) as a unit of apparent power or reactive power.
     
    Again, ISQ does not provide a direct answer here.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#more-base-quantities","title":"More base quantities?","text":"
    Is ISQ really based on only seven base quantities? Let's look at the definition of traffic intensity in IEC 80000-13 \"Information science and technology\":
     
    Quote
     
    number of simultaneously busy resources in a particular pool of resources.
     
    It looks like a definition of a specialized dimensionless quantity or, more correctly, a quantity of dimension one. This would not be the only such case. Even in the same Part 13, we can find quantities like storage capacity with a similar property.
     
    Only when we look closer do we start to see differences. All dimensionless quantities, even if they have their own dedicated units, can also be measured in a unit of one (1). This is true for storage capacity (also measured in bits), angular measure (also measured in radians), _solid angular measure (also measured in steradians), and more.
     
    However, traffic intensity can only be measured in erlangs (E), not in a unit one (1). Does it mean that it is a \"hidden\" 8-th base quantity in ISQ? If so, should it have its own dimension as well?
     
    Angular quantities are another interesting case here. Scientists have written petitions and papers for years to make them an additional dimension in ISQ and SI. More about this can be found in our documentation's Strong Angular System chapter.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#summary","title":"Summary","text":"
    ISQ is tremendous and solves many problems we had in modeling various subjects for years in software. As a result, we have more powerful tools in our hands that allow us to deliver safer products.
     
    Unfortunately, ISQ, contrarily to SI, is not widely recognized, and no libraries besides mp-units model it in any programming language. Keeping it behind a paywall does not help either. We hope that posts from this series will spread in the community, raise awareness of ISQ and its benefits, and encourage authors of other libraries to implement it in their products.
     
    Despite all the benefits, it is essential to realize that ISQ has many problems. International standards should be specified in such a way that there is no room for ambiguity in their interpretation by different parties trying to use them. As described above, this is not the case here.
     
    ISQ is not ready to be unambiguously modeled in software by various vendors. Here are the most important problems to solve to allow this:
     
       
    1. ISQ needs to define basic operations on quantities:
      2.  
     
    - what the result of addition and subtraction should be when arguments differ, \u00a0 \u00a0 - convertibility rules.
     
       
    1. The exact quantity equation recipe needs to be included for many derived quantities.
      2.  
    2. Many ISQ quantities do not provide their exact relation versus other quantities of the same    kind (no strict hierarchy).
      3.  
    3. Some missing quantities need to be included. Others would benefit from corrected names.
      4.  
     
    Additionally:
     
       
    • extending ISQ with affine space abstractions,
      •  
    • specifying more quantities as non-negative,
      •  
    • adding more base quantities (i.e., angle)
      •  
     
    could improve the safety of our programs and products that people depend on with their lives on a daily basis.
     
    I hope you enjoyed following this series and learned more about the International System of Quantities. Please try it out in your domain and share feedback with us. We always love to hear about the projects in which our library is being used and about use cases it helps address.
    "},{"location":"blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/","title":"Report from the Kona 2023 ISO C++ Committee meeting","text":"
    Several groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the mp-units library.
     
    In the following years, we scoped on getting more feedback from the production and design. This resulted in version 2 of the mp-units library that resolved many issues the users and Committee members raised. The features and interfaces of this version are close to being the best we can get with the current version of the C++ language standard.
     
    We submitted three new proposals related to the standardization of the quantities and units library for the last ISO C++ Committee meeting:
     
       
    • P2980: A motivation, scope, and plan for a physical quantities and units library,
      •  
    • P2981: Improving our safety with a physical quantities and units library,
      •  
    • P2982: std::quantity as a numeric type.
      •  
     
    Those were reviewed and briefly discussed in several groups: Numerics (SG6), Safety & Security (SG23), and Library Evolution Working Group (LEWG). Most of the feedback was positive, and the Committee is interested in spending more time on such proposals.
     
    The following poll was taken by the LEWG:
     
    LEWG POLL: Given that our time is limited, more time should be promised for a quantities and units library
     Strongly in Favor In favor Neutral Against Strongly Against 10 13 4 0 0 
    Attendance: 22 + 6
     
    Number of Authors: 4
     
    Authors\u2019 position: 4x SF
     
    Outcome: Strong consensus in favor
     
    Additionally, some concerns were raised about the large scope of the proposal. We were encouraged to return with more details and design rationale in a unified paper. This is what we are working on now for the next Committee meeting that will happen in mid-March 2024 in Tokyo.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/","title":"Report from the St. Louis 2024 ISO C++ Committee meeting","text":"
    We made significant progress in the standardization of this library during the ISO C++ Committee meeting in St. Louis.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p30942r3-stdbasic_fixed_string","title":"P30942R3: std::basic_fixed_string","text":"
    First, the fixed_string was unanimously forwarded from the SG18 LEWG Incubator to the Library Evolution Working Group (LEWG). The group suggested a few minor changes to the paper, which resulted in the R3 version of the proposal.
     
    The paper is in excellent shape, and the entire wording is ready as well. Hopefully it will progress quickly through the remaining groups in the Committee.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p3045r1-quantities-and-units-library","title":"P3045R1: Quantities and units library","text":"
    In the SG6 (Numerics), we had a really efficient discussion about the recently raised usability issues with temperatures and the Minimal Viable Product (MVP) scope.
     
    The following polls were taken:
     
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, and quantity kinds. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 7 4 7 0 0 
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and quantities of the same kind. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 5 2 5 2 0 
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and affine spaces. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 5 0 8 1 0 
    As we can see, there are no controversies about the first poll that states that the MVP should include at least:
     
       
    • units,
      •  
    • dimensions,
      •  
    • quantity kinds (e.g., frequency vs activity, plane angle vs solid angle,  fuel_consumption vs area).
      •  
     
    The next polls add either:
     
       
    • quantities of the same kind (e.g., length vs width vs wavelength, potential energy vs kinetic energy),
      •  
    • the affine space abstractions (i.e., point origins and quantity_point).
      •  
     
    SG6 considered those less important, but no one was strongly against including those in the MVP. We were asked to return with better motivation and usage examples for those features.
     
    If you are depending on quantities of the same kind or quantity points in your project and you would like to see them in the std library, please let us know about your use cases.
     
    Besides SG6, we spent six hours in the SG18 LEWG Incubator discussing the details of the library design. The proposal was very well received, and we got a few valuable comments and suggestions that we will apply to the next version of the paper.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/","title":"Report from the Tokyo 2024 ISO C++ Committee meeting","text":"
    The Tokyo 2024 meeting was a very important step in the standardization of this library. Several WG21 groups reviewed proposals, and the feedback was really good.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p3045r0-quantities-and-units-library","title":"P3045R0: Quantities and units library","text":"
    The Study Group 6 (Numerics) discussed the proposal for several hours. The initial feedback was positive. There were some concerns related to the description and design of the affine space abstractions in the library. Besides that, the people in the room liked what they saw.
     
    We run a few polls in SG6 as well:
     
    POLL: The syntax number * unit is the right solution for constructing quantities. Not allowing reordering the operands is correct.
     Strongly in Favor In favor Neutral Against Strongly Against 5 4 1 0 1 
    POLL: Not defining any UDLs is the right solution.
     
    No objection to unanimous consent.
     
    The paper was also briefly discussed in SG18 LEWG Incubator, and the initial feedback was also positive. No polls were taken.
     
    SG16 Unicode does not meet during ISO C++ Committee F2F meetings. Still, the text output chapter paper was also reviewed by it during an online meeting before Tokyo. We got good feedback and are expected to return with the updated version. No polls were taken.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p30942r1-stdbasic_fixed_string","title":"P30942R1: std::basic_fixed_string","text":"
    In the SG18 LEWG Incubator, before we started to talk about P3045R0, we spent a few hours discussing the design of the std::basic_fixed_string, which is proposed for C++26. The group gave excellent feedback, and if the R2 version addresses it properly, the paper is expected to progress to LEWG (Library Evolution Working Group) in St. Louis.
     
    Plenty of polls were taken:
     
    POLL: We should promise more committee time to pursuing std::basic_fixed_string, knowing that our time is scarce and this will leave less time for other work.
     Strongly in Favor In favor Neutral Against Strongly Against 11 0 0 0 0 
    POLL: Should the constructor from a string literal be consteval?
     Strongly in Favor In favor Neutral Against Strongly Against 6 3 2 0 0 
    POLL: Do we want to add .view()?
     Strongly in Favor In favor Neutral Against Strongly Against 3 5 3 0 0 
    POLL: Do we want the .size member to be an integral_constant<size_t, N> (and .empty to be bool_constant<N==0>)?
     Strongly in Favor In favor Neutral Against Strongly Against 5 2 2 2 0 
    POLL: Should the index operator[] return a reference to const?
     Strongly in Favor In favor Neutral Against Strongly Against 2 2 3 3 0 
    POLL: Should the constructor from a string literal have a precondition that txt[N] == 0?
     Strongly in Favor In favor Neutral Against Strongly Against 6 1 2 0 2"},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/","title":"Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting","text":"
    The Wroc\u0142aw 2024 meeting was another efficient step in the standardization of this library. We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback. We've also introduced std::fixed_string to LEWG for C++26.
    "},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/#p3045r4-quantities-and-units-library","title":"P3045R4: Quantities and units library","text":"
    We have presented the following chapters of our proposal to LEWGI and SG6. We reviewed all the usage examples, discussed composing symbols for derived dimensions and units, and looked into formatting specifications for quantities. We also discussed the minimal scope of the proposal.
     
    We got plenty of feedback on:
     
       
    • the paper itself,
      •  
    • naming of specific entities in the library,
      •  
    • usage examples,
      •  
    • text output and formatting.
      •  
     
    We were also asked to extend the library to provide text output support for quantity points.
     
    You can expect all of those changes to appear in the next release.
    "},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/#p30942r5-stdbasic_fixed_string","title":"P30942R5: std::basic_fixed_string","text":"
    The paper was well received. However, Barry Revzin submitted P3380 paper in September. This started a discussion about the scope of this proposal. Should we:
     
       
    • limit it to just a non-mutating interface (as proposed) and maybe rename it to \u00a0 std::string_literal,
      •  
    • add range slicing interface (as we support composition already),
      •  
    • add some basic mutation interface through non-const operator[],
      •  
    • refactor to fully blown std::inplace_string if P3380 successfully  progresses through EWG.
      •  
    "},{"location":"getting_started/contributing/","title":"Contributing","text":"
    \ud83d\udc4d\ud83c\udf89 First off, thanks for taking the time to contribute! \ud83c\udf89\ud83d\udc4d
    "},{"location":"getting_started/contributing/#mp-units-documentation","title":"mp-units documentation","text":"
    Before contributing, it is highly recommended to familiarize yourself with our official documentation.
     
    This file is also a part of it, and this is why it has non-standard Markdown formatting (which can be seen when reading in a regular Markdown renderer). To benefit from full mkdocs rendering, please switch to the Contributing chapter of our documentation.
    "},{"location":"getting_started/contributing/#where-to-start","title":"Where to start?","text":"
    If you are looking for a good issue to start with, please check the following:
     
       
    • good first issue - issues that   should be pretty simple to implement,
      •  
    • help wanted - issues that typically are   a bit more involved than beginner issues,
      •  
    • high priority - things to fix ASAP   but often of higher complexity.
      •  
    "},{"location":"getting_started/contributing/#gitpod","title":"Gitpod","text":"
    The easiest way to start coding is to jump straight into Gitpod environment. You can either click the button below
     
     
    or prefix any mp-units URL (main branch, other branches, issues, PRs, ...) in your web browser with gitpod.io/# (e.g., https://gitpod.io/#https://github.com/mpusz/mp-units).
     
    The above environment provides you with:
     
       
    • all supported compilers for Linux development and the latest version of build tools like cmake   and conan,
      •  
    • all Conan dependencies preinstalled on the machine,
      •  
    • all documentation generation tools ready to use,
      •  
    • completed prebuilds for all targets (Debug and Release builds for each compiler),
      •  
    • VSCode preconfigured to benefit from all the above.
      •  
    "},{"location":"getting_started/contributing/#building-testing-and-packaging","title":"Building, testing, and packaging","text":"
    Alternatively, please refer to our official docs for download, build, and install instructions with the below changes if you want to set up a development environment on your local machine.
    "},{"location":"getting_started/contributing/#conan-configuration-properties","title":"Conan configuration properties","text":"user.mp-units.build:all 
    Enables compilation of all the source code, including tests and examples. To support this, it requires some additional Conan build dependencies described in Repository directory tree and dependencies. It also runs unit tests during the Conan build (unless tools.build:skip_test configuration property is set to True).
     user.mp-units.build:skip_la 
    If user.mp-units.build:all is enabled, among others, Conan installs the external wg21-linear_algebra dependency and enables the compilation of linear algebra-based tests and usage examples. Such behavior can be disabled with this option.
     user.mp-units.analyze:clang-tidy 
    Enables clang-tidy analysis.
    "},{"location":"getting_started/contributing/#cmake-options-for-mp-units-project-developers","title":"CMake options for mp-units project developers","text":"MP_UNITS_DEV_BUILD_LA 
     2.2.0 \u00b7  ON/OFF (Default: ON)
     
    Enables building code depending on the linear algebra library.
     MP_UNITS_DEV_IWYU 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Enables include-what-you-use analysis.
     MP_UNITS_DEV_CLANG_TIDY 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Enables clang-tidy analysis.
     MP_UNITS_DEV_TIME_TRACE 
     2.5.0 \u00b7  NONE/ALL/MODULES/HEADERS (Default: NONE)
     
    Enables compilation performance data collection with -ftime-trace for clang compilers.
     
    All our unit tests compile only for headers and never for modules. To allow fair comparison, MODULES and HEADERS do not enable the data collection for unit tests. This means that they affect only the core, systems, and examples.
     
    Please use ALL to profile unit tests as well.
    "},{"location":"getting_started/contributing/#building-the-entire-repository","title":"Building the entire repository","text":"
    To build all the mp-units source code (with unit tests and examples), you should:
     
       
    1. Use the CMakeLists.txt from the top-level directory.
      2.  
    2. Run Conan with user.mp-units.build:all = True.
      3.  
     
    git clone https://github.com/mpusz/mp-units.git && cd mp-units\nconan build . -pr <your_conan_profile> -s compiler.cppstd=23 -c user.mp-units.build:all=True -b missing\n
     
    The above will download and install all of the dependencies needed for the development of the library, build all of the source code, and run unit tests.
     
    If you prefer to build the project via CMake rather than Conan, then you should replace the conan build with conan install command and then follow with a regular CMake build and testing:
     
    conan install . -pr <your_conan_profile> -s compiler.cppstd=23 -c user.mp-units.build:all=True -b missing\ncmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target all_verify_interface_header_sets\ncmake --build --preset conan-release --target test\n
     
    Hint
     
    To ensure that we always build all the targets and to save some typing of the Conan commands, we can set the following in the ~/.conan2/global.conf:
     
    user.mp-units.build:all=True\n
    "},{"location":"getting_started/contributing/#packaging","title":"Packaging","text":"
    To test CMake installation and Conan packaging run:
     
    conan create . --user <username> --channel <channel> -pr <your_conan_profile> -s compiler.cppstd=23 \\\n               -c user.mp-units.build:all=True -b missing\n
     
    The above will create a Conan package and run tests provided in ./test_package directory.
     
    In case you would like to upload mp-units package to the Conan server, do the following:
     
    conan upload -r <remote-name> --all mp-units/2.2.0@<user>/<channel>\n
    "},{"location":"getting_started/contributing/#building-documentation","title":"Building documentation","text":"
    We are building our documentation using Material for MkDocs. The easiest way to install all the required dependencies is with pip:
     
    pip install -U mkdocs-material mkdocs-rss-plugin\n
     
    Additionally, a Cairo Graphics library is required by Material for MkDocs. Please follow the official MkDocs documentation to install it.
     
    After that, you can either:
     
       
    •  
      easily start a live server to preview the documentation as you write
       
      mkdocs serve\n
       
      •  
    •  
      build the documentation
       
      mkdocs build\n
       
      •  
    "},{"location":"getting_started/contributing/#generating-api-reference","title":"Generating API reference","text":"
    We need to take a few steps to set up our environment so that we are ready to generate API reference documents.
     
    First, we need to satisfy the requirements described in https://github.com/cplusplus/draft and https://github.com/Eelis/cxxdraft-htmlgen. On the Ubuntu platform, this is equivalent to the following instructions run from the user's home directory:
     
    sudo apt install latexmk texlive-latex-recommended texlive-latex-extra texlive-fonts-recommended lmodern\nsudo apt install haskell-stack graphviz nodejs npm ghc cabal-install\nnpm install split mathjax-full mathjax-node-sre mathjax-node-cli\ncabal update\n
     
    On some platforms, installing mathjax-node-cli through npm does update the system's PATH environment variable resulting in tex2html not found errors. In such cases we need to add the .bin folder to the PATH environment variable manually:
     
    echo \"export PATH=\\\"~/node_modules/.bin:\\$PATH\\\"\" >> ~/.bashrc && source ~/.bashrc\n
     
    Next, we need to clone the following git repositories:
     
       
    • https://github.com/JohelEGP/jegp.cmake_modules
      •  
    • standardese_sources_base branch of https://github.com/JohelEGP/draft
      •  
    • standardese_sources_base branch of https://github.com/JohelEGP/cxxdraft-htmlgen
      •  
     
    For example:
     
    git clone https://github.com/JohelEGP/jegp.cmake_modules.git --depth=1\ngit clone https://github.com/JohelEGP/draft.git --branch=standardese_sources_base --depth=1\ngit clone https://github.com/JohelEGP/cxxdraft-htmlgen.git --branch=standardese_sources_base --depth=1\n
     
    Now, we are ready to start building our API reference. First, we need to configure CMake with the following:
     
    cmake -S docs/api_reference/src -B build/docs/api_reference \\\n      -DCMAKE_MODULE_PATH=\"<path to gh:JohelEGP/jegp.cmake_modules>/modules\" \\\n\u00a0 \u00a0 \u00a0 -DJEGP_STANDARDESE_SOURCES_GIT_REPOSITORY=\"<path to gh:JohelEGP/draft>\" \\\n      -DJEGP_CXXDRAFT_HTMLGEN_GIT_REPOSITORY=\"<path to gh:JohelEGP/cxxdraft-htmlgen>\"\n
     
    Then we need to build the docs with CMake:
     
    cmake --build build/docs/api_reference\n
     
    In the end, we need to move the generated documentation to the docs/api_reference/gen subdirectory:
     
    mv build/docs/api_reference/mp-units.html docs/api_reference/gen\n
     
    or just link the entire directory:
     
    ln -sf ../../build/docs/api_reference/mp-units.html docs/api_reference/gen\n
    "},{"location":"getting_started/contributing/#before-committing-git-changes","title":"Before committing git changes","text":"
    There are a few steps recommended to check before committing and pushing your changes to the git repository.
    "},{"location":"getting_started/contributing/#naming-conventions","title":"Naming conventions","text":"
    Here are the main rules for naming things in this repo:
     
       
    • types, functions, variables use standard_case,
      •  
    • template parameters use PascalCase,
      •  
    • C++ concept names, for now, use PascalCase, but we plan to change it  (see GitHub Issue #93 for more details).
      •  
    "},{"location":"getting_started/contributing/#unified-code-formatting","title":"Unified code formatting","text":"
    A formatting standard is enforced with the pre-commit script. Before committing your changes, please do the following:
     
    pip install -U pre-commit\npre-commit run --all-files\n
     
    This will run:
     
       
    • clang-format for code formatting with the .clang-format file provided in the repo,
      •  
    • cmake-format to format the CMake files,
      •  
    • some other checks (e.g., python script checkers, whitespaces, etc.).
      •  
     
    The script will run on all the files in the repo and will apply the changes in place when needed. After the script is done, please make sure to review and stage all those changes for the git commit.
    "},{"location":"getting_started/contributing/#backward-compatibility","title":"Backward compatibility","text":"
    Before submission, please remember to check if the code compiles fine on the supported compilers. The CI will check it anyway, but it is good to check at least some of the configurations before pushing changes. Especially older compilers can be tricky as those do not have full C++20 conformance. The official list of supported compilers can always be found in the C++ compiler support (API/ABI) chapter of our documentation.
    "},{"location":"getting_started/cpp_compiler_support/","title":"C++ compiler support (API/ABI)","text":"
    Info
     
    mp-units library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
     
    Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality. Newer features can be hidden behind some preprocessor macros providing a backward-compatible way to use them.
     
    The table below provides the minimum compiler version required to compile the code using a specific C++ feature:
     C++ Feature C++ version gcc clang apple-clang MSVC Minimum support 20 12+ 16+ && !19 15+ 194+  std::format 20 13+ 17+ 16+ 194+ C++ modules 20 None 17+ None None import std; 23 None 18+ None None Explicit this parameter 23 14+ 18+ None None clang-19 unfixable bug 
    Unfortunately, clang-19 does not build mp-units because of an unfixable bug in the compiler.
     MSVC bugs 
    MSVC still has a poor C++20 conformance. We had to make many workarounds to our codebase to make it compile on this compiler. Usage of such nasty preprocessor macros degrade the readability and maintainability of our code. This is why we've applied those patches to the main library code but not to unit tests and examples. Those still do not compile on MSVC.
     
    Here is a list of the most important MSVC bugs:
     
       
    • Syntax error when using non-type template parameters in templated class member function
      •  
    • Type always preferred over value when using qualified identifiers
      •  
     
    Please upvote them so they get a higher fixing priority at Microsoft.
     
    Important
     
    Enabling/disabling features listed above may influence the API of the library and the ABI of the customers' projects.
    "},{"location":"getting_started/cpp_compiler_support/#stdformat","title":"std::format","text":"
       
    • Provides powerful text formatting capabilities   for C++.
      •  
    • An alternative fmtlib library can be used instead if
         
      • the C++ language feature is not supported,
        •  
      • the customer's project did not switch to std::format yet (even when the compiler   supports it).
        •  
       
      •  
    • To write code with wide compatibility   a dedicated macro may be used.
      •  
    • Tested with __cpp_lib_format feature test macro.
      •  
    • Related build options:
         
      • Conan: std_format
        •  
      • CMake: MP_UNITS_API_STD_FORMAT
        •  
       
      •  
    "},{"location":"getting_started/cpp_compiler_support/#c-modules","title":"C++ modules","text":"
       
    • Provide new way to share declarations and definitions across translation units.
      •  
    • If used, the library will distribute both \"old-style\" headers and module interface units
         
      • associated with the same CMake targets.
        •  
       
      •  
    • Even with full compiler support, a user may still decide to not pay for C++ modules compilation   if they are not needed by the customer's project.
      •  
    • Feature test macro is not used for testing here because even if the compiler does not support   the entire C++ feature (e.g. header units), it is enough to build modules for this library.
      •  
    • Related build options:
         
      • Conan: cxx_modules
        •  
      • CMake: MP_UNITS_BUILD_CXX_MODULES
        •  
       
      •  
     
    Note
     
    More requirements for C++ modules support can be found in the CMake's documentation.
    "},{"location":"getting_started/cpp_compiler_support/#import-std","title":"import std;","text":"
       
    • If enabled, the library will obtain all the definitions from the std namespace via   import std; instead of the \"old-style\" header includes.
      •  
    • Related build options:
         
      • Conan: import_std
        •  
      • CMake: CMAKE_CXX_MODULE_STD
        •  
       
      •  
    "},{"location":"getting_started/cpp_compiler_support/#explicit-this-parameter","title":"Explicit this parameter","text":"
       
    • This feature removes the need for the usage of the CRTP idiom in the   quantity_spec definitions.
      •  
    • To write code with wide compatibility   a dedicated macro may be used.
      •  
    • Tested with __cpp_explicit_this_parameter feature test macro.
      •  
    • Related build options:
         
      • Conan: no_crtp
        •  
      • CMake: MP_UNITS_API_NO_CRTP
        •  
       
      •  
    "},{"location":"getting_started/faq/","title":"Frequently Asked Questions","text":""},{"location":"getting_started/faq/#why-do-we-spell-metre-instead-of-meter","title":"Why do we spell metre instead of meter?","text":"
    This is how the BIPM defines it in the SI Brochure (British English spelling by default).
    "},{"location":"getting_started/faq/#why-dont-we-use-udls-to-create-quantities","title":"Why don't we use UDLs to create quantities?","text":"
    Many reasons make UDLs a poor choice for a physical units library:
     
       
    1. UDLs work only with literals (compile-time known values). Our observation is that besides    the unit tests, there are only a few compile-time known quantity values used in the production    code. Please note that for physical constants, we recommend using    Faster-than-lightspeed Constants.
      2.  
    2.  
      Typical implementations of UDLs tend to always use the widest representation type available.    In the case of std::chrono::duration, the following is true:
       
      using namespace std::chrono_literals;\nauto d1 = 42s;\nauto d2 = 42.s;\nstatic_assert(std::is_same_v<decltype(d1)::rep, std::int64_t>);\nstatic_assert(std::is_same_v<decltype(d2)::rep, long double>);\n
       
      3.  
     
    When such UDL is intermixed in arithmetics with any quantity type of a shorter representation    type, it will always expand it to the longest one. In other words, such long type spreads until    all types use it everywhere.
     
       
    1.  
      While increasing the coverage for the library, we learned that many unit symbols conflict with    built-in types or numeric extensions. A few of those are: F (farad), J (joule), W (watt),    K (kelvin), d (day), l or L (litre), erg, ergps. Usage of the _ prefix would make    it work for mp-units, but in case the library is standardized, those naming collisions would    be a big issue. This is why we came up with the _q_ prefix that would become q_ after    standardization (e.g., 42q_s), which is not that nice anymore.
       
      2.  
    2.  
      UDLs with the same identifiers defined in different namespace can't be disambiguated in the C++    language. If both SI and CGS systems define _q_s UDL for a second unit, then it would not be possible    to specify which one to use in case both namespaces are \"imported\" with using directives.
       
      3.  
    3.  
      Another bad property of UDLs is that they do not compose. A coherent unit of angular momentum would    have a UDL specified as _q_kg_m2_per_s. Now imagine that we want to make every possible user happy.    How many variations of that unit would we predefine for differently scaled versions of all unit    ingredients?
       
      4.  
    4.  
      UDLs are also really expensive to define and specify. Typically, for each unit, we need two    definitions. One for integral and another one for floating-point representation. Before the    V2 framework, the coherent unit of angular momentum was defined as:
       
      constexpr auto operator\"\" _q_kg_m2_per_s(unsigned long long l)\n{\n  gsl_Expects(std::in_range<std::int64_t>(l));\n  return angular_momentum<kilogram_metre_sq_per_second, std::int64_t>(static_cast<std::int64_t>(l));\n}\n\nconstexpr auto operator\"\" _q_kg_m2_per_s(long double l)\n{\n  return angular_momentum<kilogram_metre_sq_per_second, long double>(l);\n}\n
       
      5.  
    "},{"location":"getting_started/faq/#why-cant-i-create-a-quantity-by-passing-a-number-to-a-constructor","title":"Why can't I create a quantity by passing a number to a constructor?","text":"
    A quantity class template in the mp-units library has no publicly available constructor taking a raw value. Such support is provided by the std::chrono::duration and was pointed out to us as a red flag safety issue by a few parties already.
     
    Consider the following structure and a code using it:
     
    struct X {\n  std::vector<std::chrono::milliseconds> vec;\n  // ...\n};\n
     
    X x;\nx.vec.emplace_back(42);\n
     
    Everything works fine for years until, at some point, someone changes the structure to:
     
    struct X {\n  std::vector<std::chrono::microseconds> vec;\n  // ...\n};\n
     
    The code continues to compile just fine, but all the calculations are off now. This is why we decided to not follow this path.
     
    In the mp-units library, both a number and a unit have to always be explicitly provided in order to form a quantity.
     
    Note
     
    The same applies to the construction of quantity_point using an explicit point origin. To prevent similar safety issues during maintenance, the initialization always requires providing both a quantity and a PointOrigin that we use as a reference point.
    "},{"location":"getting_started/faq/#why-a-dimensionless-quantity-is-not-just-a-fundamental-arithmetic-type","title":"Why a dimensionless quantity is not just a fundamental arithmetic type?","text":"
    In the initial design of this library, the resulting type of division of two quantities was their common representation type:
     
    static_assert(std::is_same_v<decltype(10 * km / (5 * km)), int>);\n
     
    First of all, this was consistent with std::chrono::duration behavior. Additional reasoning behind it was not providing a false impression of a strong quantity type for something that looks and feels like a regular number. Also, all of the mathematic and trigonometric functions were working fine out of the box with such representation types, so we did not have to rewrite sin(), cos(), exp(), and others.
     
    However, the feedback we got from the production usage was that such an approach is really bad for generic programming. It is hard to handle the result of the two quantities' division (or multiplication) as it might be either a quantity or a fundamental type. If we want to raise such a result to some power, we must use units::pow or std::pow depending on the resulting type. Those are only a few issues related to such an approach.
     
    Moreover, suppose we divide quantities of the same dimension but with units of significantly different magnitudes. In that case, we may end up with a really small or a huge floating-point value, which may result in losing lots of precision. Returning a dimensionless quantity from such cases allows us to benefit from all the properties of scaled units and is consistent with the rest of the library.
     
    Note
     
    More information on the current design can be found in the Dimensionless Quantities chapter.
    "},{"location":"getting_started/faq/#why-derived-units-order-is-not-preserved-from-the-multiplication","title":"Why derived units order is not preserved from the multiplication?","text":"
    It might be surprising, but the quantities and units multiplication order does not impact the order of components in the derived unit. Let's try the following example:
     
    std::println(\"{}\", 42 * kW * h);\nconstexpr auto kWh = kW * h;\nstd::println(\"{}\", 42 * kWh);\n
     
    The above prints:
     
    42 h kW\n42 h kW\n
     
    Some users could expect to see 42 kWh or 42 kW h in the output. It is not the case and for a very good reason. As stated in Simplifying the resulting symbolic expressions, to be able to reason about and simplify units, the library needs to order them in an appropriate order.
     
    Maybe this default order could be improved a bit, but according to international standards, there is no generic ordering rule. Various quantities use different, often domain-specific, ordering of derived unit components.
     
    Let's see what SI says here:
     Derived quantity Symbol Derived unit expressed in terms of base units electric field strength V m\u207b\u00b9 kg m s\u207b\u00b3 A\u207b\u00b9 electric charge density C m\u207b\u00b3 A s m\u207b\u00b3 exposure (x- and \u03b3-rays) C kg\u207b\u00b9 A s kg\u207b\u00b9 
    However, there is a workaround. A user can define its own named unit for a derived unit and provide the custom symbol text that suits the project's requirements. For example, the above case could be addressed with:
     
    inline constexpr struct kilowatt_hour final : named_unit<\"kWh\", kW * h> {} kilowatt_hour;\ninline constexpr auto kWh = kilowatt_hour;\n
     
    With the above, we can refactor the above code to:
     
    std::println(\"{}\", 42 * kWh);\nstd::println(\"{}\", (42 * kW * h).in(kWh));\n
     
    Both lines will produce an expected \"42 kWh\" unit in the output.
     
    Important
     
    Please note that this makes the entire \"kWh\" a single, indivisible entity that is not subject to simplification rules. This means that 42 * kWh / (2 * h) will result with 21 kWh/h rather than 21 kW. To get the latter, the user needs to explicitly provide a new derived unit:
     
    std::println(\"{}\", (42 * kWh / (2 * h)).in(kW));\n
    "},{"location":"getting_started/faq/#why-do-the-identifiers-for-concepts-in-the-library-use-camelcase","title":"Why do the identifiers for concepts in the library use CamelCase?","text":"
    Initially, C++20 was meant to use CamelCase for all the concept identifiers. All the concepts from the std::ranges library were merged with such names into the standard document draft. Frustratingly, CamelCase concepts got dropped from the C++ standard at the last moment before releasing C++20. Now, we are facing the predictable consequences of running out of names.
     
    As long as some concepts in the library could be easily named with a standard_case there are some that are hard to distinguish from the corresponding type names, such as Quantity, QuantityPoint, QuantitySpec, or Reference. This is why we decided to use CamelCase consistently for all the concept identifiers to make it clear when we are talking about a type or concept identifier.
     
    However, we are aware that this might be a temporary solution. In case the library gets standardized, we can expect the ISO C++ Committee to bikeshed/rename all of the concept identifiers to a standard_case, even if it will result in a harder to understand code.
     
    Note
     
    In case you have a good idea of how to rename existing concepts to the standard_case, please let us know in the associated GitHub Issue.
    "},{"location":"getting_started/faq/#why-utf-8-quantity-symbols-are-used-by-default-instead-of-portable-characters","title":"Why UTF-8 quantity symbols are used by default instead of portable characters?","text":"
    Both C++ and ISO 80000 are standardized by the ISO. ISO 80000 and the SI standards specify UTF-8 symbols as the official unit names for some quantities (e.g. \u03a9 symbol for the resistance quantity). As the mp-units library will be proposed for standardization as a part of the C++ Standard Library we have to obey the rules and be consistent with ISO specifications.
     
    Note
     
    We do understand engineering reality and the constraints of some environments. This is why the library has the option of Portable Quantity Symbols.
    "},{"location":"getting_started/faq/#why-dont-we-have-cmake-options-to-disable-the-building-of-tests-and-examples","title":"Why don't we have CMake options to disable the building of tests and examples?","text":"
    Over time, many people provided PRs proposing adding options to build tests and examples conditionally. Here are a few examples:
     
       
    • Add CMake options for disabling docs, examples and tests
      •  
    • build: add options to disable part of the build
      •  
    • CMake Refactoring and Option Cleanup
      •  
     
    We admit this is a common practice in the industry, but we also believe this is a bad pattern.
     
    First, the only need for such options comes when a user wants to use add_subdirectory() in CMake to handle dependencies. Such an approach does not scale and should be discouraged. There is little use for such a practice in times when we have dedicated package managers like Conan.
     
    The second thing is that our observation is that many people are fixed on disabling \"unneeded\" subdirectories from compilation, but they do not see or address the biggest issue, which is polluting user's build environment with our development-specific settings. Propagating our restrictive compilation flags to user's project is not the best idea as it might cause a lot of harm if this project stops to compile because of that.
     
    Last but not least, not having those options is on purpose. Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
     
    This is why our projects have two entry points:
     
       
    • ./CMakeLists.txt is to be used by projects developers to build ALL the project code with really   restrictive compilation flags,
      •  
    • ./src/CMakeLists.txt contains only a pure library definition and should be used by the customers   that prefer to use CMake's add_subdirectory() to handle the dependencies.
      •  
     
    Note
     
    For more details on this please refer to the CMake + Conan: 3 Years Later - Mateusz Pusz lecture that Mateusz Pusz provided at the C++Now 2021 conference.
    "},{"location":"getting_started/installation_and_usage/","title":"Installation And Usage","text":"
    This chapter provides all the necessary information to obtain mp-units and build the user's source code using it.
    "},{"location":"getting_started/installation_and_usage/#obtaining-dependencies","title":"Obtaining dependencies","text":"
    This library assumes that most of the dependencies will be provided by the Conan Package Manager. If you want to obtain required dependencies by other means, some modifications to the library's CMake files might be needed.
     Conan quick intro 
    In case you are not familiar with Conan, to install it (or upgrade) just do:
     
    pip install -U conan\n
     
    After that, you might need to add a custom profile file for your development environment in ~/.conan2/profiles directory. An example profile can look as follows:
     ~/.conan2/profiles/gcc12
    [settings]\narch=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.cppstd=20\ncompiler.libcxx=libstdc++11\ncompiler.version=14\nos=Linux\n\n[conf]\ntools.build:compiler_executables={\"c\": \"gcc-14\", \"cpp\": \"g++-14\"}\n
     
    Setting the language version
     
    Please note that the mp-units library requires at least C++20 to be set in a Conan profile or forced via the Conan command line. If we do the former, we will not need to provide -s compiler.cppstd=20 every time we run a Conan command line (as provided in the command line instructions below).
     
    Using Ninja as a CMake generator for Conan
     
    It is highly recommended to set Ninja as a CMake generator for Conan. To do so, we could create a ~/.conan2/global.conf file that will set tools.cmake.cmaketoolchain:generator to one of the Ninja generators. For example:
     ~/.conan2/global.conf
    tools.cmake.cmaketoolchain:generator=\"Ninja Multi-Config\"\n
     
    Separate build folders for different configurations
     
    ~/.conan2/global.conf file may also set tools.cmake.cmake_layout:build_folder_vars which makes working with several compilers or build configurations easier. For example, the below line will force Conan to generate separate CMake presets and folders for each compiler and C++ standard version:
     ~/.conan2/global.conf
    tools.cmake.cmake_layout:build_folder_vars=[\"settings.compiler\", \"settings.compiler.version\", \"settings.compiler.cppstd\"]\n
     
    In such a case, we will need to use a configuration-specific preset name in the Conan instructions provided below rather than just conan-default and conan-release (e.g., conan-gcc-13-23 and conan-gcc-13-23-release)
     CMake with presets support 
    It is recommended to use at least CMake 3.23 to build this project to benefit from CMake Presets generated by Conan. All build instructions below assume that you have such support. If not, your CMake invocations have to be replaced with something like:
     
    mkdir build && cd build\ncmake .. -G \"Ninja Multi-Config\" -DCMAKE_TOOLCHAIN_FILE=<path_to_generators_dir>/conan_toolchain.cmake\ncmake --build . --config Release\n
     
    Tip
     
    In case you can't use CMake 3.23 but you have access to CMake 3.20 or later, you can append -c tools.cmake.cmaketoolchain.presets:max_schema_version=2 to the conan install command which will force Conan to use an older version of the CMake Presets schema.
    "},{"location":"getting_started/installation_and_usage/#build-options","title":"Build options","text":"
    Note
     
    Most of the below options are related to the C++ language features available in the compilers. Please refer to the C++ compiler support chapter to learn more about which C++ features are required for each option and which compilers support them.
    "},{"location":"getting_started/installation_and_usage/#conan-options","title":"Conan options","text":"cxx_modules 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Configures CMake to add C++ modules to the list of default targets.
     import_std 
     2.3.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Enables import std; usage.
     std_format 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
     no_crtp 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
     contracts 
     2.2.0 \u00b7  none/gsl-lite/ms-gsl (Default: see below)
     
    Enables checking of preconditions and additional assertions in the code.
     
    If the automatically determined default for import_std is True, then the contracts option is set to none by default. gsl-lite otherwise.
     freestanding 
     2.2.0 \u00b7  True/False (Default: False)
     
    Configures the library in the freestanding mode. When enabled, the library's source code will build with the compiler's -ffreestanding compilation option without any issues.
     CMake options to set when Conan is not being used"},{"location":"getting_started/installation_and_usage/#cmake-options","title":"CMake options","text":"
    Conan will automatically set all the below CMake options based on its configuration (described above). Manual setting of the below CMake options is only needed when Conan is not being used.
     MP_UNITS_BUILD_AS_SYSTEM_HEADERS 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Exports library as system headers.
     MP_UNITS_BUILD_CXX_MODULES 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Adds C++ modules to the list of default targets.
     MP_UNITS_API_STD_FORMAT 
     2.2.0 \u00b7  ON/OFF (Default: automatically determined)
     
    Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
     MP_UNITS_API_NO_CRTP 
     2.2.0 \u00b7  ON/OFF (Default: automatically determined)
     
    Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
     MP_UNITS_API_CONTRACTS 
     2.2.0 \u00b7  NONE/GSL-LITE/MS-GSL (Default: GSL-LITE)
     
    Enables checking of preconditions and additional asserts in the code.
     MP_UNITS_API_FREESTANDING 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
    "},{"location":"getting_started/installation_and_usage/#installation-and-reuse","title":"Installation and reuse","text":"
    There are many different ways of installing/reusing mp-units in your project. Below we mention only a few of many options possible.
     
    Important: Prefer using Conan if possible
     
    The easiest and most recommended way to obtain mp-units is with the Conan package manager. See Conan + CMake (release) for a detailed instruction.
    "},{"location":"getting_started/installation_and_usage/#conan-cmake-release","title":"Conan + CMake (release)","text":"
    Tip
     
    If you are new to the Conan package manager you may want to read Obtaining Dependencies and refer to the Consuming packages chapter of the official Conan documentation for more information.
     
    mp-units releases are hosted on Conan-Center. The following steps may be performed to obtain an official library release:
     
       
    1.  
      Create Conan configuration file (either conanfile.txt or conanfile.py) in your    project's top-level directory and add mp-units as a dependency of your project.    For example, the simplest file may look as follows:
       conanfile.txtconanfile.py 
      [requires]\nmp-units/2.4.0\n\n[options]\n# The below mp-units options are set to defaults by Conan.\n# Uncomment and set to an explicit value to override the defaults.\n#\n# mp-units*:cxx_modules=True\n# mp-units*:import_std=False\n# mp-units*:std_format=True\n# mp-units*:no_crtp=True\n# mp-units*:contracts=gsl-lite\n# mp-units*:freestanding=False\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\n
       
      from conan import ConanFile\nfrom conan.tools.build import can_run\nfrom conan.tools.cmake import CMake, cmake_layout\n\nclass MPUnitsTestConan(ConanFile):\n    settings = \"os\", \"arch\", \"compiler\", \"build_type\"\n    generators = \"CMakeDeps\", \"CMakeToolchain\"\n\n    def requirements(self):\n        self.requires(\n            \"mp-units/2.4.0\",\n            options={\n                # The below mp-units options are set to defaults by Conan.\n                # Uncomment and set to an explicit value to override the defaults.\n                #\n                # \"cxx_modules\": False,\n                # \"import_std\": False,\n                # \"std_format\": True,\n                # \"no_crtp\": True,\n                # \"contracts\": \"gsl-lite\",\n                # \"freestanding\": False,\n            },\n        )\n\n    def layout(self):\n        cmake_layout(self)\n\n    def build(self):\n        cmake = CMake(self)\n        cmake.configure()\n        cmake.build()\n        if can_run(self):\n            cmake.ctest(cli_args=[\"--output-on-failure\"])\n
       
      2.  
    2.  
      Import mp-units and its dependencies definitions with find_package:
       
      find_package(mp-units REQUIRED)\n
       
      3.  
    3.  
      Link your CMake targets with mp-units:
       
      target_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\n
       
      4.  
    4.  
      Download, build, and install Conan dependencies before running the CMake configuration step:
       conanfile.txt or conanfile.pyconanfile.py only 
      conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\ncmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target test\n
       
      conan build . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\n
       
      5.  
    "},{"location":"getting_started/installation_and_usage/#conan-cmake-live-at-head","title":"Conan + CMake (Live At Head)","text":"
    This chapter describes the procedure to Live At Head, which means using the latest stable version of mp-units all the time.
     
    Note
     
    Please note that even though the Conan packages that you will be using are generated ONLY for builds that are considered stable (passed our CI tests), some minor regressions may happen (CI and C++ build environments are not perfect yet). Also, please expect that the library interface might, and probably will, change occasionally. Even though we do our best, such changes might not be reflected in the project's documentation right away.
     
    The procedure is similar to the one described in Conan + CMake (release) with the following differences:
     
       
    1.  
      Before starting the previous procedure, add mp-units remote to your Conan configuration:
       
      conan remote add conan-mpusz https://mpusz.jfrog.io/artifactory/api/conan/conan-oss\n
       
      2.  
    2.  
      In your Conan configuration file, provide the package identifier of the mpusz/testing stream:
       conanfile.txtconanfile.py 
      [requires]\nmp-units/2.5.0@mpusz/testing\n\n[options]\n# The below mp-units options are set to defaults by Conan.\n# Uncomment and set to an explicit value to override the defaults.\n#\n# mp-units*:cxx_modules=True\n# mp-units*:import_std=False\n# mp-units*:std_format=True\n# mp-units*:no_crtp=True\n# mp-units*:contracts=gsl-lite\n# mp-units*:freestanding=False\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\n
       
      from conan import ConanFile\nfrom conan.tools.build import can_run\nfrom conan.tools.cmake import CMake, cmake_layout\n\nclass MPUnitsTestConan(ConanFile):\n    settings = \"os\", \"arch\", \"compiler\", \"build_type\"\n    generators = \"CMakeDeps\", \"CMakeToolchain\"\n\n    def requirements(self):\n        self.requires(\n            \"mp-units/2.5.0@mpusz/testing\",\n            options={\n                # The below mp-units options are set to defaults by Conan.\n                # Uncomment and set to an explicit value to override the defaults.\n                #\n                # \"cxx_modules\": False,\n                # \"import_std\": False,\n                # \"std_format\": True,\n                # \"no_crtp\": True,\n                # \"contracts\": \"gsl-lite\",\n                # \"freestanding\": False,\n            },\n        )\n\n    def layout(self):\n        cmake_layout(self)\n\n    def build(self):\n        cmake = CMake(self)\n        cmake.configure()\n        cmake.build()\n        if can_run(self):\n            cmake.ctest(cli_args=[\"--output-on-failure\"])\n
       
      Tip
       
      The identifiers of the latest packages can always be found in the project's README file or on the project's Artifactory.
       
      3.  
    3.  
      Force Conan to check for updated recipes with -u:
       
      conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing -u\n
       
      4.  
     Alternative installation scenarios"},{"location":"getting_started/installation_and_usage/#copy","title":"Copy","text":"
    As mp-units is a C++ header-only library you can simply copy all needed src/*/include subdirectories to your source tree.
     
    Note
     
    In such a case, you are on your own to ensure all the dependencies are installed and their header files can be located during the build. Please also note that some compiler-specific flags are needed to make the code compile without issues.
    "},{"location":"getting_started/installation_and_usage/#copy-cmake","title":"Copy + CMake","text":"
    If you copy the mp-units library source code from the project's ./src directory (not the entire repo from its root), you can reuse CMake targets defined by the library. To do so, you should use CMakeLists.txt file from the ./src directory:
     
    add_subdirectory(<path_to_mp_units_lib_folder>)\n# ...\ntarget_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\n
     
    Note
     
    You are still on your own to make sure all the dependencies are installed and their header and CMake configuration files can be located during the build.
     
    Important: Library users should not use the top-level CMake file
     
    Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. ./src/CMakeLists.txt contains only a pure library definition and should be used by the customers that prefer to use CMake's add_subdirectory() to handle the dependencies.
     
    To learn more about the rationale, please check our FAQ.
    "},{"location":"getting_started/installation_and_usage/#install","title":"Install","text":"
    If you don't want to use Conan in your project and just want to install the mp-units library on your file system, and use find_package(mp-units) from another repository to find it; it is enough to perform the following steps:
     
    conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\nmv CMakeUserPresets.json src\ncd src\ncmake --preset conan-default -DCMAKE_INSTALL_PREFIX=<your_installation_path>\ncmake --build --preset conan-release --target install\n
    "},{"location":"getting_started/introduction/","title":"Introduction","text":"
    mp-units is a Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation. The initial versions of the library were inspired by the std::chrono::duration but with each release, the interfaces diverged from the original to provide a better user experience.
     
    Info
     
    A brief introduction to the library's interfaces and the rationale for changes in version 2.0 of mp-units were provided in detail by Mateusz Pusz in the \"The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design\" talk at the C++ on Sea 2023 conference.
    "},{"location":"getting_started/introduction/#open-source","title":"Open Source","text":"
    mp-units is Free and Open Source, with a permissive MIT license. Check out the source code and issue tracking (for questions and support, reporting bugs, suggesting feature requests and improvements) at https://github.com/mpusz/mp-units.
    "},{"location":"getting_started/introduction/#with-the-users-experience-in-mind","title":"With the User's Experience in Mind","text":"
    Most of the critical design decisions in the library are dictated by the requirement of providing the best user experience possible. Other C++ physical units libraries are \"famous\" for their enormous and hard-to-understand error messages (one line of the error log often does not fit on one slide). The ultimate goal of mp-units is to improve this and make compile-time errors and debugging as easy and user-friendly as possible.
     
    To achieve this goal, several techniques are applied:
     
       
    • usage of C++20 concepts that improve   compile-times and the readability of error messages when compared to the traditional template   metaprogramming with SFINAE,
      •  
    • usage of strong types for framework entities (instead of type aliases),
      •  
    • usage of symbolic expressions to improve the readability of generated types,
      •  
    • limiting the number of template arguments to the bare minimum.
      •  
     
    Important: It is all about errors
     
    In many generic C++ libraries, compile-time errors do not happen often. It is hard to break std::string or std::vector in a way that won't compile with a huge error log. Physical quantities and units libraries are different. Generation of compile-time errors is the main reason to use such a library.
    "},{"location":"getting_started/introduction/#key-features","title":"Key Features","text":"Feature Description Safety - The affine space strong types (quantity and quantity_point)- Compile-time checked conversions of quantities and units- Unique support for many quantities of the same kind- Type-safe equations on scalar, vector, and tensor quantities and their units- Value-preserving conversions Performance - All the compile-time logic implemented as immediate (consteval) functions- As fast or even faster than working with fundamental types- No space size overhead needed to implement high-level abstractions Great User Experience - Optimized for readable compilation errors and great debugging experience- Efficient and composable way to specify a unit of choice- Value-based dimension, unit, and quantity equations Feature Rich - Systems of Quantities- Systems of Units- Scalar, vector, and tensor quantities- The affine space- Different models of the universe (e.g. natural units systems)- Strong dimensionless quantities- Strong angular system- Supports any unit's magnitude (huge, small, floating-point)- Faster-than-lightspeed constants- Highly adjustable text-output formatting Easy to Extend - Each entity can be defined with a single line of code- User can easily extend the systems with custom dimensions, quantities, and units Low Standardization Cost - Small number of predefined entities thanks to their composability- No external dependencies (assuming full C++20 support)- No macros in the user interface (besides portability and standard-compliance issues)- Possibility to be standardized as a freestanding part of the C++ Standard Library"},{"location":"getting_started/look_and_feel/","title":"Look and Feel","text":"
    Here is a small example of operations possible on scalar quantities:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n
     
    Try it on Compiler Explorer
     
    This library requires some C++20 features (concepts and constraints, classes as NTTP, ...). Thanks to them, a user gets a powerful but still easy-to-use interface where all unit conversions and dimensional analysis can be performed without sacrificing accuracy. Please see the below example for a quick preview of basic library features:
     C++ modulesHeader files 
    #include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n\n  constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n\n  std::cout << v1 << '\\n';                                        // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';  // ***70 mi/h\n  std::cout << std::format(\"{:*^10}\\n\", v3);                      // *110 km/h*\n  std::println(\"{:%N in %U of %D}\", v4);                          // 70 in mi/h of LT\u207b\u00b9\n  std::println(\"{::N[.2f]}\", v5);                                 // 30.56 m/s\n  std::println(\"{::N[.2f]U[dn]}\", v6);                            // 31.29 m\u22c5s\u207b\u00b9\n  std::println(\"{:%N}\", v7);                                      // 31\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n\n  constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n\n  std::cout << v1 << '\\n';                                        // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';  // ***70 mi/h\n  std::cout << std::format(\"{:*^10}\\n\", v3);                      // *110 km/h*\n  std::println(\"{:%N in %U of %D}\", v4);                          // 70 in mi/h of LT\u207b\u00b9\n  std::println(\"{::N[.2f]}\", v5);                                 // 30.56 m/s\n  std::println(\"{::N[.2f]U[dn]}\", v6);                            // 31.29 m\u22c5s\u207b\u00b9\n  std::println(\"{:%N}\", v7);                                      // 31\n}\n
     
    Try it on Compiler Explorer
     
    Note
     
    More code examples can be found in the Examples chapter.
    "},{"location":"getting_started/project_structure/","title":"Project structure","text":"
    This chapter provides a high level overview of the project to make it easier to navigate, build, and use.
    "},{"location":"getting_started/project_structure/#cmake-projects-and-dependencies","title":"CMake projects and dependencies","text":"
    The GitHub repository contains three independent CMake-based projects:
     
       
    •  
      ./src
       
         
      • header-only project containing whole mp-units library
        •  
      • ./src/CMakeLists.txt file is intended as an entry point for library users
        •  
      •  
        in case this library becomes part of the C++ standard, it will have no external dependencies   but until then, it depends on the following:
         
           
        • gsl-lite or ms-gsl   to verify runtime contracts (if contract checking is enabled),
          •  
        • {fmt} to provide text formatting of quantities   (if std::format is not supported yet on a specific compiler).
          •  
         
        •  
       
      •  
    •  
      .
       
         
      • project used as an entry point for library development and CI/CD
        •  
      • it wraps ./src project together with usage examples and tests
        •  
      •  
        additionally to the dependencies of ./src project, it uses:
         
           
        • Catch2 library as a unit tests framework,
          •  
        • linear algebra   library based on proposal P1385 used in some examples   and tests.
          •  
         
        •  
       
      •  
    •  
      ./test_package
       
         
      • CMake library installation and Conan package verification.
        •  
       
      •  
     
    Important: Library users should not use the top-level CMake file
     
    Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
     
    This is why our projects have two entry points:
     
       
    • ./CMakeLists.txt is to be used by projects developers to build ALL the project code   with really restrictive compilation flags,
      •  
    • ./src/CMakeLists.txt contains only a pure library definition and should be used by the   customers that prefer to use CMake's   add_subdirectory() to   handle the dependencies.
      •  
     
    To learn more about the rationale, please check our FAQ.
    "},{"location":"getting_started/project_structure/#modules","title":"Modules","text":"
    The mp-units library provides the following C++ modules:
     
    flowchart TD\n    mp_units --- mp_units.systems --- mp_units.core
     C++ Module CMake Target Contents mp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems 
    Note
     
    C++ modules are provided within the package only when:
     
       
    • cxx_modules Conan option is set to True,
      •  
    • MP_UNITS_BUILD_CXX_MODULES CMake option is set to ON.
      •  
    "},{"location":"getting_started/project_structure/#header-files","title":"Header files","text":"
    All of the project's header files can be found in the mp-units/... subdirectory.
    "},{"location":"getting_started/project_structure/#core-library","title":"Core library","text":"
       
    • mp-units/framework.h contains the entire library's framework definitions,
      •  
    • mp-units/concepts.h exposes only the library's concepts for generic code needs,
      •  
    • mp-units/format.h provides text formatting support,
      •  
    • mp-units/ostream.h enables streaming of the library's objects to the text output,
      •  
    • mp-units/math.h provides overloads of common math functions for quantities,
      •  
    • mp-units/random.h provides C++ pseudo-random number generators for quantities,
      •  
    • mp-units/compat_macros.h provides macros for wide compatibility.
      •  
     More details 
    More detailed header files can be found in subfolders which typically should not be included by the end users:
     
       
    • mp-units/framework/... provides all the public interfaces of the framework,
      •  
    • mp-units/bits/... provides private implementation details only (no public definitions),
      •  
    • mp-units/ext/... contains external dependencies that at some point in the future should   be replaced with C++ standard library facilities.
      •  
    "},{"location":"getting_started/project_structure/#systems-and-associated-utilities","title":"Systems and associated utilities","text":"
    The systems definitions can be found in the mp-units/systems/... subdirectory:
    "},{"location":"getting_started/project_structure/#systems-of-quantities","title":"Systems of quantities","text":"
       
    • mp-units/systems/isq.h provides   International System of Quantities (ISQ)   definitions,
      •  
    • mp-units/systems/isq_angle.h provides a modification of the ISQ based on   the proposals to make an angle a base quantity in the ISQ,
      •  
     Tip: Improving compile times 
    mp-units/systems/isq.h might be expensive to compile in every translation unit. There are some smaller, domain targeted files available for explicit inclusion in the mp-units/systems/isq/... subdirectory.
    "},{"location":"getting_started/project_structure/#systems-of-units","title":"Systems of units","text":"
       
    • mp-units/systems/si.h provides   International System of Units (SI)   definitions and associated math functions,
      •  
    • mp-units/systems/iec.h provides units and prefixes defined by IEC (e.g., in the series of   IEC 80000 standards),
      •  
    • mp-units/systems/angular.h provides strong angular units   and associated math functions,
      •  
    • mp-units/systems/international.h provides   international yard and pound units,
      •  
    • mp-units/systems/imperial.h includes international.h and extends it with   imperial units,
      •  
    • mp-units/systems/usc.h includes international.h and extends it with   United States customary system of units,
      •  
    • mp-units/systems/cgs.h provides   centimetre-gram-second system of units,
      •  
    • mp-units/systems/iau.h provides   astronomical system of units,
      •  
    • mp-units/systems/hep.h provides units used in   high-energy physics,
      •  
    • mp-units/systems/typographic.h provides units used in   typography or typesetting,
      •  
    • mp-units/systems/natural.h provides an example implementation of   natural units.
      •  
     Tip: Improving compile times 
    mp-units/systems/si.h might be expensive to compile in every translation unit. There are some smaller files available for explicit inclusion in the mp-units/systems/si/... subdirectory.
     
    mp-units/systems/si/unit_symbols.h is the most expensive to include.
    "},{"location":"getting_started/quick_start/","title":"Quick Start","text":"
    This chapter provides a quick introduction to get you started with mp-units. Much more details can be found in our User's Guide.
    "},{"location":"getting_started/quick_start/#quantities","title":"Quantities","text":"
    A quantity is a concrete amount of a unit representing a quantity type of a specified dimension with a specific representation. It is represented in the library with a quantity class template.
     
    The SI Brochure says:
     
    SI Brochure
     
    The value of the quantity is the product of the number and the unit. The space between the number and the unit is regarded as a multiplication sign (just as a space between units implies multiplication).
     
    Following the above, the value of a quantity in the mp-units library is created by multiplying a number with a predefined unit:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n
     
    Info
     
    In case someone doesn't like the multiply syntax or there is an ambiguity between operator* provided by this and other libraries, there are two other ways to create a quantity:
     
       
    1.  
      delta construction helper:
       C++ modulesHeader files 
      import mp_units;\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n
       
      #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n
       
      2.  
    2.  
      A two-parameter constructor:
       C++ modulesHeader files 
      import mp_units;\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n
       
      #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n
       
      3.  
     
    The above creates an instance of quantity<derived_unit<si::metre, per<si::second>>{}, int>. The same can be obtained using optional unit symbols:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n
     
    Important
     
    Unit symbols introduce a lot of short identifiers into the current scope, which may cause naming collisions with unrelated but already existing identifiers in the code base. This is why unit symbols are opt-in and typically should be imported only in the context where they are being used (e.g., function scope).
     
    A user has several options here to choose from depending on the required scenario and possible naming conflicts:
     using-directiveusing-declarationcustom short identifierunit names 
    Explicitly \"import\" all of the symbols of a specific system of units from a dedicated unit_symbols namespace with a using-directive:
     
    using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n  // imports all the SI symbols at once\n  using namespace si::unit_symbols;\n  quantity speed = speed_m_s * m / s;\n  // ...\n}\n
     
    Note
     
    This solution is perfect for small and isolated scopes but can cause surprising issues when used in larger scopes or when used for the entire program namespace.
     
    There are 29 named units in SI, and each of them has many prefixed variations (e.g., ng, kcd, ...). It is pretty easy to introduce a name collision with those.
     
    Selectively bring only the required and not-conflicting symbols with using-declarations:
     
    using namespace mp_units;\n\nvoid foo(double N)\n{\n  // 'N' function parameter would collide with the SI symbol for Newton, so we only bring what we need\n  using si::unit_symbols::m;\n  using si::unit_symbols::s;\n  quantity speed = N * m / s;\n  // ...\n}\n
     
    Specify a custom not conflicting unit identifier for a unit:
     
    using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n  // names of some local variables are conflicting with the symbols we want to use\n  auto m = ...;\n  auto s = ...;\n\n  constexpr Unit auto mps = si::metre / si::second;\n  quantity speed = speed_m_s * mps;\n}\n
     
    Full unit names are straightforward to use and often provide the most readable code:
     
    using namespace mp_units;\n\nvoid foo(double m, double s)\n{\n  quantity speed = m * si::metre / (s * si::second);\n  // ...\n}\n
     
    Quantities of the same kind can be added, subtracted, and compared to each other:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n
     
    Various quantities can be multiplied or divided by each other:
     
    static_assert(140 * km / (2 * h) == 70 * km / h);\n
     
    Note
     
    In case you wonder why this library does not use UDLs to create quantities, please check our FAQ.
    "},{"location":"getting_started/quick_start/#quantity-points","title":"Quantity points","text":"
    The quantity point specifies an absolute quantity with respect to an origin. If no origin is provided explicitly, an implicit one will be provided by the library.
     
    Together with quantities, they model The Affine Space.
     
    Quantity points should be used in all places where adding two values is meaningless (e.g., temperature points, timestamps, altitudes, readouts from the car's odometer, etc.).
     
    The set of operations that can be done on quantity points is limited compared to quantities. This introduces an additional type-safety.
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::usc::unit_symbols;\n\n  quantity_point temp = point<deg_C>(20.);\n  std::println(\"Temperature: {} ({})\",\n               temp.quantity_from_zero(),\n               temp.in(deg_F).quantity_from_zero());\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::usc::unit_symbols;\n\n  quantity_point temp = point<deg_C>(20.);\n  std::println(\"Temperature: {} ({})\",\n               temp.quantity_from_zero(),\n               temp.in(deg_F).quantity_from_zero());\n}\n
     
    The above outputs:
     
    Temperature: 20 \u2103 (68 \u2109)\n
     
    Info
     
    Check The Affine Space chapter to learn more about quantity points.
    "},{"location":"users_guide/terms_and_definitions/","title":"Terms and Definitions","text":"
    The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM. You can find essential project-related definitions in our documentation's \"Glossary\" chapter. Even more, terms are provided in the official metrology vocabulary of the ISO and BIPM.
     
    Tip
     
    Please familiarize yourself with terms from \"Glossary\" to better understand the documentation and improve domain-related communication and discussions.
    "},{"location":"users_guide/examples/avg_speed/","title":"avg_speed","text":"
    Try it on Compiler Explorer
     
    Let's continue the previous example. This time, our purpose will not be to showcase as many library features as possible, but we will scope on different interfaces one can provide with the mp-units. We will also describe some advantages and disadvantages of presented solutions.
     
    First, we either import a module or include all the necessary header files and import all the identifiers from the mp_units namespace:
     avg_speed.cpp
    #ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <exception>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/ostream.h>\n#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\nnamespace {\n\nusing namespace mp_units;\n
     
    Next, we define two functions calculating average speed based on quantities of fixed units and integral and floating-point representation types, respectively, and a third function that we introduced in the previous example:
     avg_speed.cpp
    constexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,\n                                                                       quantity<si::second, int> t)\n{\n  return d / t;\n}\n\nconstexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)\n{\n  return d / t;\n}\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    We also added a simple utility to print our results:
     avg_speed.cpp
    template<QuantityOf<isq::length> D, QuantityOf<isq::time> T, QuantityOf<isq::speed> V>\nvoid print_result(D distance, T duration, V speed)\n{\n  const auto result_in_kmph = speed.force_in(si::kilo<si::metre> / non_si::hour);\n  std::cout << \"Average speed of a car that makes \" << distance << \" in \" << duration << \" is \" << result_in_kmph\n            << \".\\n\";\n}\n
     
    Now, let's analyze how those three utility functions behave with different sets of arguments. First, we are going to use quantities of SI units and integral representation:
     avg_speed.cpp
    void example()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  // SI (int)\n  {\n    constexpr auto distance = 220 * km;\n    constexpr auto duration = 2 * h;\n\n    std::cout << \"SI units with 'int' as representation\\n\";\n\n    print_result(distance, duration, fixed_int_si_avg_speed(distance, duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    The above provides the following output:
     
    SI units with 'int' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\n
     
    Please note that in the first two cases, we must convert length from km to m and time from h to s. The converted values are used to calculate speed in m/s which is then again converted to the one in km/h. Those conversions not only impact the application's runtime performance but may also affect the precision of the final result. Such truncation can be easily observed in the first case where we deal with integral representation types (the resulting speed is 108 km/h).
     
    The second scenario is really similar to the previous one, but this time, function arguments have floating-point representation types:
     avg_speed.cpp
      // SI (double)\n  {\n    constexpr auto distance = 220. * km;\n    constexpr auto duration = 2. * h;\n\n    std::cout << \"\\nSI units with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<int>(distance), value_cast<int>(duration)));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    Conversion from floating-point to integral representation types is considered value-truncating and that is why now, in the first case, we need an explicit call to value_cast<int>.
     
    In the text output, we can observe that, again, the resulting value gets truncated during conversions in the first cast:
     
    SI units with 'double' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\n
     
    Next, let's do the same for integral and floating-point representations, but this time using international mile:
     avg_speed.cpp
      // International mile (int)\n  {\n    using namespace mp_units::international::unit_symbols;\n\n    constexpr auto distance = 140 * mi;\n    constexpr auto duration = 2 * h;\n\n    std::cout << \"\\nInternational mile with 'int' as representation\\n\";\n\n    // it is not possible to make a lossless conversion of miles to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n\n  // International mile (double)\n  {\n    using namespace mp_units::international::unit_symbols;\n\n    constexpr auto distance = 140. * mi;\n    constexpr auto duration = 2. * h;\n\n    std::cout << \"\\nInternational mile with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    // also it is not possible to make a lossless conversion of miles to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    One important difference here is the fact that as it is not possible to make a lossless conversion of miles to meters on a quantity using an integral representation type, so this time, we need a value_cast<m, int> to force it.
     
    If we check the text output of the above, we will see the following:
     
    International mile with 'int' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112 km/h.\n\nInternational mile with 'double' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\n
     
    Please note how the first and third results get truncated using integral representation types.
     
    In the end, we repeat the scenario for CGS units:
     avg_speed.cpp
      // CGS (int)\n  {\n    constexpr auto distance = 22'000'000 * cgs::centimetre;\n    constexpr auto duration = 7200 * cgs::second;\n\n    std::cout << \"\\nCGS units with 'int' as representation\\n\";\n\n    // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n\n  // CGS (double)\n  {\n    constexpr auto distance = 22'000'000. * cgs::centimetre;\n    constexpr auto duration = 7200. * cgs::second;\n\n    std::cout << \"\\nCGS units with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n}\n\n}  // namespace\n
     
    Again, we observe value_cast being used in the same places and consistent truncation errors in the text output:
     
    CGS units with 'int' as representation\nAverage speed of a car that makes 22000000 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 109 km/h.\n\nCGS units with 'double' as representation\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\n
     
    The example file ends with a simple main() function:
     avg_speed.cpp
    int main()\n{\n  try {\n    example();\n  } catch (const std::exception& ex) {\n    std::cerr << \"Unhandled std exception caught: \" << ex.what() << '\\n';\n  } catch (...) {\n    std::cerr << \"Unhandled unknown exception caught\\n\";\n  }\n}\n
    ","tags":["CGS System","International System"]},{"location":"users_guide/examples/hello_units/","title":"hello_units","text":"
    Try it on Compiler Explorer
     
    This is a really simple example showcasing the features of the mp-units library.
     
    First, we either import the mp_units module or include the headers for:
     
       
    • an International System of Quantities (ISQ),
      •  
    • an International System of units (SI),
      •  
    • units derived from the International Yard and Pound,
      •  
    • text formatting and stream output support.
      •  
     hello_units.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iomanip>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n
     
    Also, to shorten the definitions, we \"import\" all the symbols from the mp_units namespace.
     hello_units.cpp
    using namespace mp_units;\n
     
    Next, we define a simple function that calculates the average speed based on the provided arguments of length and time:
     hello_units.cpp
    constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    The above function template takes any quantities implicitly convertible to isq::length and isq::time, respectively. Those quantities can use any compatible unit and a representation type. The function returns a result of a straightforward equation and ensures that its quantity type is implicitly convertible to isq::speed.
     
    Tip
     
    Besides verifying the type returned from the function, constraining a generic return type is beneficial for users of such a function as it provides more information of what to expect from a function than just using auto.
     hello_units.cpp
    int main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n
     
    The above lines explicitly opt into using unit symbols from two systems of units. As this introduces a lot of short identifiers into the current scope, it is not done implicitly while including a header file.
     hello_units.cpp
      constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * km, 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * isq::duration[h]);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n
     
       
    • Lines 27 & 28 create a quantity of kind isq::length / isq::time with the numbers   and units provided. Such quantities can be converted or assigned to any other quantity   with a matching kind.
      •  
    • Line 29 calls our function template with quantities of kind isq::length and   isq::time and number and units provided.
      •  
    • Line 30 explicitly provides quantity types of the quantities passed to a function template.   This time, those will not be quantity kinds anymore and will have   more restrictive conversion rules.
      •  
    • Line 31 changes the unit of a quantity v3 to m / s in a   value-preserving way   (floating-point representations are considered to be value-preserving).
      •  
    • Line 32 does a similar operation, but this time, it would also succeed for   value-truncating cases   (if that was the case).
      •  
    • Line 33 does a value-truncating conversion   of changing the underlying representation type from double to int.
      •  
     hello_units.cpp
      std::cout << v1 << '\\n';                                           // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';     // ***70 mi/h\n  std::cout << MP_UNITS_STD_FMT::format(\"{:*^10}\\n\", v3);            // *110 km/h*\n  std::cout << MP_UNITS_STD_FMT::format(\"{:%N in %U of %D}\\n\", v4);  // 70 in mi/h of LT\u207b\u00b9\n  std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]}\\n\", v5);         // 30.56 m/s\n  std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]U[dn]}\\n\", v6);    // 31.29 m\u22c5s\u207b\u00b9\n  std::cout << MP_UNITS_STD_FMT::format(\"{:%N}\\n\", v7);              // 31\n}\n
     
    The above presents various ways to print a quantity. Both stream insertion operations and std::format facilities are supported.
     
    Tip
     
    MP_UNITS_STD_FMT is used for compatibility reasons. If a specific compiler does not support std::format or a user prefers to use the {fmt} library, this macro will resolve to fmt namespace. Otherwise, the std namespace will be used.
     
    More about it can be found in the Wide Compatibility chapter.
    ","tags":["International System","Text Formatting"]},{"location":"users_guide/examples/hw_voltage/","title":"hw_voltage","text":"
    Try it on Compiler Explorer
     
    As it was stated in The Affine Space chapter, every measurement can (and probably should) be modelled as a quantity_point. This is a perfect example of such a use case.
     
    This example implements a simplified scenario of measuring voltage read from hardware through a mapped 16-bits register. The actual voltage range of [-10 V, 10 V] is mapped to [-32767, 32767] on hardware. Translation of the value requires not only scaling of the value but also applying of an offset.
     
    First we include all the dependencies:
     hw_voltage.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iostream>\n#include <optional>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\nusing namespace mp_units;\n
     
    Next, we specify the real measurement voltage range to be in the range of [-10, 10]:
     hw_voltage.cpp
    // real voltage range\ninline constexpr int min_voltage = -10;\ninline constexpr int max_voltage = 10;\ninline constexpr int voltage_range = max_voltage - min_voltage;\n
     
    and provide a storage type and special values for the hardware representation:
     hw_voltage.cpp
    // hardware encoding of voltage\nusing voltage_hw_t = std::uint16_t;\ninline constexpr voltage_hw_t voltage_hw_error = std::numeric_limits<voltage_hw_t>::max();\ninline constexpr voltage_hw_t voltage_hw_min = 0;\ninline constexpr voltage_hw_t voltage_hw_max = voltage_hw_error - 1;\ninline constexpr voltage_hw_t voltage_hw_range = voltage_hw_max - voltage_hw_min;\ninline constexpr voltage_hw_t voltage_hw_zero = voltage_hw_range / 2;\n
     
    Finally, we define a quantity point origin, an offset unit that scales the value and uses this origin to offset the zero of the sale, and a dedicated quantity point alias using those:
     hw_voltage.cpp
    inline constexpr struct hw_voltage_origin final :\n  relative_point_origin<point<si::volt>(min_voltage)> {} hw_voltage_origin;\n\ninline constexpr struct hw_voltage_unit final :\n  named_unit<\"hwV\", mag_ratio<voltage_range, voltage_hw_range> * si::volt, hw_voltage_origin> {} hw_voltage_unit;\n\nusing hw_voltage_quantity_point = quantity_point<hw_voltage_unit, hw_voltage_origin, voltage_hw_t>;\n
     
    Now, when everything is ready, we can simulate mapping of our hardware register, and provide a helper function that will read the value and construct a quantity point from the obtained copy:
     hw_voltage.cpp
    // mapped HW register\nvolatile voltage_hw_t hw_voltage_value;\n\nstd::optional<hw_voltage_quantity_point> read_hw_voltage()\n{\n  voltage_hw_t local_copy = hw_voltage_value;\n  if (local_copy == voltage_hw_error) return std::nullopt;\n  return point<hw_voltage_unit>(local_copy);\n}\n
     
    We also provide a simple print helper for our quantity points:
     hw_voltage.cpp
    void print(QuantityPoint auto qp)\n{\n  std::cout << MP_UNITS_STD_FMT::format(\"{:10} ({:5})\", qp.quantity_from_zero(),\n                                        value_cast<double, si::volt>(qp).quantity_from_zero());\n}\n
     
    In the main function we simulate setting of 3 values by our hardware. Each of them is read and printed in the voltage unit used on the hardware as well as in the standard SI unit:
     hw_voltage.cpp
    int main()\n{\n  // simulate reading of 3 values from the hardware\n  hw_voltage_value = voltage_hw_min;\n  quantity_point qp1 = read_hw_voltage().value();\n  hw_voltage_value = voltage_hw_zero;\n  quantity_point qp2 = read_hw_voltage().value();\n  hw_voltage_value = voltage_hw_max;\n  quantity_point qp3 = read_hw_voltage().value();\n\n  print(qp1);\n  print(qp2);\n  print(qp3);\n}\n
     
    The above program results with the following text output:
     
         0 hwV (-10 V)\n 32767 hwV (  0 V)\n 65534 hwV ( 10 V)\n
    ","tags":["Affine Space","Embedded","Text Formatting"]},{"location":"users_guide/examples/si_constants/","title":"si_constants","text":"
    Try it on Compiler Explorer
     
    The next example presents all the seven defining constants of the SI system. We can observe how Faster-than-lightspeed Constants work in practice.
     si_constants.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#endif\n
     
    As always, we start with the inclusion of all the needed header files. The main part of the example prints all of the SI-defining constants:
     si_constants.cpp
    int main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si;\n  using namespace mp_units::si::unit_symbols;\n\n  std::cout << \"The seven defining constants of the SI and the seven corresponding units they define:\\n\";\n  std::cout << MP_UNITS_STD_FMT::format(\"- hyperfine transition frequency of Cs: {} = {::N[.0]}\\n\",\n                                        1. * si2019::hyperfine_structure_transition_frequency_of_cs,\n                                        (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));\n  std::cout << MP_UNITS_STD_FMT::format(\"- speed of light in vacuum:             {} = {::N[.0]}\\n\",\n                                        1. * si2019::speed_of_light_in_vacuum,\n                                        (1. * si2019::speed_of_light_in_vacuum).in(m / s));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Planck constant:                      {} = {::N[.8e]}\\n\",\n                                        1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));\n  std::cout << MP_UNITS_STD_FMT::format(\"- elementary charge:                    {} = {::N[.9e]}\\n\",\n                                        1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Boltzmann constant:                   {} = {::N[.6e]}\\n\",\n                                        1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Avogadro constant:                    {} = {::N[.8e]}\\n\",\n                                        1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));\n  std::cout << MP_UNITS_STD_FMT::format(\"- luminous efficacy:                    {} = {}\\n\",\n                                        1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));\n}\n
     
    While analyzing the output of this program (provided below), we can easily notice that a direct printing of the quantity provides just a value 1 with a proper constant symbol. This is the main power of the Faster-than-lightspeed Constants feature. Only after we explicitly convert the unit of a quantity to proper SI units we get an actual numeric value of the constant.
     
    The seven defining constants of the SI and the seven corresponding units they define:\n- hyperfine transition frequency of Cs: 1 \u0394\u03bd_Cs = 9192631770 Hz\n- speed of light in vacuum:             1 c = 299792458 m/s\n- Planck constant:                      1 h = 6.62607015e-34 J s\n- elementary charge:                    1 e = 1.602176634e-19 C\n- Boltzmann constant:                   1 k = 1.380649e-23 J/K\n- Avogadro constant:                    1 N_A = 6.02214076e+23 1/mol\n- luminous efficacy:                    1 K_cd = 683 lm/W\n
    ","tags":["Physical Constants","Text Formatting"]},{"location":"users_guide/examples/tags_index/","title":"Tags Index","text":"
    Note
     
    mp-units usage example applications are meant to be built on all of the supported compilers. This is why they benefit from the Wide Compatibility mode.
     
    Tip
     
    All usage examples in this chapter are categorized with appropriate tags to simplify navigation and search of relevant code. You can either read all the examples one-by-one in the order provided by the documentation authors or, thanks to the tagging system, jump straight to the example that is the most interesting for you.
    "},{"location":"users_guide/examples/tags_index/#tag:affine-space","title":"Affine Space","text":"
       
    •             hw_voltage          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:cgs-system","title":"CGS System","text":"
       
    •             avg_speed          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:embedded","title":"Embedded","text":"
       
    •             hw_voltage          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:international-system","title":"International System","text":"
       
    •             avg_speed          
      •  
    •             hello_units          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:physical-constants","title":"Physical Constants","text":"
       
    •             si_constants          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:text-formatting","title":"Text Formatting","text":"
       
    •             hello_units          
      •  
    •             hw_voltage          
      •  
    •             si_constants          
      •  
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/","title":"Character of a Quantity","text":"
    Warning
     
    This chapter's features are experimental and subject to change or removal. Please share your feedback if something seems wrong or could be improved.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#scalars-vectors-and-tensors","title":"Scalars, vectors, and tensors","text":"
    ISO 80000-2
     
    Scalars, vectors and tensors are mathematical objects that can be used to denote certain physical quantities and their values. They are as such independent of the particular choice of a coordinate system, whereas each scalar component of a vector or a tensor and each component vector and component tensor depend on that choice.
     
    Such distinction is important because each quantity character represents different properties and allows different operations to be done on its quantities.
     
    For example, imagine a physical units library that allows the creation of a \\(speed\\) quantity from both \\(length / time\\) and \\(length * time\\). It wouldn't be too safe to use such a product, right?
     
    Now we have to realize that both of the above operations (multiplication and division) are not even mathematically defined for linear algebra types such as vectors or tensors. On the other hand, two vectors can be passed as arguments to dot and cross-product operations. The result of the first one is a scalar. The second one results in a vector that is perpendicular to both vectors passed as arguments. Again, it wouldn't be safe to allow replacing those two operations with each other or expect the same results from both cases. This simply can't work.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#isq-defines-quantities-of-all-characters","title":"ISQ defines quantities of all characters","text":"
    While defining quantities ISO 80000 explicitly mentions when a specific quantity has a vector or tensor character. Here are some examples:
     Quantity Character Quantity Equation \\(duration\\) scalar {base quantity} \\(mass\\) scalar {base quantity} \\(length\\) scalar {base quantity} \\(path\\; length\\) scalar {base quantity} \\(radius\\) scalar {base quantity} \\(position\\; vector\\) vector {base quantity} \\(velocity\\) vector \\(position\\; vector / duration\\) \\(acceleration\\) vector \\(velocity / duration\\) \\(force\\) vector \\(mass * acceleration\\) \\(power\\) scalar \\(force \\cdot velocity\\) \\(moment\\; of\\; force\\) vector \\(position\\; vector \\times force\\) \\(torque\\) scalar \\(moment\\; of\\; force \\cdot \\{unit\\; vector\\}\\) \\(surface\\; tension\\) scalar \\(\\lvert force \\rvert / length\\) \\(angular\\; displacement\\) scalar \\(path\\; length / radius\\) \\(angular\\; velocity\\) vector \\(angular\\; displacement / duration * \\{unit\\; vector\\}\\) \\(momentum\\) vector \\(mass * velocity\\) \\(angular\\; momentum\\) vector \\(position\\; vector \\times momentum\\) \\(moment\\; of\\; inertia\\) tensor \\(angular\\; momentum \\otimes angular\\; velocity\\) 
    In the above equations:
     
       
    • \\(a * b\\) - regular multiplication where one of the arguments has to be scalar
      •  
    • \\(a / b\\) - regular division where the divisor has to be scalar
      •  
    • \\(a \\cdot b\\) - dot product of two vectors
      •  
    • \\(a \\times b\\) - cross product of two vectors
      •  
    • \\(\\lvert a \\rvert\\) - magnitude of a vector
      •  
    • \\(\\{unit\\; vector\\}\\) - a special vector with the magnitude of \\(1\\)
      •  
    • \\(a \\otimes b\\) - tensor product of two vectors or tensors
      •  
     
    Note
     
    As of now, all of the C++ physical units libraries on the market besides mp-units do not support the operations mentioned above. They expose only multiplication and division operators, which do not work for linear algebra-based representation types. If a user of those libraries would like to create the quantities provided in the above table properly, this would result in a compile-time error stating that multiplication and division of two linear algebra vectors is impossible.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#characters-dont-apply-to-dimensions-and-units","title":"Characters don't apply to dimensions and units","text":"
    ISO 80000 explicitly states that dimensions are orthogonal to quantity characters:
     
    ISO 80000-1:2009
     
    In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
     
    Also, it explicitly states that:
     
    ISO 80000-2
     
    All units are scalars.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#defining-vector-and-tensor-quantities","title":"Defining vector and tensor quantities","text":"
    To specify that a specific quantity has a vector or tensor character a value of quantity_character enumeration can be appended to the quantity_spec describing such a quantity type:
     C++23C++20Portable 
    inline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<displacement> {} position_vector;\n
     
    inline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, displacement> {} position_vector;\n
     
    QUANTITY_SPEC(displacement, length, quantity_character::vector);\nQUANTITY_SPEC(position_vector, displacement);\n
     
    With the above, all the quantities derived from position_vector or displacement will have a correct character determined according to the kind of operations included in the quantity equation defining a derived quantity.
     
    For example, velocity in the below definition will be defined as a vector quantity (no explicit character override is needed):
     C++23C++20Portable 
    inline constexpr struct velocity final : quantity_spec<speed, displacement / duration> {} velocity;\n
     
    inline constexpr struct velocity final : quantity_spec<velocity, speed, displacement / duration> {} velocity;\n
     
    QUANTITY_SPEC(velocity, speed, displacement / duration);\n
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#representation-types-for-vector-and-tensor-quantities","title":"Representation types for vector and tensor quantities","text":"
    As we remember, the quantity class template is defined as follows:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    The second template parameter is constrained with a RepresentationOf concept that checks if the provided representation type satisfies the requirements for the character associated with this quantity type.
     
    Note
     
    The current version of the C++ Standard Library does not provide any types that could be used as a representation type for vector and tensor quantities. This is why users are on their own here .
     
    To provide examples and implement unit tests, our library uses the types proposed in the P1385 and available as a Conan package in the Conan Center. However, thanks to the provided customization points, any linear algebra library types can be used as a vector or tensor quantity representation type.
     
    For example, here is how it can be done for the P1385 types:
     
    #include <matrix>\n\nusing la_vector = STD_LA::fixed_size_column_vector<double, 3>;\n\nQuantity auto q = la_vector{1, 2, 3} * isq::velocity[m / s];\n
     
    In case there is an ambiguity of operator* between mp-units and a linear algebra library, we can either:
     
       
    •  
      use two-parameter constructor
       
      Quantity auto q = quantity{la_vector{1, 2, 3}, isq::velocity[m / s]};\n
       
      •  
    •  
      provide a dedicated overload of operator* that will resolve the ambiguity and wrap the above
       
      template<Reference R>\nQuantity auto operator*(la_vector rep, R)\n{\n  return quantity{rep, R{}};\n}\n
       
      •  
     
    Note
     
    The following does not work:
     
    Quantity auto q1 = la_vector{1, 2, 3} * m / s;\nQuantity auto q2 = isq::velocity(la_vector{1, 2, 3} * m / s);\nquantity<isq::velocity[m/s]> q3{la_vector{1, 2, 3} * m / s};\n
     
    In all the cases above, the SI unit m / s has an associated scalar quantity of isq::length / isq::time. la_vector is not a correct representation type for a scalar quantity so the construction fails.
    "},{"location":"users_guide/framework_basics/concepts/","title":"Concepts","text":"
    This chapter enumerates all the user-facing concepts in the mp-units library.
    "},{"location":"users_guide/framework_basics/concepts/#Dimension","title":"Dimension<T>","text":"
    Dimension concept matches a dimension of either a base or derived quantity:
     
       
    • Base dimensions are explicitly defined by the user   by inheriting from the instantiation of a base_dimension class template. It should be instantiated with   a unique symbol identifier describing this dimension in a specific   system of quantities.
      •  
    • Derived dimensions are implicitly created   by the library's framework based on the quantity equation   provided in the quantity specification.
      •  
     
    All of the above dimensions have to be marked as final.
    "},{"location":"users_guide/framework_basics/concepts/#DimensionOf","title":"DimensionOf<T, V>","text":"
    DimensionOf concept is satisfied when both arguments satisfy a Dimension concept and when they compare equal.
    "},{"location":"users_guide/framework_basics/concepts/#QuantitySpec","title":"QuantitySpec<T>","text":"
    QuantitySpec concept matches all the quantity specifications including:
     
       
    • Base quantities defined by a user by inheriting from   the quantity_spec class template instantiated with a base dimension   argument.
      •  
    • Derived named quantities defined by a user by   inheriting from the quantity_spec class template instantiated with a result of a   quantity equation passed as an argument.
      •  
    • Other named quantities forming a hierarchy of quantities   of the same kind defined by a user by inheriting from the   quantity_spec class template instantiated with another \"parent\" quantity specification passed as an   argument.
      •  
    • Quantity kinds describing a family of mutually comparable quantities.
      •  
    • Intermediate derived quantity specifications being   a result of a quantity equations on other specifications.
      •  
     
    All of the above quantity specifications have to be marked as final.
    "},{"location":"users_guide/framework_basics/concepts/#QuantitySpecOf","title":"QuantitySpecOf<T, V>","text":"
    QuantitySpecOf concept is satisfied when both arguments satisfy a QuantitySpec concept and when T is implicitly convertible to V.
    "},{"location":"users_guide/framework_basics/concepts/#UnitMagnitude","title":"UnitMagnitude<T>","text":"
    UnitMagnitude concept is satisfied by all types defining a unit magnitude.
     
    Info
     
    Unit magnitude implementation is a private implementation detail of the library.
    "},{"location":"users_guide/framework_basics/concepts/#Unit","title":"Unit<T>","text":"
    Unit concept matches all the units in the library including:
     
       
    • Base units defined by a user by inheriting from the named_unit   class template instantiated with a unique symbol identifier describing this unit in a specific   system of units.
      •  
    • Named scaled units defined by a user by inheriting from the named_unit class template instantiated   with a unique symbol identifier and a product of multiplying another unit with some magnitude.
      •  
    • Prefixed units defined by a user by inheriting from the prefixed_unit class template instantiated   with a prefix symbol, a magnitude, and a unit to be prefixed.
      •  
    • Derived named units defined by a user by inheriting from the   named_unit class template instantiated with a unique symbol identifier and a result of   unit equation passed as an argument.
      •  
    • Derived unnamed units being a result of a   unit equations on other units.
      •  
     
    All of the above units have to be marked as final.
     
    Note
     
    In the mp-units library, physical constants are also implemented as units.
    "},{"location":"users_guide/framework_basics/concepts/#AssociatedUnit","title":"AssociatedUnit<T>","text":"
    AssociatedUnit concept describes a unit with an associated quantity and is satisfied by:
     
       
    • All units derived from a named_unit class template instantiated with a unique symbol identifier   and a QuantitySpec of a quantity kind.
      •  
    • All units being a result of unit equations on other   associated units.
      •  
     Examples 
    All units in the SI have associated quantities. For example, si::second is specified to measure isq::time.
     
    Natural units typically do not have an associated quantity. For example, if we assume c = 1, a natural::second unit can be used to measure both time and length. In such case, speed would have a unit of one.
    "},{"location":"users_guide/framework_basics/concepts/#PrefixableUnit","title":"PrefixableUnit<T>","text":"
    PrefixableUnit concept is satisfied by all units derived from a named_unit class template. Such units can be passed as an argument to a prefixed_unit class template.
    "},{"location":"users_guide/framework_basics/concepts/#UnitOf","title":"UnitOf<T, V>","text":"
    UnitOf concept is satisfied for all units T for which an associated quantity spec is implicitly convertible to the provided QuantitySpec value.
    "},{"location":"users_guide/framework_basics/concepts/#Reference","title":"Reference<T>","text":"
    Reference concept is satisfied by all quantity reference types. Such types provide all the meta-information required to create a Quantity. A Reference can either be:
     
       
    • An AssociatedUnit.
      •  
    • The instantiation of a reference class template with a QuantitySpec passed as   the first template argument and a Unit passed as the second one.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#ReferenceOf","title":"ReferenceOf<T, V>","text":"
    ReferenceOf concept is satisfied by references T which have a quantity specification that satisfies QuantitySpecOf<V> concept.
    "},{"location":"users_guide/framework_basics/concepts/#RepresentationOf","title":"RepresentationOf<T, V>","text":"
    RepresentationOf concept constraints a type of a number that stores the value of a quantity and is satisfied:
     
       
    •  
      if the type of V satisfies QuantitySpec:
       
         
      • by all representation types when V describes   a quantity kind,
        •  
      • otherwise, by representation types that are of   a quantity character associated with a provided   quantity specification V.
        •  
       
      •  
    •  
      if V is of quantity_character type:
       
         
      • by representation types that are of a provided   quantity character.
        •  
       
      •  
    "},{"location":"users_guide/framework_basics/concepts/#Quantity","title":"Quantity<T>","text":"
    Quantity concept matches every quantity in the library and is satisfied by all types being or deriving from an instantiation of a quantity class template.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityOf","title":"QuantityOf<T, V>","text":"
    QuantityOf concept is satisfied by all the quantities for which a ReferenceOf<V> is true.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityLike","title":"QuantityLike<T>","text":"
    QuantityLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_like_traits type trait yields a valid type that provides:
     
       
    • reference static data member that matches the Reference concept,
      •  
    • rep type that matches RepresentationOf concept with the character provided   in reference,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     Examples 
    This is how support for std::chrono::seconds can be provided:
     
    template<>\nstruct mp_units::quantity_like_traits<std::chrono::seconds> {\n  static constexpr auto reference = si::second;\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = false;\n  using rep = std::chrono::seconds::rep;\n\n  [[nodiscard]] static constexpr rep to_numerical_value(const std::chrono::seconds& d)\n  {\n    return d.count();\n  }\n\n  [[nodiscard]] static constexpr std::chrono::seconds from_numerical_value(const rep& v)\n  {\n    return std::chrono::seconds(v);\n  }\n};\n\nquantity q = 42s;\nstd::chrono::seconds dur = 42 * s;\n
    "},{"location":"users_guide/framework_basics/concepts/#PointOrigin","title":"PointOrigin<T>","text":"
    PointOrigin concept matches all quantity point origins in the library. It is satisfied by either:
     
       
    • All types derived from an absolute_point_origin class template.
      •  
    • All types derived from a relative_point_origin class template.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#PointOriginFor","title":"PointOriginFor<T, V>","text":"
    PointOriginFor concept is satisfied by all PointOrigin types that have quantity type implicitly convertible from quantity specification V, which means that V must satisfy QuantitySpecOf<T::quantity_spec>.
     Examples 
    si::ice_point can serve as a point origin for points of isq::Celsius_temperature because this quantity type implicitly converts to isq::thermodynamic_temperature.
     
    However, if we define mean_sea_level in the following way:
     
    inline constexpr struct mean_sea_level final : absolute_point_origin<isq::altitude> {} mean_sea_level;\n
     
    then it can't be used as a point origin for points of isq::length or isq::width as none of them is implicitly convertible to isq::altitude:
     
       
    • not every length is an altitude,
      •  
    • width is not compatible with altitude.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#QuantityPoint","title":"QuantityPoint<T>","text":"
    QuantityPoint concept is satisfied by all types being either a specialization or derived from quantity_point class template.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityPointOf","title":"QuantityPointOf<T, V>","text":"
    QuantityPointOf concept is satisfied by all the quantity points T that match the following value V:
     V Condition QuantitySpec The quantity point quantity specification satisfies ReferenceOf<V> concept. PointOrigin The point and V have the same absolute point origin."},{"location":"users_guide/framework_basics/concepts/#QuantityPointLike","title":"QuantityPointLike<T>","text":"
    QuantityPointLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_point_like_traits type trait yields a valid type that provides:
     
       
    • reference static data member that matches the Reference concept.
      •  
    • point_origin static data member that matches the PointOrigin concept.
      •  
    • rep type that matches RepresentationOf concept with the character provided   in reference.
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity_point type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity_point type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity being the offset   of the point from the origin,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     Examples 
    This is how support for a std::chrono::time_point of std::chrono::seconds can be provided:
     
    template<typename C>\nstruct mp_units::quantity_point_like_traits<std::chrono::time_point<C, std::chrono::seconds>> {\n  static constexpr auto reference = si::second;\n  static constexpr struct point_origin_ final : absolute_point_origin<isq::time> {} point_origin{};\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = false;\n  using rep = std::chrono::seconds::rep;\n  using T = std::chrono::time_point<C, std::chrono::seconds>;\n\n  [[nodiscard]] static constexpr rep to_numerical_value(const T& tp)\n  {\n    return tp.time_since_epoch().count();\n  }\n\n  [[nodiscard]] static constexpr T from_numerical_value(const rep& v)\n  {\n    return T(std::chrono::seconds(v));\n  }\n};\n\nquantity_point qp = time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now());\nstd::chrono::sys_seconds q = qp + 42 * s;\n
    "},{"location":"users_guide/framework_basics/design_overview/","title":"Design Overview","text":"
    The most important entities in the mp-units library are:
     
       
    • quantity,
      •  
    • quantity point,
      •  
    • unit,
      •  
    • dimension,
      •  
    • quantity specification
      •  
    • quantity reference,
      •  
    • quantity representation.
      •  
     
    The graph provided below presents how those and a few other entities depend on each other:
     
    flowchart TD\n    Unit --- Reference\n    Dimension --- QuantitySpec[\"Quantity specification\"]\n    quantity_character[\"Quantity character\"] --- QuantitySpec\n    QuantitySpec --- Reference[\"Quantity reference\"]\n    Reference --- Quantity\n    quantity_character -.- Representation\n    Representation --- Quantity\n    Quantity --- QuantityPoint[\"Quantity point\"]\n    PointOrigin[\"Point origin\"] --- QuantityPoint\n\n    click Dimension \"#dimension\"\n    click quantity_character \"#quantity-character\"\n    click QuantitySpec \"#quantity-specification\"\n    click Unit \"#unit\"\n    click Reference \"#quantity-reference\"\n    click Representation \"#quantity-representation\"\n    click Quantity \"#quantity\"\n    click PointOrigin \"#point-origin\"\n    click QuantityPoint \"#quantity-point\"
    "},{"location":"users_guide/framework_basics/design_overview/#dimension","title":"Dimension","text":"
    Dimension specifies the dependence of a quantity on the base quantities of a particular system of quantities. It is represented as a product of powers of factors corresponding to the base quantities, omitting any numerical factor.
     
    In the mp-units library, we use the terms:
     
       
    • base dimension to refer to the dimension of a base quantity,
      •  
    • derived dimension to refer to the dimension of a derived quantity.
      •  
     
    For example:
     
       
    • length (\\(\\mathsf{L}\\)), mass (\\(\\mathsf{M}\\)), time (\\(\\mathsf{T}\\)), electric current (\\(\\mathsf{I}\\)),   thermodynamic temperature (\\(\\mathsf{\u0398}\\)), amount of substance (\\(\\mathsf{N}\\)), and   luminous intensity (\\(\\mathsf{J}\\)) are the base dimensions of the ISQ.
      •  
    • A derived dimension of force in the ISQ is denoted by   \\(\\textsf{dim }F = \\mathsf{LMT}^{\u20132}\\).
      •  
    • The implementation of IEC 80000 in this library provides iec::dim_traffic_intensity   base dimension to extend ISQ with strong information technology quantities.
      •  
     
    Base dimensions can be defined by the user in the following way:
     
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\n
     
    Derived dimensions are implicitly created by the library's framework based on the quantity equation provided in the quantity specification:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct time final : quantity_spec<dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct time final : quantity_spec<time, dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(time, dim_time);\nQUANTITY_SPEC(speed, length / time);\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    Important
     
    Users should not explicitly define any derived dimensions. Those should always be implicitly created by the framework.
     
    The multiplication/division on quantity specifications also multiplies/divides their dimensions:
     
    static_assert((length / time).dimension == dim_length / dim_time);\n
     
    The dimension equation of isq::dim_length / isq::dim_time results in the derived_dimension<isq::dim_length, per<isq::dim_time>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-character","title":"Quantity character","text":"
    ISO 80000 explicitly states that quantities (even of the same kind) may have different characters:
     
       
    • real scalar (e.g., time, width, speed, apparent power),
      •  
    • complex scalar (e.g., voltage phasor, complex power, impedance),
      •  
    • vector (e.g., displacement, velocity, force),
      •  
    • tensor (e.g., moment of inertia, stress, strain).
      •  
     
    The quantity character in the mp-units library is implemented with the quantity_character enumeration:
     
    enum class quantity_character { real_scalar, complex_scalar, vector, tensor };\n
     
    Info
     
    You can read more on quantity characters in the \"Character of a Quantity\" chapter.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-specification","title":"Quantity specification","text":"
    Dimension is not enough to describe a quantity. This is why the ISO 80000 provides hundreds of named quantity types. It turns out that there are many more quantity types in the ISQ than the named units in the SI.
     
    This is why the mp-units library introduces a quantity specification entity that stores:
     
       
    • dimension,
      •  
    • quantity type/name,
      •  
    • quantity character,
      •  
    • the quantity equation being the recipe to create this quantity   (only for derived quantities that specify such a recipe).
      •  
     
    Note
     
    We know that it might be sometimes confusing to talk about quantities, quantity types/names, and quantity specifications. However, it might be important to notice here that even the ISO 80000 admits that:
     
    It is customary to use the same term, \"quantity\", to refer to both general quantities, such as length, mass, etc., and their instances, such as given lengths, given masses, etc. Accordingly, we are used to saying both that length is a quantity and that a given length is a quantity by maintaining the specification \u2013 \"general quantity, \\(Q\\)\" or \"individual quantity, \\(Q_\\textsf{a}\\)\" \u2013 implicit and exploiting the linguistic context to remove the ambiguity.
     
    In the mp-units library, we have a:
     
       
    • quantity - implemented as a quantity class template,
      •  
    • quantity specification - implemented with a quantity_spec class template that among others identifies   a specific quantity type/name.
      •  
     
    For example:
     
       
    • isq::length, isq::mass, isq::time, isq::electric_current, isq::thermodynamic_temperature,   isq::amount_of_substance, and isq::luminous_intensity are the specifications of base quantities   in the ISQ.
      •  
    • isq::width, isq::height, isq::radius, and isq::position_vector are only a few of many    quantities of a kind length specified in the ISQ.
      •  
    • isq::area, isq::speed, isq::moment_of_force are only a few of many derived quantities provided   in the ISQ.
      •  
     
    Quantity specification  can be defined by the user in one of the following ways:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(height, length);\nQUANTITY_SPEC(speed, length / time);\n
     
    The quantity equation of isq::length / isq::time results in the derived_quantity_spec<isq::length, per<isq::time>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#unit","title":"Unit","text":"
    A unit is a concrete amount of a quantity that allows us to measure the values of quantities of the same kind and represent the result as a number being the ratio of the two quantities.
     
    For example:
     
       
    • si::second, si::metre, si::kilogram, si::ampere, si::kelvin, si::mole, and si::candela   are the base units of the SI.
      •  
    • si::kilo<si::metre> is a prefixed unit of length.
      •  
    • si::radian, si::newton, and si::watt are examples of named derived units within the   SI.
      •  
    • non_si::minute is an example of a scaled unit of time.
      •  
    • si::si2019::speed_of_light_in_vacuum is a physical constant standardized by the SI in 2019.
      •  
     
    Note
     
    In the mp-units library, physical constants are also implemented as units.
     
    A unit can be defined by the user in one of the following ways:
     
    template<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr kilo_<decltype(U)> kilo;\n\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct minute final : named_unit<\"min\", mag<60> * second> {} minute;\ninline constexpr struct gram   final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\n\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n
     
    The unit equation of si::metre / si::second results in the derived_unit<si::metre, per<si::second>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-reference","title":"Quantity reference","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    After that, it says:
     
    Quote
     
    A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
     
    In the mp-units library, a quantity reference provides all the domain-specific metadata for the quantity besides its numerical value:
     
       
    • all the data stored in the quantity specification,
      •  
    • unit.
      •  
     
    Together with the value of a representation type, it forms a quantity.
     
    In the library, we have two different ways to provide a reference:
     
       
    • every unit with the associated quantity kind   is a valid reference,
      •  
    • providing a unit to an indexing operator of a quantity specification explicitly instantiates   a reference class template with this quantity spec and a unit passed as arguments.
      •  
     
    Note
     
    All the units of the SI have associated quantity kinds and may serve as a reference.
     
    For example:
     
       
    • si::metre is defined in the SI as a unit of isq::length   and thus can be used as a reference to instantiate a quantity of length (e.g., 42 * m).
      •  
    • The expression isq::height[m] results with reference<isq::height, si::metre>, which can be used to   instantiate a quantity of isq::height with a unit of si::metre (e.g., 42 * isq::height[m]).
      •  
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-representation","title":"Quantity representation","text":"
    Quantity representation defines the type used to store the numerical value of a quantity. Such a type should be of a specific quantity character provided in the quantity specification.
     
    Note
     
    By default, all floating-point and integral (besides bool) types are treated as scalars.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity","title":"Quantity","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    This is why a quantity class template is defined in the library as:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    Its value can be easily created by multiplying/dividing the numerical value and a reference.
     
    For example:
     
       
    • All of 42 * m, 42 * si::metre, 42 * isq::height[m], and isq::height(42 * m) create a quantity.
      •  
    • A quantity type can also be specified explicitly (e.g., quantity<si::metre, int>,   quantity<isq::height[m]>).
      •  
    "},{"location":"users_guide/framework_basics/design_overview/#point-origin","title":"Point origin","text":"
    In the affine space theory, the point origin specifies where the \"zero\" of our measurement's scale is.
     
    In the mp-units library, we have two types of point origins:
     
       
    • absolute - defines an absolute \"zero\" for our point,
      •  
    • relative - defines an origin that has some \"offset\" relative   to an absolute point.
      •  
     
    For example:
     
       
    • the absolute point origin can be defined in the following way:
      •  
     
    inline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\n
     
       
    • the relative point origin can be defined in the following way:
      •  
     
    inline constexpr struct ice_point final : relative_point_origin<absolute_zero + 273'150 * milli<kelvin>> {} ice_point;\n
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-point","title":"Quantity point","text":"
    Quantity point implements a point in the affine space theory.
     
    In the mp-units library, the quantity point is implemented as:
     
    template<Reference auto R,\n         PointOriginFor<get_quantity_spec(R)> auto PO,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity_point;\n
     
    Its value can be easily created by adding/subtracting the quantity with a point origin.
     
    For example:
     
       
    • The following specifies a quantity point defined in terms of an ice_point provided in   the previous example:
      •  
     
    constexpr auto room_reference_temperature = ice_point + delta<isq::Celsius_temperature[deg_C]>(21);\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/","title":"Dimensionless Quantities","text":"
    The quantities we discussed so far always had some specific type and physical dimension. However, this is not always the case. While performing various computations, we sometimes end up with so-called \"dimensionless\" quantities, which ISO defines as quantities of dimension one:
     
    ISO/IEC Guide 99
     
       
    • Quantity for which all the exponents of the factors corresponding to the base quantities in   its quantity dimension are zero.
      •  
    • The measurement units and values of quantities of dimension one are numbers, but such quantities   convey more information than a number.
      •  
    • Some quantities of dimension one are defined as the ratios of two quantities of the same kind.
      •  
    • Numbers of entities are quantities of dimension one.
      •  
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-two-quantities-of-the-same-kind","title":"Dividing two quantities of the same kind","text":"
    Dividing two quantities of the same kind always results in a quantity of dimension one. However, depending on what type of quantities we divide or what their units are, we may end up with slightly different results.
     
    Note
     
    In mp-units, dividing two quantities of the same dimension always results in a quantity with the dimension being dimension_one. This is often different for other physical units libraries, which may return a raw representation type for such cases. A raw value is also always returned from the division of two std::chrono::duration objects.
     
    To read more about the reasoning for this design decision, please check our FAQ.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-the-same-type","title":"Dividing quantities of the same type","text":"
    First, let's analyze what happens if we divide two quantities of the same type:
     
    constexpr QuantityOf<dimensionless> auto q = isq::height(200 * m) / isq::height(50 * m);\n
     
    In such a case, we end up with a dimensionless quantity that has the following properties:
     
    static_assert(q.quantity_spec == dimensionless);\nstatic_assert(q.dimension == dimension_one);\nstatic_assert(q.unit == one);\n
     
    In case we would like to print its value, we would see a raw value of 4 in the output with no unit being printed.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-different-types","title":"Dividing quantities of different types","text":"
    Now let's see what happens if we divide quantities of the same dimension and unit but which have different quantity types:
     
    constexpr QuantityOf<dimensionless> auto q = isq::work(200 * J) / isq::heat(50 * J);\n
     
    Again we end up with dimension_one and one, but this time:
     
    static_assert(q.quantity_spec == isq::work / isq::heat);\n
     
    As shown above, the result is not of a dimensionless type anymore. Instead, we get a quantity type derived from the performed quantity equation. According to the ISQ, work divided by heat is the recipe for the thermodynamic efficiency quantity, thus:
     
    static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));\n
     
    Note
     
    The quantity of isq::efficiency_thermodynamics is of a kind dimensionless, so it is implicitly convertible to dimensionless and satisfies the QuantityOf<dimensionless> concept.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-different-units","title":"Dividing quantities of different units","text":"
    Now, let's see what happens when we divide two quantities of the same type but different units:
     
    constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);\n
     
    This time, we still get a quantity of the dimensionless type with a dimension_one as its dimension. However, the resulting unit is not one anymore:
     
    static_assert(q.unit == mag_power<10, 3> * one);\n
     
    In case we would print the text output of this quantity, we would not see a raw value of 2000, but 2 km/m.
     
    First, it may look surprising, but this is consistent with dividing quantities of different dimensions. For example, if we divide 4 * km / 2 * s, we do not expect km to be \"expanded\" to m before the division, right? We would expect the result of 2 km/s, which is exactly what we get when we divide quantities of the same kind.
     
    This is a compelling feature that allows us to express huge or tiny ratios without the need for big and expensive representation types. With this, we can easily define things like a Hubble's constant that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both units of length:
     
    inline constexpr struct hubble_constant final :\n    named_unit<{u8\"H\u2080\", \"H_0\"}, mag_ratio<701, 10> * si::kilo<si::metre> / si::second / si::mega<parsec>> {} hubble_constant;\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#counts-of-things","title":"Counts of things","text":"
    Another important use case for dimensionless quantities is to provide strong types for counts of things. For example:
     
       
    • ISO-80000-3 provides a rotation quantity defined as the number of revolutions,
      •  
    • IEC-80000-6 provides a number of turns in a winding quantity,
      •  
    • IEC-80000-13 provides a Hamming distance quantity defined as the number of digit positions   in which the corresponding digits of two words of the same length are different.
      •  
     
    Thanks to assigning strong names to such quantities, later on, they can be explicitly used as arguments in the quantity equations of other quantities deriving from them.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#predefined-units-of-the-dimensionless-quantity","title":"Predefined units of the dimensionless quantity","text":"
    As we observed above, the most common unit for dimensionless quantities is one. It has the ratio of 1 and does not output any textual symbol.
     
    Important: one is an identity
     
    A unit one is special in the entire type system of units as it is considered to be an identity operand in the unit symbolic expressions. This means that, for example:
     
    static_assert(one * one == one);\nstatic_assert(one * si::metre == si::metre);\nstatic_assert(si::metre / si::metre == one);\n
     
    The same is also true for dimension_one and dimensionless in the domains of dimensions and quantity specifications.
     
    Besides the unit one, there are a few other scaled units predefined in the library for usage with dimensionless quantities:
     
    inline constexpr struct percent final : named_unit<\"%\", mag_ratio<1, 100> * one> {} percent;\ninline constexpr struct per_mille final : named_unit<{u8\"\u2030\", \"%o\"}, mag_ratio<1, 1000> * one> {} per_mille;\ninline constexpr struct parts_per_million final : named_unit<\"ppm\", mag_ratio<1, 1'000'000> * one> {} parts_per_million;\ninline constexpr auto ppm = parts_per_million;\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#superpowers-of-the-unit-one","title":"Superpowers of the unit one","text":"
    Quantities implicitly convertible to dimensionless with the unit equivalent to one are the only ones that are:
     
       
    • implicitly constructible from the raw value,
      •  
    • explicitly convertible to a raw value,
      •  
    • comparable to a raw value.
      •  
     
    quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n  legacy(static_cast<int>(q));\n
     
    This property also expands to usual arithmetic operators.
     
    Note
     
    Those rules do not apply to all the dimensionless quantities. It would be unsafe and misleading to allow such operations on units with a magnitude different than 1 (e.g., percent) or for quantities that are not implicitly convertible to dimensionless (e.g., angular_measure).
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#angular-quantities","title":"Angular quantities","text":"
    Special, often controversial, examples of dimensionless quantities are an angular measure and solid angular measure quantities that are defined in the ISQ to be the result of a division of \\(arc\\; length / radius\\) and \\(area / radius^2\\) respectively. Moreover, ISQ also explicitly states that both can be expressed in the unit one. This means that both angular measure and solid angular measure should be of a kind dimensionless.
     
    On the other hand, ISQ also specifies that a unit radian can be used for angular measure, and a unit steradian can be used for solid angular measure. Those should not be mixed or used to express other types of dimensionless quantities. This means that both angular measure and solid angular measure should also be quantity kinds by themselves.
     
    Note
     
    Many people claim that angle being a dimensionless quantity is a bad idea. There are proposals submitted to make an angle a base quantity and rad to become a base unit. More on this topic can be found in the \"Strong Angular System\" chapter.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#radians-and-degrees-support","title":"Radians and degrees support","text":"
    Thanks to the usage of magnitudes the library provides efficient strong types for all angular types. This means that with the built-in support for magnitudes of \\(\\pi\\) we can provide accurate conversions between radians and degrees. The library also provides common trigonometric functions for angular quantities:
     
    using namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::rad;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::grad;\n\nquantity speed = 110 * km / h;\nquantity rate_of_climb = -0.63657 * m / s;\nquantity glide_ratio = speed / -rate_of_climb;\nquantity glide_angle = angular::asin(1 / glide_ratio);\n\nstd::println(\"Glide ratio: {::N[.1f]}\", glide_ratio.in(one));\nstd::println(\"Glide angle:\");\nstd::println(\" - {::N[.4f]}\", glide_angle.in(rad));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(deg));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(grad));\n
     
    The above program prints:
     
    Glide ratio: 48.0\nGlide angle:\n - 0.0208 rad\n - 1.19\u00b0\n - 1.33\u1d4d\n
     
    Note
     
    In the production code the above speed and rate_of_climb quantities should probably be modelled as separate typed quantities of the same kind.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#nested-quantity-kinds","title":"Nested quantity kinds","text":"
    Angular quantities are not the only ones with such a \"strange\" behavior. Another but a similar case is a storage capacity quantity specified in IEC-80000-13 that again allows expressing it in both one and bit units.
     
    Those cases make dimensionless quantities an exceptional tree in the library. This quantity hierarchy contains more than one quantity kind and more than one unit in its tree:
     
    flowchart TD\n    dimensionless[\"<b>dimensionless</b><br>[one]\"]\n    dimensionless --- rotation[\"<b>rotation</b>\"]\n    dimensionless --- thermodynamic_efficiency[\"<b>thermodynamic_efficiency</b><br><i>(work / heat)</i>\"]\n    dimensionless --- angular_measure[\"<b>angular_measure</b><br><i>(arc_length / radius)</i><br>[rad]\"]\n    angular_measure --- rotational_displacement[\"<b>rotational_displacement</b><br><i>(path_length / radius)</i>\"]\n    angular_measure --- phase_angle[\"<b>phase_angle</b>\"]\n    dimensionless --- solid_angular_measure[\"<b>solid_angular_measure</b><br><i>(area / pow<2>(radius))</i><br>[sr]\"]\n    dimensionless --- drag_factor[\"<b>drag_factor</b><br><i>(drag_force / (mass_density * pow<2>(speed) * area))</i>\"]\n    dimensionless --- storage_capacity[\"<b>storage_capacity</b><br>[bit]\"] --- equivalent_binary_storage_capacity[\"<b>equivalent_binary_storage_capacity</b>\"]\n    dimensionless --- ...
     
    To provide such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
     C++23C++20Portable 
    inline constexpr struct angular_measure final : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<dimensionless, is_kind> {} storage_capacity;\n
     
    inline constexpr struct angular_measure final : quantity_spec<angular_measure, dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<storage_capacity, dimensionless, is_kind> {} storage_capacity;\n
     
    QUANTITY_SPEC(angular_measure, dimensionless, arc_length / radius, is_kind);\nQUANTITY_SPEC(solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind);\nQUANTITY_SPEC(storage_capacity, dimensionless, is_kind);\n
     
    With the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
     
    inline constexpr struct radian final : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\n
     
    but still allow the usage of one and its scaled versions for such quantities.
     
    Info
     
    It is worth mentioning here that converting up the hierarchy beyond a subkind requires an explicit conversion. For example:
     
    static_assert(implicitly_convertible(isq::rotation, dimensionless));\nstatic_assert(!implicitly_convertible(isq::angular_measure, dimensionless));\nstatic_assert(explicitly_convertible(isq::angular_measure, dimensionless));\n
     
    This increases type safety and prevents accidental quantities with invalid units. For example, a result of a conversion from isq::angular_measure[rad] to dimensionless would be a reference of dimensionless[rad], which contains an incorrect unit for a dimensionless quantity. Such a conversion must be explicit and be preceded by an explicit unit conversion:
     
    quantity q1 = isq::angular_measure(42. * rad);\nquantity<dimensionless[one]> q2 = dimensionless(q1.in(one));\n
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/","title":"Faster-than-lightspeed Constants","text":"
    In most libraries, physical constants are implemented as constant (possibly constexpr) quantity values. Such an approach has some disadvantages, often affecting the run time performance and causing a loss of precision.
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#simplifying-constants-in-an-equation","title":"Simplifying constants in an equation","text":"
    When dealing with equations involving physical constants, they often occur more than once in an expression. Such a constant may appear both in a numerator and denominator of a quantity equation. As we know from fundamental physics, we can simplify such an expression by striking a constant out of the equation. Supporting such behavior allows a faster runtime performance and often a better precision of the resulting value.
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#physical-constants-as-units","title":"Physical constants as units","text":"
    The mp-units library allows and encourages the implementation of physical constants as regular units. With that, the constant's value is handled at compile-time, and under favorable circumstances, it can be simplified in the same way as all other repeated units do. If it is not simplified, the value is stored in a type, and the expensive multiplication or division operations can be delayed in time until a user selects a specific unit to represent/print the data.
     
    Such a feature often also allows using simpler or faster representation types in the equation. For example, instead of always having to multiply a small integral value with a big floating-point constant number, we can just use the integral type all the way. Only in case a constant will not simplify in the equation, and the user will require a specific unit, such a multiplication will be lazily invoked, and the representation type will need to be expanded to facilitate that. With that, addition, subtractions, multiplications, and divisions will always be the fastest - compiled away or done in out-of-order execution.
     
    To benefit from all of the above, in the mp-units library, SI defining and other constants are implemented as units in the following way:
     
    namespace si {\n\nnamespace si2019 {\n\ninline constexpr struct speed_of_light_in_vacuum final :\n  named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n\n}  // namespace si2019\n\ninline constexpr struct magnetic_constant final :\n  named_unit<{u8\"\u03bc\u2080\", \"u_0\"}, mag<4> * mag<\u03c0> * mag_power<10, -7> * henry / metre> {} magnetic_constant;\n\n}  // namespace mp_units::si\n
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#usage-examples","title":"Usage examples","text":"
    With the above definitions, we can calculate vacuum permittivity as:
     
    constexpr auto permeability_of_vacuum = 1. * si::magnetic_constant;\nconstexpr auto speed_of_light_in_vacuum = 1 * si::si2019::speed_of_light_in_vacuum;\n\nQuantityOf<isq::permittivity_of_vacuum> auto q = 1 / (permeability_of_vacuum * pow<2>(speed_of_light_in_vacuum));\n\nstd::println(\"permittivity of vacuum = {} = {::N[.3e]}\", q, q.in(F / m));\n
     
    The above first prints the following:
     
    permittivity of vacuum = 1  \u03bc\u2080\u207b\u00b9 c\u207b\u00b2 = 8.854e-12 F/m\n
     
    As we can clearly see, all the calculations above were just about multiplying and dividing the number 1 with the rest of the information provided as a compile-time type. Only when a user wants a specific SI unit as a result, the unit ratios are lazily resolved.
     
    Another similar example can be an equation for total energy:
     
    QuantityOf<isq::mechanical_energy> auto total_energy(QuantityOf<isq::momentum> auto p,\n                                                     QuantityOf<isq::mass> auto m,\n                                                     QuantityOf<isq::speed> auto c)\n{\n  return isq::mechanical_energy(sqrt(pow<2>(p * c) + pow<2>(m * pow<2>(c))));\n}\n
     
    constexpr auto GeV = si::giga<si::electronvolt>;\nconstexpr QuantityOf<isq::speed> auto c = 1. * si::si2019::speed_of_light_in_vacuum;\nconstexpr auto c2 = pow<2>(c);\n\nconst auto p1 = isq::momentum(4. * GeV / c);\nconst QuantityOf<isq::mass> auto m1 = 3. * GeV / c2;\nconst auto E = total_energy(p1, m1, c);\n\nstd::cout << \"in `GeV` and `c`:\\n\"\n          << \"p = \" << p1 << \"\\n\"\n          << \"m = \" << m1 << \"\\n\"\n          << \"E = \" << E << \"\\n\";\n\nconst auto p2 = p1.in(GeV / (m / s));\nconst auto m2 = m1.in(GeV / pow<2>(m / s));\nconst auto E2 = total_energy(p2, m2, c).in(GeV);\n\nstd::cout << \"\\nin `GeV`:\\n\"\n          << \"p = \" << p2 << \"\\n\"\n          << \"m = \" << m2 << \"\\n\"\n          << \"E = \" << E2 << \"\\n\";\n\nconst auto p3 = p1.in(kg * m / s);\nconst auto m3 = m1.in(kg);\nconst auto E3 = total_energy(p3, m3, c).in(J);\n\nstd::cout << \"\\nin SI base units:\\n\"\n          << \"p = \" << p3 << \"\\n\"\n          << \"m = \" << m3 << \"\\n\"\n          << \"E = \" << E3 << \"\\n\";\n
     
    The above prints the following:
     
    in `GeV` and `c`:\np = 4 GeV/c\nm = 3 GeV/c\u00b2\nE = 5 GeV\n\nin `GeV`:\np = 1.33426e-08 GeV s/m\nm = 3.33795e-17 GeV s\u00b2/m\u00b2\nE = 5 GeV\n\nin SI base units:\np = 2.13771e-18 kg m/s\nm = 5.34799e-27 kg\nE = 8.01088e-10 J\n
    "},{"location":"users_guide/framework_basics/generic_interfaces/","title":"Generic Interfaces","text":"
    Using a concrete unit in the interface often makes a lot of sense. It is especially useful if we store the data internally in the object. In such a case, we have to select a specific unit anyway.
     
    For example, let's consider a simple storage tank:
     
    class StorageTank {\n  quantity<horizontal_area[m2]> base_;\n  quantity<isq::height[m]> height_;\n  quantity<isq::mass_density[kg / m3]> density_ = air_density;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[m2]>& base, const quantity<isq::height[m]>& height) :\n      base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n
     
    As the quantities provided in the function's interface are then stored in the class, there is probably no sense in using generic interfaces here.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#the-issues-with-unit-specific-interfaces","title":"The issues with unit-specific interfaces","text":"
    However, in many cases, using a specific unit in the interface is counterproductive. Let's consider the following function:
     
    quantity<km / h> avg_speed(quantity<km> distance, quantity<h> duration)\n{\n  return distance / duration;\n}\n
     
    Everything seems fine for now. It also works great if we call it with:
     
    quantity<km / h> s1 = avg_speed(220 * km, 2 * h);\n
     
    However, if the user starts doing the following:
     
    quantity<mi / h> s2 = avg_speed(140 * mi, 2 * h);\nquantity<m / s> s3 = avg_speed(20 * m, 2 * s);\n
     
    some issues start to be clearly visible:
     
       
    1. The arguments must be converted to units mandated by the function's parameters at each call.    This involves potentially expensive multiplication/division operations at runtime.
      2.  
    2. After the function returns the speed in a unit of km/h, another potentially expensive    multiplication/division operations must be performed to convert the resulting quantity into    a unit being the derived unit of the initial function's arguments.
      3.  
    3. Besides the obvious runtime cost, some unit conversions may result in a value truncation, which    means that the result will not be exactly equal to a direct division of the function's arguments.
      4.  
    4.  
      We have to use a floating-point representation type (the quantity class template by default uses    double as a representation type) which is considered    value-preserving.    Trying to use an integral type in this scenario will work only for s1, while s2 and s3    will fail to compile. Failing to compile is a good thing here as the library tries to prevent    the user from doing a clearly wrong thing. To make the code compile, the user needs to use    dedicated value_cast or force_in like this:
       
      quantity<isq::speed[mi / h]> s2 = avg_speed(value_cast<km>(140 * mi), 2 * h);\nquantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));\n
       
      but the above will obviously provide an incorrect behavior (e.g., division by 0 in the evaluation of s3).
       
      5.  
    "},{"location":"users_guide/framework_basics/generic_interfaces/#a-naive-solution","title":"A naive solution","text":"
    A naive solution here would be to implement the function as an unconstrained function template:
     
    auto avg_speed(auto distance, auto duration)\n{\n  return distance / duration;\n}\n
     
    Beware, this is not a good solution. The above code is too generic. Such a function template accepts everything:
     
       
    • quantities of other types
         
      • the compiler will not prevent accidental reordering of the function's arguments,
        •  
      • quantities of different types can be passed as well,
        •  
       
      •  
    • plain double arguments,
      •  
    • std::vector and std::lock_guard will be accepted as well (of course, this will fail in the   instantiation of a function's body later in the compilation process).
      •  
     
    Note
     
    The usage of auto instead of a function parameter type is a C++20 feature. It makes such a code a function template where the type of such a parameter will be deduced during the template instantiation process from the argument type passed by the user.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-arguments-with-concepts","title":"Constraining function template arguments with concepts","text":"
    Much better generic code can be implemented using basic concepts provided with the library:
     Original template notationThe shorthand notationTerse notation 
    template<typename Distance, typename Duration>\n  requires QuantityOf<Distance, isq::length> && QuantityOf<Duration, isq::time>\nauto avg_speed(Distance distance, Duration duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    template<QuantityOf<isq::length> Distance, QuantityOf<isq::time> Duration>\nauto avg_speed(Distance distance, Duration duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    auto avg_speed(QuantityOf<isq::length> auto distance,\n               QuantityOf<isq::time> auto duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    This explicitly states that the arguments passed by the user must not only satisfy a Quantity concept, but also their quantity specification must be implicitly convertible to isq::length and isq::time accordingly. This no longer leaves room for error while still allowing the compiler to generate the most efficient code.
     
    Tip
     
    Please note that now it is safe just to use integral types all the way which again improves the runtime performance as the multiplication/division operations are often faster on the integral rather than floating-point types.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-return-type","title":"Constraining function template return type","text":"
    The above function template resolves all of the issues described before. However, we can do even better here by additionally constraining the return type:
     
    QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto distance,\n                                      QuantityOf<isq::time> auto duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    Doing so has two important benefits:
     
       
    1. It informs the users of our interface about what to expect to be the result of a function    invocation. It is superior to just returning auto, which does not provide any hint about    the thing being returned there.
      2.  
    2. Such a concept constrains the type returned from the function. This means that it works as    a unit test to verify if our function actually performs what it is supposed to do. If there is    an error in quantity equations, we will learn    about it right away.
      3.  
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-a-variable-on-the-stack","title":"Constraining a variable on the stack","text":"
    If we know precisely what the function does in its internals and if we know the exact argument types passed to such a function, we often know the exact type that will be returned from its invocation.
     
    However, if we care about performance, we should often use the generic interfaces described in this chapter. A side effect is that we sometimes are unsure about the return type. Even if we know it today, it might change a week from now due to some code refactoring.
     
    In such cases, we can again use auto to denote the type:
     
    auto s1 = avg_speed(220 * km, 2 * h);\nauto s2 = avg_speed(140 * mi, 2 * h);\nauto s3 = avg_speed(20 * m, 2 * s);\n
     
    or benefit from CTAD:
     
    quantity s1 = avg_speed(220 * km, 2 * h);\nquantity s2 = avg_speed(140 * mi, 2 * h);\nquantity s3 = avg_speed(20 * m, 2 * s);\n
     
    In both cases, it is probably OK to do so as the avg_speed function name explicitly provides the information on what to expect as a result.
     
    In other scenarios where the returned quantity type is not so obvious, it is again helpful to constrain the type with a concept like so:
     
    QuantityOf<isq::speed> auto s1 = avg_speed(220 * km, 2 * h);\nQuantityOf<isq::speed> auto s2 = avg_speed(140 * mi, 2 * h);\nQuantityOf<isq::speed> auto s3 = avg_speed(20 * m, 2 * s);\n
     
    The above explicitly provides additional information about the quantity we are dealing with in the code, and it serves as a unit test checking if the \"thing\" returned from a function is actually what we expected here.
     
    Note
     
    The QuantityOf and QuantityPointOf concepts are probably the most useful, but there are a few more to play with. A list of all the concepts can be found in the Basic Concepts chapter.
    "},{"location":"users_guide/framework_basics/interface_introduction/","title":"Interface Introduction","text":""},{"location":"users_guide/framework_basics/interface_introduction/#new-style-of-definitions","title":"New style of definitions","text":"
    The mp-units library decided to use a rather unusual pattern to define entities. Here is how we define metre and second SI base units:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\n
     
    Please note that the above reuses the same identifier for a type and its value. The rationale behind this is that:
     
       
    • Users always work with values and never have to spell such a type name.
      •  
    • The types appear in the compilation errors and during debugging.
      •  
     
    Important
     
    To improve compiler errors' readability and make it easier to correlate them with a user's written code, a new idiom in the library is to use the same identifier for a type and its instance.
     
    Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent symbolic expressions simplification of equivalent entities.
    "},{"location":"users_guide/framework_basics/interface_introduction/#strong-types-instead-of-aliases","title":"Strong types instead of aliases","text":"
    Let's look again at the above units definitions. Another important point to notice is that all the types describing entities in the library are short, nicely named identifiers that derive from longer, more verbose class template instantiations. This is really important to improve the user experience while debugging the program or analyzing the compilation error.
     
    Note
     
    Such a practice is rare in the industry. Some popular C++ physical units libraries generate enormously long error messages where even only the first line failed to fit on a slide with a tiny font.
    "},{"location":"users_guide/framework_basics/interface_introduction/#entities-composability","title":"Entities composability","text":"
    Many physical units libraries (in C++ or any other programming language) assign strong types to library entities (e.g., derived units). While metre_per_second as a type may not look too scary, consider, for example, units of angular momentum. If we followed this path, its coherent unit would look like kilogram_metre_sq_per_second. Now, consider how many scaled versions of this unit you would predefine in the library to ensure that all users are happy with your choice? How expensive would it be from the implementation point of view? What about potential future standardization efforts?
     
    This is why in mp-units, we put a strong requirement to make everything as composable as possible. For example, to create a quantity with a unit of speed, one may write:
     
    quantity<si::metre / si::second> q;\n
     
    In case we use such a unit often and would prefer to have a handy helper for it, we can always do something like this:
     
    constexpr auto metre_per_second = si::metre / si::second;\nquantity<metre_per_second> q;\n
     
    or choose any shorter identifier of our choice.
     
    Coming back to the angular momentum case, thanks to the composability of units, a user can create such a quantity in the following way:
     
    using namespace mp_units::si::unit_symbols;\nauto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];\n
     
    It is a much better solution. It is terse and easy to understand. Please also notice how easy it is to obtain any scaled version of such a unit (e.g., mg * square(mm) / min) without having to introduce hundreds of types to predefine them.
    "},{"location":"users_guide/framework_basics/interface_introduction/#value-based-equations","title":"Value-based equations","text":"
    The mp-units library is based on C++20, significantly improving user experience. One of such improvements is the usage of value-based equations.
     
    As we have learned above, the entities are being used as values in the code, and they compose. Moreover, derived entities can be defined in the library using such value-based equations. This is a huge improvement compared to what we can find in other physical units libraries or what we have to deal with when we want to write some equations for std::ratio.
     
    For example, below are a few definitions of the SI derived units showing the power of C++20 extensions to Non-Type Template Parameters, which allow us to directly pass a result of the value-based unit equation to a class template definition:
     
    inline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct pascal final : named_unit<\"Pa\", newton / square(metre)> {} pascal;\ninline constexpr struct joule  final : named_unit<\"J\", newton * metre> {} joule;\n
    "},{"location":"users_guide/framework_basics/interface_introduction/#symbolic-expressions","title":"Symbolic expressions","text":"
    The previous chapter provided a rationale for not having predefined types for derived entities. In many libraries, such an approach results in long and unreadable compilation errors, as framework-generated types are typically far from being easy to read and understand.
     
    The mp-units library greatly improves the user experience by extensively using symbolic expressions. Such expressions are used consistently throughout the entire library to describe the results of:
     
       
    • dimension equation - the result is put into   the derived_dimension<> class template
      •  
    • quantity equation - the result is put into   the derived_quantity_spec<> class template
      •  
    • unit equation - the result is put into the   derived_unit<> class template
      •  
     
    For example, if we take the above-defined base units and put the results of their division into the quantity class template like this:
     
    quantity<metre / second> q;\n
     
    we will observe the following type in the debugger
     
    (gdb) ptype q\ntype = class mp_units::quantity<mp_units::derived_unit<metre, mp_units::per<second>>(), double> [with Rep = double] {\n
     
    The same type identifier will be visible in the compilation error (in case it happens).
     
    Important
     
    Expressions templates are extensively used throughout the library to improve the readability of the resulting types.
    "},{"location":"users_guide/framework_basics/interface_introduction/#identities","title":"Identities","text":"
    As mentioned above, equations can be performed on dimensions, quantities, and units. Each such domain must introduce an identity object that can be used in the resulting expressions. Here is the list of identities used in the library:
     Domain Concept Identity Dimension dimension_one QuantitySpec dimensionless Unit one 
    In the equations, a user can explicitly refer to an identity object. For example:
     
    constexpr auto my_unit = one / second;\n
     
    Note
     
    Another way to achieve the same result is to call an inverse() function:
     
    constexpr auto my_unit = inverse(second);\n
     
    Both cases will result in the same symbolic expression being generated and put into the wrapper class template.
    "},{"location":"users_guide/framework_basics/interface_introduction/#supported-operations-and-their-results","title":"Supported operations and their results","text":"
    There are only a few operations that one can do on such entities, and the result of each of them has its unique representation in the library:
     Operation Resulting template expression arguments A * B A, B B * A A, B A * A power<A, 2> {identity} * A A A * {identity} A A / B A, per<B> A / A {identity} A / {identity} A {identity} / A {identity}, per<A> pow<2>(A) power<A, 2> pow<2>({identity}) {identity} sqrt(A) or pow<1, 2>(A) power<A, 1, 2> sqrt({identity}) or pow<1, 2>({identity}) {identity}"},{"location":"users_guide/framework_basics/interface_introduction/#simplifying-the-resulting-symbolic-expressions","title":"Simplifying the resulting symbolic expressions","text":"
    To limit the length and improve the readability of generated types, there are many rules to simplify the resulting symbolic expression.
     
       
    1.  
      Ordering
       
      The resulting comma-separated arguments of multiplication are always sorted according to a specific predicate. This is why:
       
      static_assert(A * B == B * A);\nstatic_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);\n
       
      This is probably the most important of all the steps, as it allows comparing types and enables the rest of the simplification rules.
       
      2.  
    2.  
      Aggregation
       
      In case two of the same identifiers are found next to each other on the argument list they will be aggregated in one entry:
       Before After A, A power<A, 2> A, power<A, 2> power<A, 3> power<A, 1, 2>, power<A, 2> power<A, 5, 2> power<A, 1, 2>, power<A, 1, 2> A 
      3.  
    3.  
      Simplification
       
      In case two of the same identifiers are found in the numerator and denominator argument lists; they are being simplified into one entry:
       Before After A, per<A> {identity} power<A, 2>, per<A> A power<A, 3>, per<A> power<A, 2> A, per<power<A, 2>> {identity}, per<A> 
      It is important to notice here that only the elements with exactly the same type are being simplified. This means that, for example, m/m results in one, but km/m will not be simplified. The resulting derived unit will preserve both symbols and their relative magnitude. This allows us to properly print symbols of some units or constants that require such behavior. For example, the Hubble constant is expressed in km\u22c5s\u207b\u00b9\u22c5Mpc\u207b\u00b9, where both km and Mpc are units of length.
       
      Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent symbolic expression simplification of equivalent entities.
       
      4.  
    4.  
      Repacking
       
      In case an expression uses two results of other operations, the components of its arguments are repacked into one resulting type and simplified there.
       
      For example, assuming:
       
      constexpr auto X = A / B;\n
       
      then:
       Operation Resulting template expression arguments X * B A X * A power<A, 2>, per<B> X * X power<A, 2>, per<power<B, 2>> X / X {identity} X / A {identity}, per<B> X / B A, per<power<B, 2>> 
      5.  
    "},{"location":"users_guide/framework_basics/interface_introduction/#example","title":"Example","text":"
    Thanks to all of the features described above, a user may write the code like this one:
     
    using namespace mp_units::si::unit_symbols;\nquantity speed = 60. * isq::speed[km / h];\nquantity duration = 8 * s;\nquantity acceleration = speed / duration;\nstd::cout << \"acceleration: \" << acceleration << \" (\" << acceleration.in(m / s2) << \")\\n\";\n
     
    The acceleration quantity, being the result of the above code, has the following type (after stripping the mp_units namespace for brevity):
     
    quantity<reference<derived_quantity_spec<isq::speed, per<isq::time>>{}, derived_unit<si::kilo_<si::metre{}>, per<non_si::hour, si::second>>{}>{}, int>\n
     
    and the text output presents:
     
    acceleration: 7.5 km h\u207b\u00b9 s\u207b\u00b9 (2.08333 m/s\u00b2)\n
    "},{"location":"users_guide/framework_basics/obtaining_metadata/","title":"Obtaining Metadata","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#quantity-spec","title":"quantity spec","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#unit","title":"unit","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#reference","title":"reference","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#quantity","title":"quantity","text":""},{"location":"users_guide/framework_basics/quantity_arithmetics/","title":"Quantity Arithmetics","text":""},{"location":"users_guide/framework_basics/quantity_arithmetics/#quantity-is-a-numeric-wrapper","title":"quantity is a numeric wrapper","text":"
    If we think about it, the quantity class template is just a \"smart\" numeric wrapper. It exposes properly constrained set of arithmetic operations on one or two operands.
     
    Important: quantity propagates the underlying interface
     
    Every single arithmetic operator is exposed by the quantity class template only if the underlying representation type provides it as well, and when its implementation has proper semantics (e.g., returns a reasonable type).
     
    For example, in the following code, -a will compile only if MyInt exposes such an operation as well:
     
    quantity a = MyInt{42} * m;\nquantity b = -a;\n
     
    Assuming that:
     
       
    • q is our quantity,
      •  
    • qi is a quantity implicitly convertible to q,
      •  
    • qk is a quantity of the same kind as q,
      •  
    • q1 is a quantity of dimension_one with the unit one,
      •  
    • qq is any other quantity,
      •  
    • number is a value of a type \"compatible\" with q's representation type,
      •  
     
    here is the list of all the supported operators:
     
       
    • unary:
         
      • +q
        •  
      • -q
        •  
      • ++q
        •  
      • q++
        •  
      • --q
        •  
      • q--
        •  
       
      •  
    • compound assignment:
         
      • q += qi
        •  
      • q -= qi
        •  
      • q %= qi
        •  
      • q *= number
        •  
      • q *= q1
        •  
      • q /= number
        •  
      • q /= q1
        •  
       
      •  
    • binary:
         
      • q + qk
        •  
      • q - qk
        •  
      • q % qk
        •  
      • q * qq
        •  
      • q * number
        •  
      • number * q
        •  
      • q / qq
        •  
      • q / number
        •  
      • number / q
        •  
       
      •  
    • ordering and comparison:
         
      • q == qk
        •  
      • q <=> qk
        •  
       
      •  
     
    As we can see, there are plenty of operations one can do on a value of a quantity type. As most of them are obvious, in the following chapters, we will discuss only the most important or non-trivial aspects of quantity arithmetics.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#addition-and-subtraction","title":"Addition and subtraction","text":"
    Quantities can easily be added or subtracted from each other:
     
    static_assert(1 * m + 1 * m == 2 * m);\nstatic_assert(2 * m - 1 * m == 1 * m);\nstatic_assert(isq::height(1 * m) + isq::height(1 * m) == isq::height(2 * m));\nstatic_assert(isq::height(2 * m) - isq::height(1 * m) == isq::height(1 * m));\n
     
    The above uses the same types for LHS, RHS, and the result, but in general, we can add, subtract, or compare the values of any quantity type as long as both quantities are of the same kind. The result of such an operation will be the common type of the arguments:
     
    static_assert(1 * km + 1.5 * m == 1001.5 * m);\nstatic_assert(isq::height(1 * m) + isq::width(1 * m) == isq::length(2 * m));\nstatic_assert(isq::height(2 * m) - isq::distance(0.5 * m) == 1.5 * m);\nstatic_assert(isq::radius(1 * m) - 0.5 * m == isq::radius(0.5 * m));\n
     
    Note
     
    Please note that for the compound assignment operators, we always need to end up with the left-hand-side argument type:
     
    static_assert((1 * m += 1 * km) == 1001 * m);\nstatic_assert((isq::length(1 * m) += isq::height(1 * m)) == isq::length(1 * m));\nstatic_assert((isq::height(1.5 * m) -= 1 * m) == isq::height(0.5 * m));\n
     
    If we will break typical library's convertibility rules, the following code will not compile:
     
    quantity q1 = 1 * m -= 0.5 * m;                         // Compile-time error(1)\nquantity q2 = 1 * km += 1 * m;                          // Compile-time error(2)\nquantity q3 = isq::height(1 * m) += isq::length(1 * m); // Compile-time error(3)\n
     
       
    1. Conversion of the floating-point to integral representation type is    considered narrowing.
      2.  
    2. Conversion of quantity with integral representation type from a unit of a higher resolution    to the one with a lower resolution is considered narrowing.
      3.  
    3. Conversion from a more generic quantity type to a more specific one is    considered unsafe.
      4.  
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#multiplication-and-division","title":"Multiplication and division","text":"
    Multiplying or dividing a quantity by a number does not change its quantity type or unit. However, its representation type may change. For example:
     
    static_assert(isq::height(3 * m) * 0.5 == isq::height(1.5 * m));\n
     
    Note
     
    Unless we use a compound assignment operator, in which case we always have to result with the type of the left-hand-side argument. This, together with the fact that this library tries to prevent truncation of a quantity value means, that the following does not compile:
     
    quantity q = isq::height(3 * m) *= 0.5; // Compile-time error\n
     
    However, suppose we multiply or divide quantities of the same or different types or we divide a raw number by a quantity. In that case, we most probably will end up in a quantity of yet another type:
     
    static_assert(120 * km / (2 * h) == 60 * km / h);\nstatic_assert(isq::width(2 * m) * isq::length(2 * m) == isq::area(4 * m2));\nstatic_assert(50 / isq::time(1 * s) == isq::frequency(50 * Hz));\n
     
    Note
     
    An exception from the above rule happens when one of the arguments is a dimensionless quantity. If we multiply or divide by such a quantity, the quantity type will not change. If such a quantity has a unit one, also the unit of a quantity will not change:
     
    static_assert(120 * m / (2 * one) == 60 * m);\n
     
    An interesting special case happens when we divide the same quantity kinds or multiply a quantity by its inverted type. In such a case, we end up with a dimensionless quantity.
     
    static_assert(isq::height(4 * m) / isq::width(2 * m) == 2 * one); // (1)!\nstatic_assert(5 * h / (120 * min) == 0 * one);  // (2)!\nstatic_assert(5. * h / (120 * min) == 2.5 * one);\n
     
       
    1. The resulting quantity type of the LHS is isq::height / isq::width, which is a quantity of the dimensionless kind.
      2.  
    2. The resulting quantity of the LHS is 0 * dimensionless[h / min]. To be consistent with the division of different quantity types, we do not convert quantity values to a common unit before the division.
      3.  
     
    Important: Beware of integral division
     
    The physical units library can't do any runtime branching logic for the division operator. All logic must be done at compile-time when the actual values are unknown, and the quantity types can't change at runtime.
     
    If we expect 120 * km / (2 * h) to return 60 km / h, we have to agree with the fact that 5 * km / (24 * h) returns 0 km/h. We can't do a range check at runtime to dynamically adjust scales and types based on the values of provided function arguments.
     
    This is why we often prefer floating-point representation types when dealing with units. Some popular physical units libraries even forbid integer division at all.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#modulo","title":"Modulo","text":"
    Now that we know how addition, subtraction, multiplication, and division work, it is time to discuss modulo. What would we expect to be returned from the following quantity equation?
     
    auto q = 5 * h % (120 * min);\n
     
    Most of us would probably expect to see 1 h or 60 min as a result. And this is where the problems start.
     
    C++ language defines its / and % operators with the quotient-remainder theorem:
     
    q = a / b;\nr = a % b;\nq * b + r == a;\n
     
    The important property of the modulo operation is that it only works for integral representation types (it is undefined what modulo for floating-point types means). However, as we saw in the previous chapter, integral types are tricky because they often truncate the value.
     
    From the quotient-remainder theorem, the result of modulo operation is r = a - q * b. Let's see what we get from such a quantity equation on integral representation types:
     
    const quantity a = 5 * h;\nconst quantity b = 120 * min;\nconst quantity q = a / b;\nconst quantity r = a - q * b;\n\nstd::cout << \"reminder: \" << r << \"\\n\";\n
     
    The above code outputs:
     
    reminder: 5 h\n
     
    And now, a tough question needs an answer. Do we really want modulo operation on physical units to be consistent with the quotient-remainder theorem and return 5 h for 5 * h % (120 * min)?
     
    This is exactly why we decided not to follow this hugely surprising path in the mp-units library. The selected approach was also consistent with the feedback from the C++ experts. For example, this is what Richard Smith said about this issue:
     
    Richard Smith
     
    I think the quotient-remainder property is a less important motivation here than other factors -- the constraints on % and / are quite different, so they lack the inherent connection they have for integers. In particular, I would expect that A / B works for all quantities A and B, whereas A % B is only meaningful when A and B have the same dimension. It seems like a nice-to-have for the property to apply in the case where both / and % are defined, but internal consistency of / across all cases seems much more important to me.
     
    I would expect 61 min % 1 h to be 1 min, and 1 h % 59 min to also be 1 min, so my intuition tells me that the result type of A % B, where A and B have the same dimension, should have the smaller unit of A and B (and if the smaller one doesn't divide the larger one, we should either use the gcd / std::common_type of the units of A and B or perhaps just produce an error). I think any other behavior for % is hard to defend.
     
    On the other hand, for division it seems to me that the choice of unit should probably not affect the result, and so if we want that 5 mm / 120 min = 0 mm/min, then 5 h / 120 min == 0 hc (where hc is a dimensionless \"hexaconta\", or 60x, unit). I don't like the idea of taking SI base units into account; that seems arbitrary and like it would do the wrong thing as often as it does the right thing, especially when the units have a multiplier that is very large or small. We could special-case the situation of a dimensionless quantity, but that could lead to problematic overflow pretty easily: a calculation such as 10 s * 5 GHz * 2 uW would overflow an int if it produces a dimensionless quantity for 10 s * 5 GHz, but it could equally produce 50 G * 2 uW = 100 kW without any overflow, and presumably would if the terms were merely reordered.
     
    If people want to use integer-valued quantities, I think it's fundamental that you need to know what the units of the result of an operation will be, and take that into account in how you express computations; the simplest rule for heterogeneous operators like * or / seems to be that the units of the result are determined by applying the operator to the units of the operands -- and for homogeneous operators like + or %, it seems like the only reasonable option is that you get the std::common_type of the units of the operands.
     
    To summarize, the modulo operation on physical units has more in common with addition and division operators than with the quotient-remainder theorem. To avoid surprising results, the operation uses a common unit to do the calculation and provide its result:
     
    static_assert(5 * h / (120 * min) == 0 * one);\nstatic_assert(5 * h % (120 * min) == 60 * min);\nstatic_assert(61 * min % (1 * h) == 1 * min);\nstatic_assert(1 * h % (59 * min) == 1 * min);\n
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#comparison-against-zero","title":"Comparison against zero","text":"
    In our code, we often want to compare the value of a quantity against zero. For example, we do it every time we want to ensure that we deal with a non-zero or positive value.
     
    We could implement such checks in the following way:
     
    if (q1 / q2 != 0 * m / s)\n  // ...\n
     
    The above would work (assuming we are dealing with the quantity of speed) but could be suboptimal if the result of q1 / q2 is not expressed in m / s. To eliminate the need for conversion, we need to write:
     
    if (auto q = q1 / q2; q != q.zero())\n  // ...\n
     
    but that is a bit inconvenient, and inexperienced users could be unaware of this technique and its reasons.
     
    For the above reasons, the library provides dedicated interfaces to compare against zero that follow the naming convention of named comparison functions in the C++ Standard Library. The mp-units/compare.h header file exposes the following functions:
     
       
    • is_eq_zero
      •  
    • is_neq_zero
      •  
    • is_lt_zero
      •  
    • is_gt_zero
      •  
    • is_lteq_zero
      •  
    • is_gteq_zero
      •  
     
    Thanks to them, to save typing and not pay for unneeded conversions, our check could be implemented as follows:
     
    if (is_neq_zero(q1 / q2))\n  // ...\n
     
    Tip
     
    Those functions will work with any type T that exposes zero() member function returning something comparable to T. Thanks to that, we can use them not only with quantities but also with std::chrono::duration or any other type that exposes such an interface.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#other-maths","title":"Other maths","text":"
    This chapter scopes only on the quantity type's operators. However, there are many named math functions taking quantities as arguments. Those can be found in the mp-units/math.h header file. Among others, we can find there the following:
     
       
    • pow(), sqrt(), cbrt(),
      •  
    • exp(),
      •  
    • abs(),
      •  
    • epsilon(),
      •  
    • fma(), fmod(), remainder(),
      •  
    • isfinite(), isinf(), isnan(),
      •  
    • floor(), ceil(), round(),
      •  
    • inverse(),
      •  
    • hypot(),
      •  
    • sin(), cos(), tan(),
      •  
    • asin(), acos(), atan(), atan2().
      •  
     
    In the library, we can also find mp-units/random.h header file with all the pseudo-random number generators working on quantity types.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/","title":"Simple and Typed Quantities","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    After that, it says:
     
    Quote
     
    A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-class-template","title":"quantity class template","text":"
    In the mp-units library, a quantity is represented with the following class template:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    The concept Reference is satisfied by a type that provides all the domain-specific metadata describing a quantity (besides the representation type and its value). Such a type can be either:
     
       
    • a unit with an associated quantity type (e.g., si::metre, m / s),
      •  
    • a reference type explicitly specifying the quantity type and its unit.
      •  
     
    Important
     
    All units in the SI system have an associated quantity type.
     
    A reference type is implicitly created as a result of the following expression:
     
    constexpr auto ref = isq::length[m];\n
     
    The above example results in the following type reference<isq::length(), si::metre()> being instantiated.
     
    As we have two alternative options that satisfy the Reference concept in the mp-units library, we also have two modes of dealing with quantities.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#simple-quantities","title":"Simple quantities","text":"
    The simple mode might be preferred by many developers. It is all about units. Quantities using this mode have shorter type identifiers, resulting in easier-to-understand error messages and better debugging experience.
     
    Here is a simple example showing how to deal with such quantities:
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = 110 * km;\n  const quantity duration = 2 * h;\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = 110 * km;\n  const quantity duration = 2 * h;\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    The code above prints:
     
    A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\n
     
    Try it on Compiler Explorer
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#user-provided-unit-wrappers","title":"User-provided unit wrappers","text":"
    Sometimes it might be awkward to type some derived units:
     
    quantity speed = 60 * km / h;\n
     
    In case such a unit is used a lot in the project, a user can easily provide a nicely named wrapper for it with:
     
    constexpr auto kmph = km / h;\nquantity speed = 60 * kmph;\n
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#easy-to-understand-compilation-error-messages","title":"Easy-to-understand compilation error messages","text":"
    In case a user makes an error in a quantity equation and the result of the calculation will not match the function return type, the compiler will detect such an issue at compile-time.
     
    For example, in case we will make the following error:
     
    constexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist * time;  // (1)!\n}\n
     
       
    1. Quantities multiplied (instead of divided) by accident.
      2.  
     
    the following compilation error message will be provided:
     
    error: no viable conversion from returned value of type\n       'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::si::second>{{{}}}, [...]>'\n       to function return type\n       'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::per<mp_units::si::second>>{{{}}}, [...]>'\n   10 |   return dist * time;\n      |          ^~~~~~~~~~~\n
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#typed-quantities","title":"Typed quantities","text":"
    Simple mode is all about and just about units. Typed quantities should be preferred if we also want to be quantity-safe. This, for example, allows us to specify if we deal with width, height, or radius and ensure we will not assign one to another by accident.
     
    The previous example can be re-typed using typed quantities in the following way:
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n                                                                 quantity<isq::time[si::second]> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = isq::distance(110 * km);\n  const quantity duration = isq::time(2 * h);\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n                                                                 quantity<isq::time[si::second]> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = isq::distance(110 * km);\n  const quantity duration = isq::time(2 * h);\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\n
     
    Try it on Compiler Explorer
     
    In case we will accidentally make the same calculation error as before, this time, we will get a bit longer error message, this time also containing information about the quantity type:
     
    error: no viable conversion from returned value of type\n       'quantity<reference<get_quantity_spec(metre{}) * struct time{{{}}}, metre{} * second{{}}>{}, [...]>'\n       to function return type\n       'quantity<reference<speed{}, derived_unit<metre, per<second>>{}>{}, [...]>'\n   12 |   return dist * time;\n      |          ^~~~~~~~~~~\n
     
    As we can see above, the compilation error is longer but still relatively easy to understand.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-safety-with-typed-quantities","title":"Quantity-safety with typed quantities","text":"
    Based on the previous example, it might seem that typed quantities are not that useful, more to type and provide harder-to-understand error messages. It might be true in some cases, but there are scenarios where they offer additional level of safety.
     
    Let's see another example:
     C++ modulesHeader files SimpleTyped 
    #include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\nclass StorageTank {\n  quantity<square(si::metre)> base_;\n  quantity<si::metre> height_;\npublic:\n  constexpr StorageTank(const quantity<square(si::metre)>& base,\n                        const quantity<si::metre>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n                                   const quantity<si::metre>& height) :\n    StorageTank(std::numbers::pi * pow<2>(radius), height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<si::metre>& length,\n                                   const quantity<si::metre>& width,\n                                   const quantity<si::metre>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n  // ...\n}\n
     
    #include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n    quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n    quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n  quantity<horizontal_area[square(si::metre)]> base_;\n  quantity<isq::height[si::metre]> height_;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n                        const quantity<isq::height[si::metre]>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n                                   const quantity<isq::width[si::metre]>& width,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                     isq::width(500 * mm),\n                                     isq::height(200 * mm));\n  // ...\n}\n
     SimpleTyped 
    #include <mp-units/math.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\nclass StorageTank {\n  quantity<square(si::metre)> base_;\n  quantity<si::metre> height_;\npublic:\n  constexpr StorageTank(const quantity<square(si::metre)>& base,\n                        const quantity<si::metre>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n                                   const quantity<si::metre>& height) :\n    StorageTank(std::numbers::pi * pow<2>(radius), height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<si::metre>& length,\n                                   const quantity<si::metre>& width,\n                                   const quantity<si::metre>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n  // ...\n}\n
     
    #include <mp-units/math.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n    quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n    quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n  quantity<horizontal_area[square(si::metre)]> base_;\n  quantity<isq::height[si::metre]> height_;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n                        const quantity<isq::height[si::metre]>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n                                   const quantity<isq::width[si::metre]>& width,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                     isq::width(500 * mm),\n                                     isq::height(200 * mm));\n  // ...\n}\n
     
    In the above example, the highlighted call doesn't look that safe anymore in the case of simple quantities, right? Suppose someone, either by mistake or due to some refactoring, will call the function with an invalid order of arguments. In that case, the program will compile fine but not work as expected.
     
    Let's see what will happen if we reorder the arguments in the case of typed quantities:
     
    auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                   isq::height(200 * mm),\n                                   isq::width(500 * mm));\n
     
    This time, a compiler provides the following compilation error:
     
    <source>:53:15: error: no matching constructor for initialization of 'RectangularStorageTank'\n   53 |   auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n      |               ^                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n   54 |                                      isq::height(200 * mm),\n      |                                      ~~~~~~~~~~~~~~~~~~~~~~\n   55 |                                      isq::width(500 * mm));\n      |                                      ~~~~~~~~~~~~~~~~~~~~\n<source>:43:13: note: candidate constructor not viable: no known conversion from\n                'quantity<mp_units::reference<mp_units::isq::height{{{{{}}}}},\n                                              mp_units::si::milli_<mp_units::si::metre{{}}>{{{{}}}}>{}, int>' to\n                'const quantity<reference<width{}, metre{}>{}, (default) double>' for 2nd argument\n   43 |   constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n      |             ^\n   44 |                                    const quantity<isq::width[m]>& width,\n      |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n
     
    What about derived quantities? In the above example, you probably noticed that we also defined a custom horizontal_area quantity of kind isq::area. This quantity has the unique property of being implicitly constructible only from the result of the multiplication of quantities of horizontal_area and isq::width or the ones that implicitly convert to them.
     
    Based on the above error message, we already know that a quantity of isq::height is not implicitly constructible to the quantity of isq::width. This property is transitively passed to derived quantities using them. If by accident, we will try to create a StorageTank base class in the following way:
     
    class RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n                                   const quantity<isq::width[m]>& width,\n                                   const quantity<isq::height[m]>& height) :\n    StorageTank(length * height, height)\n  {\n  }\n};\n
     
    we will again get a compilation error message like this one:
     
    error: no matching constructor for initialization of 'StorageTank'\n   46 |     StorageTank(length * height, height)\n      |     ^           ~~~~~~~~~~~~~~~~~~~~~~~\n<source>:22:13: note: candidate constructor not viable: no known conversion from\n                'quantity<mp_units::reference<mp_units::derived_quantity_spec<horizontal_length, mp_units::isq::height>{{}, {{}}},\n                                              mp_units::derived_unit<mp_units::power<mp_units::si::metre, 2>>{{{}}}>{}, [...]>' to\n                'const quantity<reference<horizontal_area{}, derived_unit<power<metre, 2>>{}>{}, [...]>' for 1st argument\n   22 |   constexpr StorageTank(const quantity<horizontal_area[m2]>& base,\n      |             ^           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n
     
    Tip
     
    If you need to use various quantities of the same kind, consider using typed quantities to bring an additional level of safety to your project.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity_cast-to-force-unsafe-conversions","title":"quantity_cast() to force unsafe conversions","text":"
    Did you notice the quantity_cast() usage in the other child class?
     
    class CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[m]>& radius,\n                                   const quantity<isq::height[m]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n
     
    As isq::radius is not convertible to horizontal_length, the derived quantity of pow<2>(radius) can't be converted to horizontal_area as well. It would be unsafe to allow such a conversion as not all of the circles lie flat on the ground, right?
     
    In such a case, the user has to explicitly force such an unsafe conversion with the help of a quantity_cast(). This function name is easy to spot in code reviews or while searching the project for problems if something goes sideways. In case of unexpected quantities-related issues, this should be the first function to look for.
     
    Tip
     
    Do not overuse quantity_cast(). Use it only when necessary and ensure that the requested conversion is exactly what you need in this case.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#which-mode-should-i-use-in-my-project","title":"Which mode should I use in my project?","text":"
    We have good news for you if you wonder which mode you should choose for your project. Simple and typed quantity modes can be freely mixed with each other. When you use different quantities of the same kind (e.g., radius, wavelength, altitude, ...), you should probably reach for typed quantities to bring additional safety for those cases. Otherwise, just use simple mode for the remaining quantities. The mp-units library will do its best to protect your project based on the information provided.
     
    Tip
     
    You can easily mix simple and typed quantities in your project.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/","title":"Systems of Quantities","text":"
    The physical units libraries on the market typically only scope on modeling one or more systems of units. However, this is not the only system kind to model. Another, and maybe even more important, system kind is a system of quantities.
     
    Info
     
    Please note that the mp-units is probably the first library on the Open Source market (in any programming language) that models the ISQ with all its definitions provided in ISO 80000. Please provide feedback if something looks odd or could be improved.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"
    Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. For example, let's see the following implementation:
     
    class Box {\n  area base_;\n  length height_;\npublic:\n  Box(length l, length w, length h) : base_(l * w), height_(h) {}\n  // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\n
     
    How do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do 
     
    Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are different quantities.
     
    A similar issue is related to figuring out what should be the result of:
     
    auto res = 1 * Hz + 1 * Bq + 1 * Bd;\n
     
    where:
     
       
    • Hz (hertz) - unit of frequency
      •  
    • Bq (becquerel) - unit of activity
      •  
    • Bd (baud) - unit of modulation rate
      •  
     
    All of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
     
    If the above example seems too abstract, let's consider a fuel consumption (fuel volume divided by distance, e.g., 6.7 l/km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
     
    Important
     
    More than one quantity may be defined for the same dimension:
     
       
    • quantities of different kinds (e.g. frequency, modulation rate, activity, ...)
      •  
    • quantities of the same kind (e.g. length, width, altitude, distance, radius,   wavelength, position vector, ...)
      •  
     
    It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"
    ISO 80000-1
     
       
    • Quantities may be grouped together into categories of quantities that are   mutually comparable
      •  
    • Mutually comparable quantities are called quantities of the same kind
      •  
    • Two or more quantities cannot be added or subtracted unless they belong to the same category   of mutually comparable quantities
      •  
    • Quantities of the same kind within a given system of quantities have the same quantity   dimension
      •  
    • Quantities of the same dimension are not necessarily of the same kind
      •  
     
    The above quotes from ISO 80000 provide answers to all the issues above. Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are of different kinds, the expression provided above should not compile.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"
    ISO 80000 specify hundreds of different quantities. There are plenty of different kinds provided and often each kind contains more than one quantity. In fact, it turns out that such quantities form a hierarchy of quantities of the same kind.
     
    For example, here are all quantities of the kind length provided in the ISO 80000:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    Each of the above quantities expresses some kind of length, and each can be measured with si::metre. However, each of them has different properties, usage, and sometimes even requires a different representation type (notice that position_vector and displacement are vector quantities).
     
    Forming such a hierarchy helps us in defining arithmetics and conversion rules for various quantities of the same kind.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#defining-quantities","title":"Defining quantities","text":"
    In the mp-units library all the information about the quantity is provided with the quantity_spec class template. In order to define a specific quantity a user should inherit a strong type from such an instantiation.
     
    Tip
     
    Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code. However, as C++23 is far from being mainstream today, a portability macro QUANTITY_SPEC() is provided and used consistently through the library to allow the code to compile with C++20 compilers, thanks to the CRTP usage under the hood.
     
    See more in the C++ compiler support chapter.
     
    For example, here is how the above quantity kind tree can be modeled in the library:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct width final : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<width> {} diameter;\ninline constexpr struct radius final : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<length> {} wavelength;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<displacement> {} position_vector;\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct width final : quantity_spec<width, length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<thickness, width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<diameter, width> {} diameter;\ninline constexpr struct radius final : quantity_spec<radius, width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius_of_curvature, radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<path_length, length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<distance, path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<radial_distance, distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<wavelength, length> {} wavelength;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, displacement> {} position_vector;\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(width, length);\ninline constexpr auto breadth = width;\nQUANTITY_SPEC(height, length);\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\nQUANTITY_SPEC(thickness, width);\nQUANTITY_SPEC(diameter, width);\nQUANTITY_SPEC(radius, width);\nQUANTITY_SPEC(radius_of_curvature, radius);\nQUANTITY_SPEC(path_length, length);\ninline constexpr auto arc_length = path_length;\nQUANTITY_SPEC(distance, path_length);\nQUANTITY_SPEC(radial_distance, distance);\nQUANTITY_SPEC(wavelength, length);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nQUANTITY_SPEC(position_vector, displacement);\n
     
    Note
     
    More information on how to define a system of quantities can be found in the \"International System of Quantities (ISQ)\" chapter.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#comparing-adding-and-subtracting-quantities","title":"Comparing, adding, and subtracting quantities","text":"
    ISO 80000 explicitly states that width and height are quantities of the same kind, and as such they:
     
       
    • are mutually comparable,
      •  
    • can be added and subtracted.
      •  
     
    If we take the above for granted, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
     
    static_assert(get_common_quantity_spec(isq::width, isq::height) == isq::length);\nstatic_assert(get_common_quantity_spec(isq::thickness, isq::radius) == isq::width);\nstatic_assert(get_common_quantity_spec(isq::distance, isq::path_length) == isq::path_length);\n
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#converting-between-quantities","title":"Converting between quantities","text":"
    Based on the same hierarchy of quantities of kind length, we can define quantity conversion rules.
     
       
    1.  
      Implicit conversions
       
         
      • every width is a length
        •  
      • every radius is a width
        •  
       
      static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\n
       
      2.  
    2.  
      Explicit conversions
       
         
      • not every length is a width
        •  
      • not every width is a radius
        •  
       
      static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\n
       
      3.  
    3.  
      Explicit casts
       
         
      • height is not a width
        •  
      • both height and width are quantities of kind length
        •  
       
      static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\n
       
      4.  
    4.  
      No conversion
       
         
      • time has nothing in common with length
        •  
       
      static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\n
       
      5.  
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#hierarchies-of-derived-quantities","title":"Hierarchies of derived quantities","text":"
    Derived quantity equations often do not automatically form a hierarchy tree. This is why it is sometimes not obvious what such a tree should look like. Also, ISO explicitly states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    The below presents some arbitrary hierarchy of derived quantities of kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    potential_energy --- gravitational_potential_energy[\"<b>gravitational_potential_energy</b><br><i>(mass * acceleration_of_free_fall * height)</i>\"]\n    potential_energy --- elastic_potential_energy[\"<b>elastic_potential_energy</b><br><i>(spring_constant * amount_of_compression<sup>2</sup>)</i>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b><br><i>(mass * speed<sup>2</sup>)</i>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    Notice, that even though all of those quantities have the same dimension and can be expressed in the same units, they have different quantity equations that can be used to create them implicitly:
     
       
    •  
      energy is the most generic one and thus can be created from base quantities of mass, length,   and time. As those are also the roots of quantities of their kinds and all other quantities from their   trees are implicitly convertible to them (we agreed on that \"every width is a length\" already),   it means that an energy can be implicitly constructed from any quantity of mass, length, and time:
       
      static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\n
       
      •  
    •  
      mechanical energy is a more \"specialized\" quantity than energy (not every energy is   a mechanical energy). It is why an explicit cast is needed to convert from either energy or   the results of its quantity equation:
       
      static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     isq::mechanical_energy));\n
       
      •  
    •  
      gravitational potential energy is not only even more specialized one but additionally,   it is special in a way that it provides its own \"constrained\"   quantity equation. Maybe not every   mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every   mass * acceleration_of_free_fall * height is.
       
      static_assert(!implicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n                                     gravitational_potential_energy));\n
       
      •  
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#modeling-a-quantity-kind","title":"Modeling a quantity kind","text":"
    In the physical units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
     
    To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
     
    Important
     
    isq::length and kind_of<isq::length> are two different things.
     
    Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
     
    static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\n
     
    Additionally, the result of operations on quantity kinds is also a quantity kind:
     
    static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\n
     
    However, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
     
    static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\n
     
    Info
     
    Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
     
    static_assert(get_kind(isq::width) == kind_of<isq::length>);\n
    "},{"location":"users_guide/framework_basics/systems_of_units/","title":"Systems of Units","text":"
    Modeling a system of units is probably the most important feature and a selling point of every physical units library. Thanks to that, the library can protect users from performing invalid operations on quantities and provide automated conversion factors between various compatible units.
     
    Probably all the libraries in the wild model the SI and many of them provide support for additional units belonging to various other systems (e.g., imperial, cgs, etc).
    "},{"location":"users_guide/framework_basics/systems_of_units/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of Units are based on Systems of Quantities","text":"
    Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. To create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
     
    The SI is explicitly stated to be based on the ISQ. Among others, it defines 7 base units, one for each base quantity. In the mp-units this is expressed by associating a quantity kind (that we discussed in detail in the previous chapter) with a unit that is used to express it:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\n
     
    Important
     
    The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
    "},{"location":"users_guide/framework_basics/systems_of_units/#units-compose","title":"Units compose","text":"
    One of the most vital points of the SI system is that its units compose. This allows providing thousands of different units for hundreds of various quantities with a tiny set of predefined units and prefixes.
     
    The same is modeled in the mp-units library, which also allows composing predefined units to create a nearly infinite number of different derived units. For example, one can write:
     
    quantity<si::metre / si::second> q;\n
     
    to express a quantity of speed. The resulting quantity type is implicitly inferred from the unit equation by repeating the same operations on the associated quantity kinds.
    "},{"location":"users_guide/framework_basics/systems_of_units/#many-shades-of-the-same-unit","title":"Many shades of the same unit","text":"
    The SI provides the names for 22 common coherent units of 22 derived quantities.
     
    Each such named derived unit is a result of a specific predefined unit equation. For example, a unit of power quantity is defined in the library as:
     
    inline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\n
     
    However, a power quantity can be expressed in other units as well. For example, the following:
     
    auto q1 = 42 * W;\nstd::cout << q1 << \"\\n\";\nstd::cout << q1.in(J / s) << \"\\n\";\nstd::cout << q1.in(N * m / s) << \"\\n\";\nstd::cout << q1.in(kg * m2 / s3) << \"\\n\";\n
     
    prints:
     
    42 W\n42 J/s\n42 N m/s\n42 kg m\u00b2/s\u00b3\n
     
    All of the above quantities are equivalent and mean exactly the same.
     
    Note
     
    The above code example may give the impression that the order of components in a derived unit is determined by the multiplication order. This is not the case. As stated in Simplifying the resulting symbolic expressions, to be able to reason about and simplify units, the library needs to order them in an appropriate order. This will affect the order of components in a resulting type and text output.
     
    Please refer to our FAQ for more information.
    "},{"location":"users_guide/framework_basics/systems_of_units/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"
    Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation 1 / s. However, it also explicitly states:
     
    SI Brochure
     
    The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
     
    The above means that the usage of becquerel as a unit of a frequency quantity is an error.
     
    The library allows constraining such units to work only with quantities of a specific kind in the following way:
     
    inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\n
     
    With the above, hertz can only be used with frequencies, while becquerel should only be used with quantities of activity. This means that the following equation will not compile:
     
    auto q = 1 * Hz + 1 * Bq;   // Fails to compile\n
     
    This is exactly what we wanted to achieve to improve the type-safety of the library.
    "},{"location":"users_guide/framework_basics/systems_of_units/#prefixed-units","title":"Prefixed units","text":"
    Besides named units, the SI specifies also 24 prefixes (all being a power of 10) that can be prepended to all named units to obtain various scaled versions of them.
     
    Implementation of std::ratio provided by all major compilers is able to express only 16 of them. This is why, in the mp-units, we had to find an alternative way to represent unit magnitude in a more flexible way.
     
    Each prefix is implemented similarly to the following:
     
    template<PrefixableUnit U> struct quecto_ : prefixed_unit<\"q\", mag_power<10, -30>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr quecto_<decltype(U)> quecto;\n
     
    and then a PrefixableUnit can be prefixed in the following way:
     
    inline constexpr auto qm = quecto<metre>;\n
     
    The usage of mag_power not only enables providing support for SI prefixes, but it can also efficiently represent any rational magnitude. For example, IEC 80000 prefixes used in the IT industry can be implemented as:
     
    template<PrefixableUnit U> struct yobi_ : prefixed_unit<\"Yi\", mag_power<2, 80>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr yobi_<decltype(U)> yobi;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#scaled-units","title":"Scaled units","text":"
    In the SI, all units are either base or derived units or prefixed versions of those. However, those are only some of the options possible.
     
    For example, there is a list of off-system units accepted for use with SI. Those are scaled versions of the SI units with ratios that can't be explicitly expressed with predefined SI prefixes. Those include units like minute, hour, or electronvolt:
     
    inline constexpr struct minute final : named_unit<\"min\", mag<60> * si::second> {} minute;\ninline constexpr struct hour final : named_unit<\"h\", mag<60> * minute> {} hour;\ninline constexpr struct electronvolt final : named_unit<\"eV\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * si::joule> {} electronvolt;\n
     
    Also, units of other systems of units are often defined in terms of scaled versions of the SI units. For example, the international yard is defined as:
     
    inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\n
     
    For some units, a magnitude might also be irrational. The best example here is a degree which is defined using a floating-point magnitude having a factor of the number \u03c0 (Pi):
     
    inline constexpr struct pi final : mag_constant<symbol_text{u8\"\u03c0\", \"pi\"}, std::numbers::pi_v<long double>> {} pi;\ninline constexpr auto \u03c0 = pi;\n
     
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag<\u03c0> / mag<180> * si::radian> {} degree;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#unit-symbols","title":"Unit symbols","text":"
    Units are available via their full names or through their short symbols. To use a long version, it is enough to type:
     
    quantity q1 = 42 * si::metre / si::second;\nquantity q2 = 42 * si::kilo<si::metre> / si::hour;\n
     
    To simplify how we spell it a short, user-friendly symbols are provided in a dedicated subnamespace in systems definitions:
     
    namespace si::unit_symbols {\n\nconstexpr auto m = si::metre;\nconstexpr auto km = si::kilo<si::metre>;\nconstexpr auto s = si::second;\nconstexpr auto h = si::hour;\n\n}\n
     
    Unit symbols introduce a lot of short identifiers into the current namespace. This is why they are opt-in. A user has to explicitly \"import\" them from a dedicated unit_symbols namespace:
     using-declarationusing-directive 
    using namespace si::unit_symbols;\n\nquantity q1 = 42 * m / s;\nquantity q2 = 42 * km / h;\n
     
    using si::unit_symbols::m;\nusing si::unit_symbols::km;\nusing si::unit_symbols::s;\nusing si::unit_symbols::h;\n\nquantity q1 = 42 * m / s;\nquantity q2 = 42 * km / h;\n
     
    We also provide alternative object identifiers using UTF-8 characters in their names for most unit symbols. The code using UTF-8 looks nicer, but it is harder to type on the keyboard. This is why we provide both versions of identifiers for such units.
     PortableWith UTF-8 glyphs 
    quantity resistance = 60 * kohm;\nquantity capacitance = 100 * uF;\n
     
    quantity resistance = 60 * k\u03a9;\nquantity capacitance = 100 * \u00b5F;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#common-units","title":"Common units","text":"
    Adding, subtracting, or comparing two quantities of different units will force the library to find a common unit for those. This is to prevent data truncation. For the cases when one of the units is an integral multiple of the another, the resulting quantity will use a \"smaller\" one in its result. For example:
     
    static_assert((1 * kg + 1 * g).unit == g);\nstatic_assert((1 * km + 1 * mm).unit == mm);\nstatic_assert((1 * yd + 1 * mi).unit == yd);\n
     
    However, in many cases an arithmetic operation on quantities of different units will result in a yet another unit. This happens when none of the source units is an integral multiple of another. In such cases, the library returns a special type that denotes that we are dealing with a common unit of such an equation:
     
    quantity q1 = 1 * km + 1 * mi;     // quantity<common_unit<international::mile, si::kilo_<si::metre>>{}, int>\nquantity q2 = 1. * rad + 1. * deg; // quantity<common_unit<si::degree, si::radian>{}, double>\n
     
    Note
     
    A user should never explicitly instantiate a common_unit class template. The library's framework will do it based on the provided quantity equation.
    "},{"location":"users_guide/framework_basics/text_output/","title":"Text Output","text":"
    Besides providing dimensional analysis and unit conversions, the library also tries hard to print any quantity in the most user-friendly way. We can print the entire quantity or its selected parts (numerical value, unit, or dimension).
     
    Note
     
    The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
     
    In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
     
    For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
     
    Please let us know if you have a good idea of how to solve this issue.
    "},{"location":"users_guide/framework_basics/text_output/#predefined-symbols","title":"Predefined symbols","text":"
    The definitions of dimensions, units, prefixes, and constants require assigning text symbols for each entity. Those symbols will be composed by the library's framework to express dimensions and units of derived quantities.
     DimensionsUnitsPrefixesConstants 
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_mass final : base_dimension<\"M\"> {} dim_mass;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\ninline constexpr struct dim_electric_current final : base_dimension<\"I\"> {} dim_electric_current;\ninline constexpr struct dim_thermodynamic_temperature final : base_dimension<{u8\"\u0398\", \"O\"}> {} dim_thermodynamic_temperature;\ninline constexpr struct dim_amount_of_substance final : base_dimension<\"N\"> {} dim_amount_of_substance;\ninline constexpr struct dim_luminous_intensity final : base_dimension<\"J\"> {} dim_luminous_intensity;\n
     
    inline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\n\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\ninline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\ninline constexpr struct coulomb final : named_unit<\"C\", ampere * second> {} coulomb;\ninline constexpr struct volt final : named_unit<\"V\", watt / ampere> {} volt;\ninline constexpr struct farad final : named_unit<\"F\", coulomb / volt> {} farad;\ninline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    template<PrefixableUnit U> struct micro_ : prefixed_unit<{u8\"\u00b5\", \"u\"}, mag_power<10, -6>, U{}> {};\ntemplate<PrefixableUnit U> struct milli_ : prefixed_unit<\"m\", mag_power<10, -3>, U{}> {};\ntemplate<PrefixableUnit U> struct centi_ : prefixed_unit<\"c\", mag_power<10, -2>, U{}> {};\ntemplate<PrefixableUnit U> struct deci_  : prefixed_unit<\"d\", mag_power<10, -1>, U{}> {};\ntemplate<PrefixableUnit U> struct deca_  : prefixed_unit<\"da\", mag_power<10, 1>, U{}> {};\ntemplate<PrefixableUnit U> struct hecto_ : prefixed_unit<\"h\", mag_power<10, 2>, U{}> {};\ntemplate<PrefixableUnit U> struct kilo_  : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit U> struct mega_  : prefixed_unit<\"M\", mag_power<10, 6>, U{}> {};\n
     
    inline constexpr struct hyperfine_structure_transition_frequency_of_cs final : named_unit<{u8\"\u0394\u03bd_Cs\", \"dv_Cs\"}, mag<9'192'631'770> * hertz> {} hyperfine_structure_transition_frequency_of_cs;\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\ninline constexpr struct planck_constant final : named_unit<\"h\", mag_ratio<662'607'015, 100'000'000> * mag_power<10, -34> * joule * second> {} planck_constant;\ninline constexpr struct elementary_charge final : named_unit<\"e\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * coulomb> {} elementary_charge;\ninline constexpr struct boltzmann_constant final : named_unit<\"k\", mag_ratio<1'380'649, 1'000'000> * mag_power<10, -23> * joule / kelvin> {} boltzmann_constant;\ninline constexpr struct avogadro_constant final : named_unit<\"N_A\", mag_ratio<602'214'076, 100'000'000> * mag_power<10, 23> / mole> {} avogadro_constant;\ninline constexpr struct luminous_efficacy final : named_unit<\"K_cd\", mag<683> * lumen / watt> {} luminous_efficacy;\n
     
    Important
     
    Two symbols always have to be provided if the primary symbol contains characters outside of the basic literal character set. The first must be provided as a UTF-8 literal and may contain any Unicode characters. The second one must provide an alternative spelling and only use characters from within of basic literal character set.
     
    Note
     
    Unicode provides only a minimal set of characters available as subscripts, which are often used to differentiate various constants and quantities of the same kind. To workaround this issue, mp-units uses the '_' character to specify that the following characters should be considered a subscript of the symbol.
     
    Tip
     
    For older compilers, it might be required to specify a symbol_text class explicitly template name to initialize it with two symbols:
     
    inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-for-derived-entities","title":"Symbols for derived entities","text":""},{"location":"users_guide/framework_basics/text_output/#text_encoding","title":"text_encoding","text":"
    ISQ and SI standards always specify symbols using UTF-8 encoding. This is why it is a default and primary target for text output. However, in some applications or environments, a standard portable text output using only the characters from the basic literal character set can be preferred by users.
     
    This is why the library provides an option to change the default encoding to the portable one with:
     
    enum class text_encoding : std::int8_t {\n  utf8,       // \u00b5s; m\u00b3;  L\u00b2MT\u207b\u00b3\n  portable,   // us; m^3; L^2MT^-3\n  default_encoding = utf8\n};\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-derived-dimensions","title":"Symbols of derived dimensions","text":""},{"location":"users_guide/framework_basics/text_output/#dimension_symbol_formatting","title":"dimension_symbol_formatting","text":"
    dimension_symbol_formatting is a data type describing the configuration of the symbol generation algorithm.
     
    struct dimension_symbol_formatting {\n  text_encoding encoding = text_encoding::default_encoding;\n};\n
    "},{"location":"users_guide/framework_basics/text_output/#dimension_symbol","title":"dimension_symbol()","text":"
    Returns a std::string_view with the symbol of a dimension for the provided configuration:
     
    template<dimension_symbol_formatting fmt = dimension_symbol_formatting{}, typename CharT = char, Dimension D>\n[[nodiscard]] consteval std::string_view dimension_symbol(D);\n
     
    For example:
     
    static_assert(dimension_symbol<{.encoding = text_encoding::portable}>(isq::power.dimension) == \"L^2MT^-3\");\n
     
    Note
     
    std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned.
    "},{"location":"users_guide/framework_basics/text_output/#dimension_symbol_to","title":"dimension_symbol_to()","text":"
    Inserts the generated dimension symbol into the output text iterator at runtime.
     
    template<typename CharT = char, std::output_iterator<CharT> Out, Dimension D>\nconstexpr Out dimension_symbol_to(Out out, D d, dimension_symbol_formatting fmt = dimension_symbol_formatting{});\n
     
    For example:
     
    std::string txt;\ndimension_symbol_to(std::back_inserter(txt), isq::power.dimension, {.encoding = text_encoding::portable});\nstd::cout << txt << \"\\n\";\n
     
    The above prints:
     
    L^2MT^-3\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-derived-units","title":"Symbols of derived units","text":""},{"location":"users_guide/framework_basics/text_output/#unit_symbol_formatting","title":"unit_symbol_formatting","text":"
    unit_symbol_formatting is a data type describing the configuration of the symbol generation algorithm. It contains three orthogonal fields, each with a default value.
     
    enum class unit_symbol_solidus : std::int8_t {\n  one_denominator,  // m/s;   kg m\u207b\u00b9 s\u207b\u00b9\n  always,           // m/s;   kg/(m s)\n  never,            // m s\u207b\u00b9; kg m\u207b\u00b9 s\u207b\u00b9\n  default_denominator = one_denominator\n};\n\nenum class unit_symbol_separator : std::int8_t {\n  space,          // kg m\u00b2/s\u00b2\n  half_high_dot,  // kg\u22c5m\u00b2/s\u00b2  (valid only for utf8 encoding)\n  default_separator = space\n};\n\nstruct unit_symbol_formatting {\n  text_encoding encoding = text_encoding::default_encoding;\n  unit_symbol_solidus solidus = unit_symbol_solidus::default_denominator;\n  unit_symbol_separator separator = unit_symbol_separator::default_separator;\n};\n
     
    unit_symbol_solidus impacts how the division of unit symbols is being presented in the text output. By default, the '/' will be printed if only one unit component is in the denominator. Otherwise, the exponent syntax will be used.
     
    unit_symbol_separator specifies how multiple multiplied units should be separated from each other. By default, the space (' ') will be used as a separator.
    "},{"location":"users_guide/framework_basics/text_output/#unit_symbol","title":"unit_symbol()","text":"
    Returns a std::string_view with the symbol of a unit for the provided configuration:
     
    template<unit_symbol_formatting fmt = unit_symbol_formatting{}, typename CharT = char, Unit U>\n[[nodiscard]] consteval std::string_view unit_symbol(U);\n
     
    For example:
     
    static_assert(unit_symbol<{.solidus = unit_symbol_solidus::never,\n                           .separator = unit_symbol_separator::half_high_dot}>(kg * m / s2) == \"kg\u22c5m\u22c5s\u207b\u00b2\");\n
    "},{"location":"users_guide/framework_basics/text_output/#unit_symbol_to","title":"unit_symbol_to()","text":"
    Inserts the generated unit symbol into the output text iterator at runtime.
     
    template<typename CharT = char, std::output_iterator<CharT> Out, Unit U>\nconstexpr Out unit_symbol_to(Out out, U u, unit_symbol_formatting fmt = unit_symbol_formatting{});\n
     
    For example:
     
    std::string txt;\nunit_symbol_to(std::back_inserter(txt), kg * m / s2,\n               {.solidus = unit_symbol_solidus::never, .separator = unit_symbol_separator::half_high_dot});\nstd::cout << txt << \"\\n\";\n
     
    The above prints:
     
    kg\u22c5m\u22c5s\u207b\u00b2\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-scaled-units","title":"Symbols of scaled units","text":"
    In most cases scaled units are hidden behind named units. However, there are a few real-life where a user directly faces a scaled unit. For example:
     
    constexpr Unit auto L_per_100km = L / (mag<100> * km);\n
     
    The above is a derived unit of litre divided by a scaled unit of 100 kilometers. As we can see a scaled unit has a magnitude and a reference unit. To denote the scope of such a unit, we enclose it in [...]. For example, the following:
     
    std::cout << 6.7 * L_per_100km << \"\\n\";\n
     
    prints:
     
    6.7 L/[100 km]\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-common-units","title":"Symbols of common units","text":"
    Some common units expressed with a specialization of the common_unit class template need special printing rules for their symbols. As they represent a minimum set of equivalent common units resulting from the addition or subtraction of multiple quantities, we print all of them as a scaled version of the source unit. For example, the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\nstd::cout << 1 * rad + 1 * deg << \"\\n\";\n
     
    prints:
     
    40771 EQUIV{[1/25146 mi], [1/15625 km]}\n108167 EQUIV{[1/50292 mi], [1/57875 nmi]}\n23 EQUIV{[1/5 km/h], [1/18 m/s]}\n183.142 EQUIV{[1/\u03c0\u00b0], [1/180 rad]}\n
     
    Thanks to the above, it might be easier for the user to reason about the magnitude of the resulting unit and its impact on the value stored in the quantity.
     
    Note
     
    It is important to note that this output is provided only for intermediate results of the equations, as shown above. A user usually knows which unit should be used, and explicit conversion can be made to achieve that. For example:
     
    std::cout << (1 * km + 1 * mi).in<double>(km) << \"\\n\";\n
     
    prints:
     
    2.60934 km\n
    "},{"location":"users_guide/framework_basics/text_output/#space_before_unit_symbol-customization-point","title":"space_before_unit_symbol customization point","text":"
    The SI Brochure says:
     
    SI Brochure
     
    The numerical value always precedes the unit and a space is always used to separate the unit from the number. ... The only exceptions to this rule are for the unit symbols for degree, minute and second for plane angle, \u00b0, \u2032 and \u2033, respectively, for which no space is left between the numerical value and the unit symbol.
     
    There are more units with such properties. For example, percent (%) and per mille(\u2030).
     
    To support the above and other similar cases, the library exposes space_before_unit_symbol customization point. By default, its value is true for all the units, so the space between a number and a unit will be inserted in the output text. To change this behavior, we have to provide a partial specialization for a specific unit:
     
    template<>\nconstexpr bool space_before_unit_symbol<non_si::degree> = false;\n
     
    Note
     
    The above works only for the default formatting or for the format strings that use %? placement field (std::format(\"{}\", q) is equivalent to std::format(\"{:%N%?%U}\", q)).
     
    In case a user provides custom format specification (e.g., std::format(\"{:%N %U}\", q)), the library will always obey this specification for all the units (no matter what the actual value of the space_before_unit_symbol customization point is) and the separating space will always be used in this case.
    "},{"location":"users_guide/framework_basics/text_output/#output-streams","title":"Output streams","text":"
    Tip
     
    The output streaming support is opt-in and can be enabled by including the <mp-units/ostream.h> header file.
     
    The easiest way to print a dimension, unit, or quantity is to provide its object to the output stream:
     
    const QuantityOf<isq::speed> auto v1 = avg_speed(220. * km, 2 * h);\nconst QuantityOf<isq::speed> auto v2 = avg_speed(140. * mi, 2 * h);\nstd::cout << v1 << '\\n';            // 110 km/h\nstd::cout << v2 << '\\n';            // 70 mi/h\nstd::cout << v2.unit << '\\n';       // mi/h\nstd::cout << v2.dimension << '\\n';  // LT\u207b\u00b9\n
     
    The text output will always print the value using the default formatting for this entity.
     
    Important: Don't assume a unit
     
    Remember that when we deal with a quantity of an \"unknown\" (e.g., auto) type, it is a good practice to always convert the unit to the expected one before passing it to the text output:
     
    std::cout << v1.in(km / h) << '\\n';       // 110 km/h\nstd::cout << v1.force_in(m / s) << '\\n';  // 30.5556 m/s\n
    "},{"location":"users_guide/framework_basics/text_output/#output-stream-formatting","title":"Output stream formatting","text":"
    Only basic formatting can be applied to output streams. It includes control over width, fill, and alignment.
     
    The numerical value of the quantity will be printed according to the current stream state and standard manipulators may be used to customize that (assuming that the underlying representation type respects them).
     
    std::cout << \"|\" << std::setw(10) << 123 * m << \"|\\n\";                       // |     123 m|\nstd::cout << \"|\" << std::setw(10) << std::left << 123 * m << \"|\\n\";          // |123 m     |\nstd::cout << \"|\" << std::setw(10) << std::setfill('*') << 123 * m << \"|\\n\";  // |123 m*****|\n
     
    Note
     
    To have more control over the formatting of the quantity that is printed with the output stream just use std::cout << std::format(...).
    "},{"location":"users_guide/framework_basics/text_output/#text-formatting","title":"Text formatting","text":"
    The library provides custom formatters for std::format facility, which allows fine-grained control over what and how it is being printed in the text output.
     
    Tip
     
    The text formatting facility support is opt-in and can be enabled by including the <mp-units/format.h> header file.
    "},{"location":"users_guide/framework_basics/text_output/#controlling-width-fill-and-alignment","title":"Controlling width, fill, and alignment","text":"
    Formatting grammar for all the entities provides control over width, fill, and alignment. The C++ standard grammar tokens fill-and-align and width are being used. They treat the entity as a contiguous text to be aligned. For example, here are a few examples of the quantity numerical value and symbol formatting:
     
    std::println(\"|{:0}|\", 123 * m);     // |123 m|\nstd::println(\"|{:10}|\", 123 * m);    // |     123 m|\nstd::println(\"|{:<10}|\", 123 * m);   // |123 m     |\nstd::println(\"|{:>10}|\", 123 * m);   // |     123 m|\nstd::println(\"|{:^10}|\", 123 * m);   // |  123 m   |\nstd::println(\"|{:*<10}|\", 123 * m);  // |123 m*****|\nstd::println(\"|{:*>10}|\", 123 * m);  // |*****123 m|\nstd::println(\"|{:*^10}|\", 123 * m);  // |**123 m***|\n
     
    It is important to note that in the second line above, the quantity text is aligned to the right by default, which is consistent with the formatting of numeric types. Units and dimensions behave as text and, thus, are aligned to the left by default.
     
    Note
     
    std::println is a C++23 facility. In case we do not have access to C++23, we can obtain the same output with:
     
    std::cout << std::format(\"<format-string>\\n\", <format-args>);\n
    "},{"location":"users_guide/framework_basics/text_output/#dimension-formatting","title":"Dimension formatting","text":"
    dimension-format-spec = [fill-and-align], [width], [dimension-spec];\ndimension-spec        = [character-set];\ncharacter-set         = 'U' | 'P';\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • character-set token specifies the symbol text encoding:
         
      • U (default) uses the UTF-8 symbols defined by [@ISO80000] (e.g., LT\u207b\u00b2),
        •  
      • P forces non-standard portable output (e.g., LT^-2).
        •  
       
      •  
     
    Dimension symbols of some quantities are specified to use Unicode signs by the ISQ (e.g., \u0398 symbol for the thermodynamic temperature dimension). The library follows this by default. From the engineering point of view, sometimes Unicode text might not be the best solution, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the dimension symbol can be forced to be printed using such characters thanks to character-set token:
     
    std::println(\"{}\", isq::dim_thermodynamic_temperature);   // \u0398\nstd::println(\"{:P}\", isq::dim_thermodynamic_temperature); // O\nstd::println(\"{}\", isq::power.dimension);                 // L\u00b2MT\u207b\u00b3\nstd::println(\"{:P}\", isq::power.dimension);               // L^2MT^-3\n
    "},{"location":"users_guide/framework_basics/text_output/#unit-formatting","title":"Unit formatting","text":"
    unit-format-spec      = [fill-and-align], [width], [unit-spec];\nunit-spec             = [character-set], [unit-symbol-solidus], [unit-symbol-separator], [L]\n                      | [character-set], [unit-symbol-separator], [unit-symbol-solidus], [L]\n                      | [unit-symbol-solidus], [character-set], [unit-symbol-separator], [L]\n                      | [unit-symbol-solidus], [unit-symbol-separator], [character-set], [L]\n                      | [unit-symbol-separator], [character-set], [unit-symbol-solidus], [L]\n                      | [unit-symbol-separator], [unit-symbol-solidus], [character-set], [L];\nunit-symbol-solidus   = '1' | 'a' | 'n';\nunit-symbol-separator = 's' | 'd';\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • unit-symbol-solidus token specifies how the division of units should look like:
         
      • '1' (default) outputs / only when there is only one unit in the denominator, otherwise   negative exponents are printed (e.g., m/s, kg m\u207b\u00b9 s\u207b\u00b9)
        •  
      • 'a' always uses solidus (e.g., m/s, kg/(m s))
        •  
      • 'n' never prints solidus, which means that negative exponents are always used   (e.g., m s\u207b\u00b9, kg m\u207b\u00b9 s\u207b\u00b9)
        •  
       
      •  
    • unit-symbol-separator token specifies how multiplied unit symbols should be separated:
         
      • 's' (default) uses space as a separator (e.g., kg m\u00b2/s\u00b2)
        •  
      • 'd' uses half-high dot (\u22c5) as a separator (e.g., kg\u22c5m\u00b2/s\u00b2) (requires the UTF-8 encoding)
        •  
       
      •  
    • 'L' is reserved for possible future localization use in case the C++ standard library gets access to   the ICU-like database.
      •  
     
    Note
     
    The above grammar intended that the elements of unit-spec can appear in any order as they have unique characters. Users shouldn't have to remember the order of those tokens to control the formatting of a unit symbol.
     
    Unit symbols of some quantities are specified to use Unicode signs by the SI (e.g., \u03a9 symbol for the resistance quantity). The library follows this by default. From the engineering point of view, Unicode text might not be the best solution sometimes, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the unit symbol can be forced to be printed using such characters thanks to character-set token:
     
    std::println(\"{}\", si::ohm);      // \u03a9\nstd::println(\"{:P}\", si::ohm);    // ohm\nstd::println(\"{}\", us);           // \u00b5s\nstd::println(\"{:P}\", us);         // us\nstd::println(\"{}\", m / s2);       // m/s\u00b2\nstd::println(\"{:P}\", m / s2);     // m/s^2\n
     
    Additionally, both ISO 80000 and SI leave some freedom on how to print unit symbols. This is why two additional tokens were introduced.
     
    unit-symbol-solidus specifies how the division of units should look like. By default, / will be used only when the denominator contains only one unit. However, with the 'a' or 'n' options, we can force the facility to print the / character always (even when there are more units in the denominator), or never, in which case a parenthesis will be added to enclose all denominator units.
     
    std::println(\"{}\", m / s);          // m/s\nstd::println(\"{}\", kg / m / s2);    // kg m\u207b\u00b9 s\u207b\u00b2\nstd::println(\"{:a}\", m / s);        // m/s\nstd::println(\"{:a}\", kg / m / s2);  // kg/(m s\u00b2)\nstd::println(\"{:n}\", m / s);        // m s\u207b\u00b9\nstd::println(\"{:n}\", kg / m / s2);  // kg m\u207b\u00b9 s\u207b\u00b2\n
     
    The unit-symbol-separator token allows us to obtain the following outputs:
     
    std::println(\"{}\", kg * m2 / s2);    // kg m\u00b2/s\u00b2\nstd::println(\"{:d}\", kg * m2 / s2);  // kg\u22c5m\u00b2/s\u00b2\n
     
    Note
     
    'd' requires the UTF-8 encoding to be set.
    "},{"location":"users_guide/framework_basics/text_output/#quantity-formatting","title":"Quantity formatting","text":"
    quantity-format-spec        = [fill-and-align], [width], [quantity-specs], [defaults-specs];\nquantity-specs              = conversion-spec;\n                            | quantity-specs, conversion-spec;\n                            | quantity-specs, literal-char;\nliteral-char                = ? any character other than '{', '}', or '%' ?;\nconversion-spec             = '%', placement-type;\nplacement-type              = subentity-id | '?' | '%';\ndefaults-specs              = ':', default-spec-list;\ndefault-spec-list           = default-spec;\n                            | default-spec-list, default-spec;\ndefault-spec                = subentity-id, '[' format-spec ']';\nsubentity-id                = 'N' | 'U' | 'D';\nformat-spec                 = ? as specified by the formatter for the argument type ?;\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • placement-type token specifies which entity should be put and where:
         
      • 'N' inserts a default-formatted numerical value of the quantity,
        •  
      • 'U' inserts a default-formatted unit of the quantity,
        •  
      • 'D' inserts a default-formatted dimension of the quantity,
        •  
      • '?' inserts an optional separator between the number and a unit based on the value of   space_before_unit_symbol for this unit,
        •  
      • '%' just inserts '%' character.
        •  
       
      •  
    • defaults-specs token allows overwriting defaults for the underlying formatters with the custom   format string. Each override starts with a subentity identifier ('N', 'U', or 'D') followed by   the format string enclosed in square brackets.
      •  
    "},{"location":"users_guide/framework_basics/text_output/#default-formatting","title":"Default formatting","text":"
    To format quantity values, the formatting facility uses quantity-format-spec. If left empty, the default formatting is applied. The same default formatting is also applied to the output streams. This is why the following code lines produce the same output:
     
    std::cout << \"Distance: \" << 123 * km << \"\\n\";\nstd::cout << std::format(\"Distance: {}\\n\", 123 * km);\nstd::cout << std::format(\"Distance: {:%N%?%U}\\n\", 123 * km);\n
     
    Note
     
    For some quantities, the {:%N %U} format may provide a different output than the default one, as some units have space_before_unit_symbol customization point explicitly set to false (e.g., % and \u00b0).
    "},{"location":"users_guide/framework_basics/text_output/#quantity-numerical-value-unit-symbol-or-both","title":"Quantity numerical value, unit symbol, or both?","text":"
    Thanks to the grammar provided above, the user can easily decide to either:
     
       
    •  
      print a whole quantity:
       
      std::println(\"Speed: {}\", 120 * km / h);\n
       
      Speed: 120 km/h\n
       
      •  
    •  
      provide custom quantity formatting:
       
      std::println(\"Speed: {:%N in %U}\", 120 * km / h);\n
       
      Speed: 120 in km/h\n
       
      •  
    •  
      provide custom formatting for components:
       
      std::println(\"Speed: {::N[.2f]U[n]}\", 100. * km / (3 * h));\n
       
      Speed: 33.33 km h\u207b\u00b9\n
       
      •  
    •  
      print only specific components (numerical value, unit, or dimension):
       
      std::println(\"Speed:\\n- number: {0:%N}\\n- unit: {0:%U}\\n- dimension: {0:%D}\", 120 * km / h);\n
       
      Speed:\n- number: 120\n- unit: km/h\n- dimension: LT\u207b\u00b9\n
       
      •  
    "},{"location":"users_guide/framework_basics/text_output/#formatting-of-the-quantity-numerical-value","title":"Formatting of the quantity numerical value","text":"
    The representation type used as a numerical value of a quantity must provide its own formatter specialization. It will be called by the quantity formatter with the format-spec provided by the user in the N defaults specification.
     
    In case we use C++ fundamental arithmetic types with our quantities the standard formatter specified in format.string.std will be used. The rest of this chapter assumes that it is the case and provides some usage examples.
     
    sign token allows us to specify how the value's sign is being printed:
     
    std::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", 1 * m);   // 1 m,+1 m,1 m, 1 m\nstd::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", -1 * m);  // -1 m,-1 m,-1 m,-1 m\n
     
    where:
     
       
    • + indicates that a sign should be used for both non-negative and negative numbers,
      •  
    • - indicates that a sign should be used for negative numbers and negative zero only   (this is the default behavior),
      •  
    • <space> indicates that a leading space should be used for non-negative numbers other   than negative zero, and a minus sign for negative numbers and negative zero.
      •  
     
    precision token is allowed only for floating-point representation types:
     
    std::println(\"{::N[.0]}\", 1.2345 * m);   // 1 m\nstd::println(\"{::N[.1]}\", 1.2345 * m);   // 1 m\nstd::println(\"{::N[.2]}\", 1.2345 * m);   // 1.2 m\nstd::println(\"{::N[.3]}\", 1.2345 * m);   // 1.23 m\nstd::println(\"{::N[.0f]}\", 1.2345 * m);  // 1 m\nstd::println(\"{::N[.1f]}\", 1.2345 * m);  // 1.2 m\nstd::println(\"{::N[.2f]}\", 1.2345 * m);  // 1.23 m\n
     
    type specifies how a value of the representation type is being printed. For integral types:
     
    std::println(\"{::N[b]}\", 42 * m);    // 101010 m\nstd::println(\"{::N[B]}\", 42 * m);    // 101010 m\nstd::println(\"{::N[d]}\", 42 * m);    // 42 m\nstd::println(\"{::N[o]}\", 42 * m);    // 52 m\nstd::println(\"{::N[x]}\", 42 * m);    // 2a m\nstd::println(\"{::N[X]}\", 42 * m);    // 2A m\n
     
    The above can be printed in an alternate version thanks to the # token:
     
    std::println(\"{::N[#b]}\", 42 * m);   // 0b101010 m\nstd::println(\"{::N[#B]}\", 42 * m);   // 0B101010 m\nstd::println(\"{::N[#o]}\", 42 * m);   // 052 m\nstd::println(\"{::N[#x]}\", 42 * m);   // 0x2a m\nstd::println(\"{::N[#X]}\", 42 * m);   // 0X2A m\n
     
    For floating-point values, the type token works as follows:
     
    std::println(\"{::N[a]}\",   1.2345678 * m);      // 1.3c0ca2a5b1d5dp+0 m\nstd::println(\"{::N[.3a]}\", 1.2345678 * m);      // 1.3c1p+0 m\nstd::println(\"{::N[A]}\",   1.2345678 * m);      // 1.3C0CA2A5B1D5DP+0 m\nstd::println(\"{::N[.3A]}\", 1.2345678 * m);      // 1.3C1P+0 m\nstd::println(\"{::N[e]}\",   1.2345678 * m);      // 1.234568e+00 m\nstd::println(\"{::N[.3e]}\", 1.2345678 * m);      // 1.235e+00 m\nstd::println(\"{::N[E]}\",   1.2345678 * m);      // 1.234568E+00 m\nstd::println(\"{::N[.3E]}\", 1.2345678 * m);      // 1.235E+00 m\nstd::println(\"{::N[g]}\",   1.2345678 * m);      // 1.23457 m\nstd::println(\"{::N[g]}\",   1.2345678e8 * m);    // 1.23457e+08 m\nstd::println(\"{::N[.3g]}\", 1.2345678 * m);      // 1.23 m\nstd::println(\"{::N[.3g]}\", 1.2345678e8 * m);    // 1.23e+08 m\nstd::println(\"{::N[G]}\",   1.2345678 * m);      // 1.23457 m\nstd::println(\"{::N[G]}\",   1.2345678e8 * m);    // 1.23457E+08 m\nstd::println(\"{::N[.3G]}\", 1.2345678 * m);      // 1.23 m\nstd::println(\"{::N[.3G]}\", 1.2345678e8 * m);    // 1.23E+08 m\n
    "},{"location":"users_guide/framework_basics/the_affine_space/","title":"The Affine Space","text":"
    The affine space has two types of entities:
     
       
    • Point - a position specified with coordinate values (e.g., location, address, etc.)
      •  
    • Displacement vector - the difference between two points (e.g., shift, offset,   displacement, duration, etc.)
      •  
     
    In the following subchapters, we will often refer to displacement vectors simply as vectors for brevity.
     
    Note
     
    The displacement vector described here is specific to the affine space theory and is not the same thing as the quantity of a vector character that we discussed in the \"Scalars, vectors, and tensors\" chapter (although, in some cases, those terms may overlap).
    "},{"location":"users_guide/framework_basics/the_affine_space/#operations-in-the-affine-space","title":"Operations in the affine space","text":"
    Here are the primary operations one can do in the affine space:
     
       
    • vector + vector -> vector
      •  
    • vector - vector -> vector
      •  
    • -vector -> vector
      •  
    • vector * scalar -> vector
      •  
    • scalar * vector -> vector
      •  
    • vector / scalar -> vector
      •  
    • point - point -> vector
      •  
    • point + vector -> point
      •  
    • vector + point -> point
      •  
    • point - vector -> point
      •  
     
    Important
     
    It is not possible to:
     
       
    • add two points,
      •  
    • subtract a point from a vector,
      •  
    • multiply nor divide points with anything else.
      •  
    "},{"location":"users_guide/framework_basics/the_affine_space/#points-are-more-common-than-most-of-us-imagine","title":"Points are more common than most of us imagine","text":"
    Point abstractions should be used more often in the C++ software. They are not only about temperature or time. Points are everywhere around us and should become more popular in the products we implement. They can be used to implement:
     
       
    • temperature points,
      •  
    • timestamps,
      •  
    • daily mass readouts from the scale,
      •  
    • altitudes of mountain peaks on a map,
      •  
    • current path length measured by the car's odometer,
      •  
    • today's price of instruments on the market,
      •  
    • and many more.
      •  
     
    Improving the affine space's Points intuition will allow us to write better and safer software.
    "},{"location":"users_guide/framework_basics/the_affine_space/#displacement-vector-is-modeled-by-quantity","title":"Displacement vector is modeled by quantity","text":"
    Up until now, each time we used a quantity in our code, we were modeling some kind of a difference between two things:
     
       
    • the distance between two points,
      •  
    • duration between two time points,
      •  
    • the difference in speed (even if relative to zero).
      •  
     
    As we already know, a quantity type provides all operations required for a displacement vector abstraction in the affine space. It can be constructed with:
     
       
    • the multiply syntax (works for most of the units),
      •  
    • delta<Reference> construction helper (e.g., delta<isq::height[m]>(42), delta<deg_C>(3)),
      •  
    • two-parameter constructor taking a number and a quantity reference/unit.
      •  
     
    Note
     
    The multiply syntax support is disabled for units that provide a point origin in their definition (i.e., units of temperature like K, deg_C, and deg_F).
    "},{"location":"users_guide/framework_basics/the_affine_space/#point-is-modeled-by-quantity_point-and-pointorigin","title":"Point is modeled by quantity_point and PointOrigin","text":"
    In the mp-units library, the Point abstraction is modelled by:
     
       
    • PointOrigin concept that specifies measurement origin, and
      •  
    • quantity_point class template that specifies a Point relative to a specific predefined origin.
      •  
    "},{"location":"users_guide/framework_basics/the_affine_space/#quantity_point","title":"quantity_point","text":"
    The quantity_point class template specifies an absolute quantity measured from a predefined origin:
     
    template<Reference auto R,\n         PointOriginFor<get_quantity_spec(R)> auto PO = default_point_origin(R),\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity_point;\n
     
    As we can see above, the quantity_point class template exposes one additional parameter compared to quantity. The PO parameter satisfies a PointOriginFor concept and specifies the origin of our measurement scale.
     
    Each quantity_point internally stores a quantity object, which represents a displacement vector from the predefined origin. Thanks to this, an instantiation of a quantity_point can be considered as a model of a vector space from such an origin.
     
    Forcing the user to manually predefine an origin for every domain may be cumbersome and discourage users from using such abstractions at all. This is why, by default, the PO template parameter is initialized with the default_point_origin(R) that provides the quantity points' scale zeroth point using the following rules:
     
       
    • if the measurement unit of a quantity specifies its point origin in its definition   (e.g., degree Celsius), then this origin is being used,
      •  
    • otherwise, an instantiation of zeroth_point_origin<QuantitySpec> is being used which   provides a well-established zeroth point for a specific quantity type.
      •  
     
    Quantity points with default point origins may be constructed with the point construction helper or forcing an explicit conversion from the quantity:
     
    // quantity_point qp1 = 42 * m;           // Compile-time error\n// quantity_point qp2 = 42 * K;           // Compile-time error\n// quantity_point qp3 = delta<deg_C>(42); // Compile-time error\nquantity_point qp4(42 * m);\nquantity_point qp5(42 * K);\nquantity_point qp6(delta<deg_C>(42));\nquantity_point qp7 = point<m>(42);\nquantity_point qp8 = point<K>(42);\nquantity_point qp9 = point<deg_C>(42);\n
     
    Tip
     
    The quantity_point definition can be found in the mp-units/quantity_point.h header file.
    "},{"location":"users_guide/framework_basics/the_affine_space/#zeroth_point_originquantityspec","title":"zeroth_point_origin<QuantitySpec>","text":"
    zeroth_point_origin<QuantitySpec> is meant to be used in cases where the specific domain has a well-established, non-controversial, and unique zeroth point on the measurement scale. This saves the user from the need to write a boilerplate code that would predefine such a type for this domain.
     
     
    quantity_point<isq::distance[si::metre]> qp1(100 * m);\nquantity_point<isq::distance[si::metre]> qp2 = point<m>(120);\n\nassert(qp1.quantity_from_zero() == 100 * m);\nassert(qp2.quantity_from_zero() == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\n// auto res = qp1 + qp2;   // Compile-time error\n
     
    In the above code 100 * m and 120 * m still create two quantities that serve as displacement vectors here. Quantity point objects can be explicitly constructed from such quantities only when their origin is an instantiation of the zeroth_point_origin<QuantitySpec>.
     
    It is really important to understand that even though we can use .quantity_from_zero() to obtain the displacement vector of a point from the origin, the point by itself does not represent or have any associated physical value. It is just a point in some space. The same point can be expressed with different displacement vectors from different origins.
     
    It is also worth mentioning that simplicity comes with a safety cost here. For some users, it might be surprising that the usage of zeroth_point_origin<QuantitySpec> makes various quantity point objects compatible as long as quantity types used in the origin and reference are compatible:
     
    quantity_point<si::metre> qp1{isq::distance(100 * m)};\nquantity_point<si::metre> qp2 = point<isq::height[m]>(120);\n\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#absolute-point-origin","title":"Absolute point origin","text":"
    In cases where we want to implement an isolated independent space in which points are not compatible with other spaces, even of the same quantity type, we should manually predefine an absolute point origin.
     
     
    inline constexpr struct origin final : absolute_point_origin<isq::distance> {} origin;\n\n// quantity_point<si::metre, origin> qp1{100 * m};        // Compile-time error\n// quantity_point<si::metre, origin> qp2{delta<m>(120)};  // Compile-time error\nquantity_point<si::metre, origin> qp1 = origin + 100 * m;\nquantity_point<si::metre, origin> qp2 = 120 * m + origin;\n\n// assert(qp1.quantity_from_zero() == 100 * m);   // Compile-time error\n// assert(qp2.quantity_from_zero() == 120 * m);   // Compile-time error\nassert(qp1.quantity_from(origin) == 100 * m);\nassert(qp2.quantity_from(origin) == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp1 - origin == 100 * m);\nassert(qp2 - origin == 120 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\nassert(origin - qp1 == -100 * m);\nassert(origin - qp2 == -120 * m);\n\n// assert(origin - origin == 0 * m);   // Compile-time error\n
     
    We can't construct a quantity point directly from the quantity anymore when a custom, named origin is used. To prevent potential safety and maintenance issues, we always need to explicitly provide both a compatible origin and a quantity measured from it to construct a quantity point.
     
    Said otherwise, a quantity point defined in terms of a specific origin is the result of adding the origin and the displacement vector measured from it to the point we create.
     
    Info
     
    A rationale for this longer construction syntax can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
     
    Similarly to creation of a quantity, if someone does not like the operator-based syntax to create a quantity_point, the same results can be achieved with a two-parameter constructor:
     
    quantity_point qp1{100 * m, origin};\n
     
    Again, CTAD always helps to use precisely the type we need in a current case.
     
    Additionally, if a quantity point is defined in terms of a custom, named origin, then we can't use a quantity_from_zero() member function anymore. This is to prevent surprises, as our origin may not necessarily be perceived as an absolute zero in the domain we model. Also, as we will learn soon, we can define several related origins in one space, and then it gets harder to understand which one is the \"zero\" one. This is why, to be specific and always correct about the points we use, a quantity_from(QP) member function can be used (where QP can either be an origin or another quantity point).
     
    Finally, please note that it is not allowed to subtract two point origins defined in terms of absolute_point_origin (e.g., origin - origin) as those do not contain information about the unit, so we cannot determine a resulting quantity type.
    "},{"location":"users_guide/framework_basics/the_affine_space/#modeling-independent-spaces-in-one-domain","title":"Modeling independent spaces in one domain","text":"
    Absolute point origins are also perfect for establishing independent spaces even if the same quantity type and unit is being used:
     
     
    inline constexpr struct origin1 final : absolute_point_origin<isq::distance> {} origin1;\ninline constexpr struct origin2 final : absolute_point_origin<isq::distance> {} origin2;\n\nquantity_point qp1 = origin1 + 100 * m;\nquantity_point qp2 = origin2 + 120 * m;\n\nassert(qp1.quantity_from(origin1) == 100 * m);\nassert(qp2.quantity_from(origin2) == 120 * m);\n\nassert(qp1 - origin1 == 100 * m);\nassert(qp2 - origin2 == 120 * m);\nassert(origin1 - qp1 == -100 * m);\nassert(origin2 - qp2 == -120 * m);\n\n// assert(qp2 - qp1 == 20 * m);                    // Compile-time error\n// assert(qp1 - origin2 == 100 * m);               // Compile-time error\n// assert(qp2 - origin1 == 120 * m);               // Compile-time error\n// assert(qp2.quantity_from(qp1) == 20 * m);       // Compile-time error\n// assert(qp1.quantity_from(origin2) == 100 * m);  // Compile-time error\n// assert(qp2.quantity_from(origin1) == 120 * m);  // Compile-time error\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#relative-point-origin","title":"Relative Point origin","text":"
    We often do not have only one ultimate \"zero\" point when we measure things. Often, we have one common scale, but we measure various quantities relative to different points and expect those points to be compatible. There are many examples here, but probably the most common are temperatures, timestamps, and altitudes.
     
    For such cases, relative point origins should be used:
     
     
    inline constexpr struct A final : absolute_point_origin<isq::distance> {} A;\ninline constexpr struct B final : relative_point_origin<A + 10 * m> {} B;\ninline constexpr struct C final : relative_point_origin<B + 10 * m> {} C;\ninline constexpr struct D final : relative_point_origin<A + 30 * m> {} D;\n\nquantity_point qp1 = C + 100 * m;\nquantity_point qp2 = D + 120 * m;\n\nassert(qp1.quantity_ref_from(qp1.point_origin) == 100 * m);\nassert(qp2.quantity_ref_from(qp2.point_origin) == 120 * m);\n\nassert(qp2.quantity_from(qp1) == 30 * m);\nassert(qp1.quantity_from(qp2) == -30 * m);\nassert(qp2 - qp1 == 30 * m);\nassert(qp1 - qp2 == -30 * m);\n\nassert(qp1.quantity_from(A) == 120 * m);\nassert(qp1.quantity_from(B) == 110 * m);\nassert(qp1.quantity_from(C) == 100 * m);\nassert(qp1.quantity_from(D) == 90 * m);\nassert(qp1 - A == 120 * m);\nassert(qp1 - B == 110 * m);\nassert(qp1 - C == 100 * m);\nassert(qp1 - D == 90 * m);\n\nassert(qp2.quantity_from(A) == 150 * m);\nassert(qp2.quantity_from(B) == 140 * m);\nassert(qp2.quantity_from(C) == 130 * m);\nassert(qp2.quantity_from(D) == 120 * m);\nassert(qp2 - A == 150 * m);\nassert(qp2 - B == 140 * m);\nassert(qp2 - C == 130 * m);\nassert(qp2 - D == 120 * m);\n\nassert(B - A == 10 * m);\nassert(C - A == 20 * m);\nassert(D - A == 30 * m);\nassert(D - C == 10 * m);\n\nassert(B - B == 0 * m);\n// assert(A - A == 0 * m);  // Compile-time error\n
     
    Note
     
    Even though we can't subtract two absolute point origins from each other, it is possible to subtract relative ones or relative and absolute ones.
    "},{"location":"users_guide/framework_basics/the_affine_space/#converting-between-different-representations-of-the-same-point","title":"Converting between different representations of the same point","text":"
    As we might represent the same point with displacement vectors from various origins, the library provides facilities to convert the same point to the quantity_point class templates expressed in terms of different origins.
     
     
    For this purpose, we can use either:
     
       
    •  
      A converting constructor:
       
      quantity_point<si::metre, C> qp2C = qp2;\nassert(qp2C.quantity_ref_from(qp2C.point_origin) == 130 * m);\n
       
      •  
    •  
      A dedicated conversion interface:
       
      quantity_point qp2B = qp2.point_for(B);\nquantity_point qp2A = qp2.point_for(A);\n\nassert(qp2B.quantity_ref_from(qp2B.point_origin) == 140 * m);\nassert(qp2A.quantity_ref_from(qp2A.point_origin) == 150 * m);\n
       
      •  
     
    It is important to understand that all such translations still describe exactly the same point (e.g., all of them compare equal):
     
    assert(qp2 == qp2C);\nassert(qp2 == qp2B);\nassert(qp2 == qp2A);\n
     
    Important
     
    It is only allowed to convert between various origins defined in terms of the same absolute_point_origin. Even if it is possible to express the same point as a displacement vector from another absolute_point_origin, the library will not provide such a conversion. A custom user-defined conversion function will be needed to add such a functionality.
     
    Said another way, in the library, there is no way to spell how two distinct absolute_point_origin types relate to each other.
    "},{"location":"users_guide/framework_basics/the_affine_space/#temperature-support","title":"Temperature support","text":"
    Support for temperature quantity points is probably one of the most common examples of relative point origins in action that we use in daily life.
     
    The SI definition in the library provides a few predefined point origins for this purpose:
     
    namespace si {\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\n\ninline constexpr struct ice_point final : relative_point_origin<point<milli<kelvin>>(273'150)}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\n\n}\n\nnamespace usc {\n\ninline constexpr struct zeroth_degree_Fahrenheit final :\n  relative_point_origin<point<mag_ratio<5, 9> * si::degree_Celsius>(-32)> {} zeroth_degree_Fahrenheit;\n\n}\n
     
    The above is a great example of how point origins can be stacked on top of each other:
     
       
    • usc::zeroth_degree_Fahrenheit is defined relative to si::zeroth_degree_Celsius
      •  
    • si::zeroth_degree_Celsius is defined relative to si::zeroth_kelvin.
      •  
     
    Note
     
    Notice that while stacking point origins, we can use different representation types and units for origins and a point. In the above example, the relative point origin for degree Celsius is defined in terms of si::kelvin, while the quantity point for it will use si::degree_Celsius as a unit.
     
    The temperature point origins defined above are provided explicitly in the respective units' definitions:
     
    namespace si {\n\ninline constexpr struct kelvin final :\n    named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\ninline constexpr struct degree_Celsius final :\n    named_unit<{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n\n}\n\nnamespace usc {\n\ninline constexpr struct degree_Fahrenheit final :\n    named_unit<{u8\"\u2109\", \"`F\"}, mag_ratio<5, 9> * si::degree_Celsius,\n               zeroth_degree_Fahrenheit> {} degree_Fahrenheit;\n\n}\n
     
    As it was described above, default_point_origin(R) returns a zeroth_point_origin<QuantitySpec> when a unit does not provide any origin in its definition. As of today, the units of temperature are the only ones in the entire mp-units library that provide such origins.
     
    Now, let's see how we can benefit from the above definitions. We have quite a few alternatives to choose from here. Depending on our needs or tastes, we can:
     
       
    •  
      be explicit about the unit and origin:
       
      quantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q1 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q2{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q3{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q4 = point<deg_C>(20.5);\n
       
      •  
    •  
      specify a unit and use its zeroth point origin implicitly:
       
      quantity_point<si::degree_Celsius> q5 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius> q6{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius> q7{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius> q8 = point<deg_C>(20.5);\n
       
      •  
    •  
      benefit from CTAD:
       
      quantity_point q9 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point q10{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point q11{delta<deg_C>(20.5)};\nquantity_point q12 = point<deg_C>(20.5);\n
       
      •  
     
    In all of the above cases, we end up with the quantity_point of the same type and value.
     
    To play a bit more with temperatures, we can implement a simple room AC temperature controller in the following way:
     
     
    constexpr struct room_reference_temp final : relative_point_origin<point<deg_C>(21)> {} room_reference_temp;\nusing room_temp = quantity_point<isq::Celsius_temperature[deg_C], room_reference_temp>;\n\nconstexpr auto step_delta = delta<isq::Celsius_temperature<deg_C>>(0.5);\nconstexpr int number_of_steps = 6;\n\nroom_temp room_ref{};\nroom_temp room_low = room_ref - number_of_steps * step_delta;\nroom_temp room_high = room_ref + number_of_steps * step_delta;\n\nstd::println(\"Room reference temperature: {} ({}, {::N[.2f]})\\n\",\n             room_ref.quantity_from_zero(),\n             room_ref.in(usc::degree_Fahrenheit).quantity_from_zero(),\n             room_ref.in(si::kelvin).quantity_from_zero());\n\nstd::println(\"| {:<18} | {:^18} | {:^18} | {:^18} |\",\n             \"Temperature delta\", \"Room reference\", \"Ice point\", \"Absolute zero\");\nstd::println(\"|{0:=^20}|{0:=^20}|{0:=^20}|{0:=^20}|\", \"\");\n\nauto print_temp = [&](std::string_view label, auto v) {\n  std::println(\"| {:<14} | {:^18} | {:^18} | {:^18:N[.2f]} |\", label,\n               v - room_reference_temp, (v - si::ice_point).in(deg_C), (v - si::absolute_zero).in(deg_C));\n};\n\nprint_temp(\"Lowest\", room_low);\nprint_temp(\"Default\", room_ref);\nprint_temp(\"Highest\", room_high);\n
     
    The above prints:
     
    Room reference temperature: 21 \u2103 (69.8 \u2109, 294.15 K)\n\n| Temperature delta  |   Room reference   |     Ice point      |   Absolute zero    |\n|====================|====================|====================|====================|\n| Lowest             |       -3 \u2103        |       18 \u2103        |     291.15 \u2103      |\n| Default            |        0 \u2103        |       21 \u2103        |     294.15 \u2103      |\n| Highest            |        3 \u2103        |       24 \u2103        |     297.15 \u2103      |\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#no-text-output-for-points","title":"No text output for Points","text":"
    The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
     
    In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
     
    For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
    "},{"location":"users_guide/framework_basics/the_affine_space/#the-affine-space-is-about-type-safety","title":"The affine space is about type-safety","text":"
    The following operations are not allowed in the affine space:
     
       
    • adding two quantity_point objects
         
      • It is physically impossible to add positions of home and Denver airports.
        •  
       
      •  
    • subtracting a quantity_point from a quantity
         
      • What would it mean to subtract the DEN airport location from the distance to it?
        •  
       
      •  
    • multiplying/dividing a quantity_point with a scalar
         
      • What is the position of 2 * DEN airport location?
        •  
       
      •  
    • multiplying/dividing a quantity_point with a quantity
         
      • What would multiplying the distance with the DEN airport location mean?
        •  
       
      •  
    • multiplying/dividing two quantity_point objects
         
      • What would multiplying home and DEN airport location mean?
        •  
       
      •  
    • mixing quantity_points of different quantity kinds
         
      • It is physically impossible to subtract time from length.
        •  
       
      •  
    • mixing quantity_points of inconvertible quantities
         
      • What does subtracting a distance point to DEN airport from the Mount Everest base camp   altitude mean?
        •  
       
      •  
    • mixing quantity_points of convertible quantities but with unrelated origins
         
      • How do we subtract a point on our trip to CppCon measured relatively to our home location from   a point measured relative to the center of the Solar System?
        •  
       
      •  
     
    Important: The affine space improves safety
     
    The usage of quantity_point and affine space types, in general, improves expressiveness and type-safety of the code we write.
    "},{"location":"users_guide/framework_basics/value_conversions/","title":"Value Conversions","text":"
    One of the most important features of every unit library is to provide support for compile-time-enabled conversions of a numerical value of a quantity.
     
    A numerical value of a quantity depends on two elements:
     
       
    • quantity representation type (e.g., int, double) that stores the number expressing the amount   of quantity,
      •  
    • unit in which the quantity is being measured.
      •  
     
    Changing any of the above may require changing the value stored in a quantity.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-preserving-conversions","title":"Value-preserving conversions","text":"
    auto q1 = 5 * km;\nstd::cout << q1.in(m) << '\\n';\nquantity<si::metre, int> q2 = q1;\n
     
    The second line above converts the current quantity to the one expressed in meters and prints its contents. The third line converts the quantity expressed in kilometers into the one measured in meters.
     
    In case a user would like to perform an opposite transformation:
     
    auto q1 = 5 * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1;\n
     
    Both conversions will fail to compile.
     
    There are two ways to make the above work. The first solution is to use a floating-point representation type:
     
    auto q1 = 5. * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;\n
     
    or
     
    auto q1 = 5 * m;\nstd::cout << value_cast<double>(q1).in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;  // double by default\n
     
    Important
     
    The mp-units library follows std::chrono::duration logic and treats floating-point types as value-preserving.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-truncating-conversions","title":"Value-truncating conversions","text":"
    The second solution is to force a truncating conversion:
     
    auto q1 = 5 * m;\nstd::cout << value_cast<km>(q1) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1.force_in(km);\n
     
    This explicit cast makes it clear that something unsafe is going on. It is easy to spot in code reviews or while chasing a bug in the source code.
     
    Note
     
    q.force_in(U) is just a shortcut to run value_cast<U>(q). There is no difference in behavior between those two interfaces. q.force_in(U) was added for consistency with q.in(U) and q.force_numerical_value_in(U).
     
    Another place where this cast is useful is when a user wants to convert a quantity with a floating-point representation to the one using an integral one. Again, this is a truncating conversion, so an explicit cast is needed:
     
    quantity<si::metre, int> q3 = value_cast<int>(3.14 * m);\n
     
    Info
     
    It is often OK to use an integral as a representation type, but in general, floating-point types provide better precision and are privileged in the library as they are considered to be value-preserving.
     
    In some cases, a unit and a representation type should be changed simultaneously. Moreover, sometimes, the order of doing those operations matters. In such cases, the library provides the value_cast<U, Rep>(q) which always returns the most precise result:
     C++23C++20Portable 
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<currency, dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\nQUANTITY_SPEC(currency, dim_currency);\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    using namespace unit_symbols;\nPrice price{12.95 * USD};\nScaled spx = value_cast<USD_s, std::int64_t>(price);\n
     
    As a shortcut, instead of providing a unit and a representation type to value_cast, you may also provide a Quantity type directly, from which unit and representation type are taken. However, value_cast<Quantity>, still only allows for changes in unit and representation type, but not changing the type of the quantity. For that, you will have to use a quantity_cast instead.
     
    Overloads are also provided for instances of quantity_point. All variants of value_cast<...>(q) that apply to instances of quantity have a corresponding version applicable to quantity_point, where the point_origin remains untouched, and the cast changes how the \"offset\" from the origin is represented. Specifically, for any quantity_point instance qp, all of the following equivalences hold:
     
    static_assert(value_cast<Rep>(qp) == quantity_point{value_cast<Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U>(qp) == quantity_point{value_cast<U>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U, Rep>(qp) == quantity_point{value_cast<U, Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<Q>(qp) == quantity_point{value_cast<Q>(qp.quantity_from(qp.point_origin)), qp.point_origin});\n
     
    Furthermore, there is one additional overload value_cast<ToQP>(qp). This overload permits to additionally replace the point_origin with another compatible one, while still representing the same point in the affine space. Thus, it is roughly equivalent to value_cast<ToQP::unit, ToQP::rep>(qp).point_for(ToQP::point_origin). In contrast to a separate value_cast followed by point_for (or vice-versa), the combined value_cast tries to choose the order of the individual conversion steps in a way to avoid both overflow and unnecessary loss of precision. Overflow is a risk because the change of origin point may require an addition of a potentially large offset (the difference between the origin points), which may well be outside the range of one or both quantity types.
    "},{"location":"users_guide/framework_basics/value_conversions/#scaling-overflow-prevention","title":"Scaling overflow prevention","text":"
    In the case of small integral types, it is easy to overflow the representation type for every value besides 0 while performing simple and popular unit conversions. This is why the library prevents such invalid conversions at compile-time both for explicit and implicit conversions:
     
    quantity q1 = std::int8_t(1) * km;\nquantity q2 = q1.force_in(m);   // Compile-time error (1)\nif(q1 != 1 * m) { /* ... */ }   // Compile-time error (2)\n
     
       
    1. Forced conversion would overflow on scaling.
      2.  
    2. Implicit conversion that brings arguments to a common unit before comparison would overflow on    scaling.
      3.  
     
    In the above example, the conversion factor between km and m is 1'000, which is larger than the maximum value that can be stored in std::int8_t. Even if we want to convert the smallest possible integral amount (e.g., 1 km), we will overflow the quantity representation type. We decided not to allow such conversions for safety reasons despite the value of 0 km would work.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-conversions-summary","title":"Value conversions summary","text":"
    The table below provides all the value conversion functions that may be run on x being the instance of either quantity or quantity_point:
     Forcing Representation Unit Member function Non-member function No Same u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x) or value_cast<T, u>(x)"},{"location":"users_guide/systems/strong_angular_system/","title":"Strong Angular System","text":""},{"location":"users_guide/systems/strong_angular_system/#some-background-information","title":"Some background information","text":"
    As per today's SI, both radian and steradian are dimensionless. This forces the convention to set the angle 1 radian equal to the number 1 within equations (similar to what natural units system does for c constant).
     
    Following Wikipedia:
     
    Wikipedia: Radian - Dimensional analysis
     
    Giacomo Prando says \"the current state of affairs leads inevitably to ghostly appearances and disappearances of the radian in the dimensional analysis of physical equations.\" For example, a mass hanging by a string from a pulley will rise or drop by \\(y=r\u03b8\\) centimeters, where \\(r\\) is the radius of the pulley in centimeters and \\(\u03b8\\) is the angle the pulley turns in radians. When multiplying \\(r\\) by \\(\u03b8\\) the unit of radians disappears from the result. Similarly in the formula for the angular velocity of a rolling wheel, \\(\u03c9=v/r\\), radians appear in the units of \\(\u03c9\\) but not on the right hand side. Anthony French calls this phenomenon \"a perennial problem in the teaching of mechanics\". Oberhofer says that the typical advice of ignoring radians during dimensional analysis and adding or removing radians in units according to convention and contextual knowledge is \"pedagogically unsatisfying\".
     
    At least a dozen scientists have made proposals to treat the radian as a base unit of measure defining its own dimension of \"angle\", as early as 1936 and as recently as 2022. This would bring the advantages of a physics-based, consistent, and logically-robust unit system, with unambiguous units for all physical quantities. At the same time the only notable changes for typical end-users would be: improved units for the quantities torque, angular momentum, and moment of inertia.
     
    Paul Quincey in his proposal \"Angles in the SI: a detailed proposal for solving the problem\" states:
     
    Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
     
    The familiar units assigned to some angular quantities are based on equations that have adopted the radian convention, and so are missing rads that would be present if the complete equation is used. The physically-correct units are those with the rads reinstated. Numerical values would not change, and the physical meanings of all quantities would also be unaffected.
     
    He proposes the following changes:
     
       
    • The radian would become either a new base unit or a 'complementary' unit
      •  
    • The steradian would become a derived unit equal to \\(1\\:rad^2\\)
      •  
    •  
      The SI units for
       
         
      • Torque would change from \\(N\\:m\\) (\\(=J\\)) to \\(J\\:rad^{-1}\\)
        •  
      • Angular momentum would change from \\(J\\:s\\) to \\(J\\:s\\:rad^{-1}\\) (i.e. \\(J/(rad/s)\\))
        •  
      • Moment of inertia would change from \\(kg\\:m^2\\) to \\(kg\\:m^2\\:rad^{-2}\\) (i.e. \\(J/(rad/s)^2\\))
        •  
       
      •  
    •  
      The option to omit the radian from the SI units for angle, angular velocity, angular frequency,   angular acceleration, and angular wavenumber would be removed, the only correct SI units being   \\(rad\\), \\(rad/s\\), \\(rad/s\\), \\(rad/s^2\\) and \\(rad/m\\) respectively.
       
      •  
     
    Paul Quincey summarizes that with the above in action:
     
    Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
     
    However, the physical clarity this would build into the SI should be recognised very quickly. The units would tell us that \\(torque \\times angle = energy\\), and \\(angular\\:momentum \\times angle = action\\), for example, in the same way that they do for \\(force \\times distance = energy\\), \\(linear\\:momentum \\times distance = action\\), and \\(radiant\\:intensity \\times solid\\:angle = radiant\\:flux\\). Dimensional analysis could be used to its full extent. Software involving angular quantities would be rationalised. Arguments about the correct units for frequency and angular frequency, and the meaning of the unit \\(Hz\\), could be left behind. The explanation of these changes would be considerably easier and more rewarding than explaining how a kilogram-sized mass can be measured in terms of the Planck constant.
    "},{"location":"users_guide/systems/strong_angular_system/#angular-quantities-in-the-si","title":"Angular quantities in the SI","text":"
    Even though the SI somehow ignores the dimensionality of angle:
     
    SI Brochure
     
    Plane and solid angles, when expressed in radians and steradians respectively, are in effect also treated within the SI as quantities with the unit one. The symbols \\(rad\\) and \\(sr\\) are written explicitly where appropriate, in order to emphasize that, for radians or steradians, the quantity being considered is, or involves the plane angle or solid angle respectively. For steradians it emphasizes the distinction between units of flux and intensity in radiometry and photometry for example. However, it is a long-established practice in mathematics and across all areas of science to make use of \\(rad = 1\\) and \\(sr = 1\\). For historical reasons the radian and steradian are treated as derived units.
     
    It also explicitly states:
     
    SI Brochure
     
    The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second, and the SI unit of activity is becquerel, implying counts per second. Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor of \\(2\\pi\\). Ignoring this fact may cause an error of \\(2\\pi\\). Note that in some countries, frequency values are conventionally expressed using \u201ccycle/s\u201d or \u201ccps\u201d instead of the SI unit \\(Hz\\), although \u201ccycle\u201d and \u201ccps\u201d are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in \\(rad/s\\). Because of this, it is recommended that quantities called \u201cfrequency\u201d, \u201cangular frequency\u201d, and \u201cangular velocity\u201d always be given explicit units of \\(Hz\\) or \\(rad/s\\) and not \\(s^{-1}\\).
    "},{"location":"users_guide/systems/strong_angular_system/#strong-angular-extensions-in-the-library","title":"Strong Angular extensions in the library","text":"
    The mp-units library strives to define physically-correct quantities and their units to provide maximum help to its users. As treating angle as a dimensional quantity can lead to many \"trivial\" mistakes in dimensional analysis and calculation, it was decided to provide additional experimental systems of quantities and units that follow the above approach and treat angle as a base quantity with a base unit of radian and solid angle as its derived quantity.
     
    As those (at least for now) are not a part of SI, the plain angle and solid angle definitions can be found in a dedicated angular system. Those definitions are also used in the isq_angle system of quantities to make the recipes for angle-based quantities like torque or angular velocity physically correct:
     
    using namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::rad;\n\nconst quantity lever = isq_angle::position_vector(20 * cm);\nconst quantity force = isq_angle::force(500 * N);\nconst quantity angle = isq_angle::angular_measure(90. * deg);\nconst quantity torque = isq_angle::torque(lever * force * angular::sin(angle) / (1 * isq_angle::cotes_angle));\n\nstd::cout << \"Applying a perpendicular force of \" << force << \" to a \" << lever << \" long lever results in \"\n          << torque.in(N * m / rad) << \" of torque.\\n\";\n
     
    The above program prints:
     
    Applying a perpendicular force of 500 N to a 20 cm long lever results in 100 N m/rad of torque.\n
     
    Note
     
    cotes_angle is a constant which represents an angle with the value of exactly 1 radian. You can find more information about this constant in Quincey.
     
    Try it on Compiler Explorer
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/","title":"Interoperability with Other Libraries","text":"
    mp-units makes it easy to cooperate with similar entities of other libraries. No matter if we want to provide interoperability with a simple home-grown strongly typed wrapper type (e.g., Meter, Timestamp, ...) or with a feature-rich quantities and units library, we have to provide specializations of:
     
       
    • a quantity_like_traits for external quantity-like type,
      •  
    • a quantity_point_like_traits for external quantity_point-like type.
      •  
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#specifying-a-conversion-kind","title":"Specifying a conversion kind","text":"
    Before we delve into the template specialization details, let's first decide if we want the conversions to happen implicitly or if explicit ones would be a better choice. Or maybe the conversion should be implicit in one direction only (e.g., into mp-units abstractions) while the explicit conversions in the other direction should be preferred?
     
    There is no one unified answer to the above questions. Everything depends on the use case.
     
    Typically, the implicit conversions are allowed in cases where:
     
       
    • both abstractions mean exactly the same, and interchanging them in the code should not change   its logic,
      •  
    • there is no significant runtime overhead introduced by such a conversion (e.g., no need for dynamic   allocation or copying of huge internal buffers),
      •  
    • the target type of the conversion provides the same or better safety to the users,
      •  
    • we prefer the simplicity of implicit conversions over safety during the (hopefully short)   transition period of refactoring our code base from the usage of one library to the other.
      •  
     
    In all other scenarios, we should probably enforce explicit conversions.
     
    The kinds of inter-library conversions can be easily configured in partial specializations of conversion traits in the mp-units library. Conversion traits should provide a static data member convertible to bool. If the value is true, then the conversion is explicit. Otherwise, if the value is false, implicit conversions will be allowed. The names of the flags are as follows:
     
       
    • explicit_import to describe conversion from the external entity to the one in this   library (import case),
      •  
    • explicit_export to describe conversion from the entity in this library to the external one   (export case).
      •  
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#quantities-conversions","title":"Quantities conversions","text":"
    For example, let's assume that some company has its own Meter strong-type wrapper:
     
    struct Meter {\n  int value;\n};\n
     
    As every usage of Meter is at least as good and safe as the usage of quantity<si::metre, int>, and as there is no significant runtime performance penalty, we would like to allow the conversion to mp_units::quantity to happen implicitly.
     
    On the other hand, the quantity type is much safer than the Meter, and that is why we would prefer to see the opposite conversions stated explicitly in our code.
     
    To enable such interoperability, we must define a partial specialization of the quantity_like_traits<T> type trait. Such specialization should provide:
     
       
    • reference static data member that provides the quantity reference (e.g., unit),
      •  
    • rep type that specifies the underlying storage type,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a quantity's raw value of rep type,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     
    For example, for our Meter type, we could provide the following:
     
    template<>\nstruct mp_units::quantity_like_traits<Meter> {\n  static constexpr auto reference = si::metre;\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Meter::value);\n  static constexpr rep to_numerical_value(Meter m) { return m.value; }\n  static constexpr Meter from_numerical_value(rep v) { return Meter{v}; }\n};\n
     
    After that, we can check that the QuantityLike concept is satisfied:
     
    static_assert(mp_units::QuantityLike<Meter>);\n
     
    and we can write the following:
     
    void print(Meter m) { std::cout << m.value << \" m\\n\"; }\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n\n  Meter height{42};\n\n  // implicit conversions\n  quantity h1 = height;\n  quantity<isq::height[m], int> h2 = height;\n\n  std::cout << h1 << \"\\n\";\n  std::cout << h2 << \"\\n\";\n\n  // explicit conversions\n  print(Meter(h1));\n  print(Meter(h2));\n}\n
     
    Note
     
    No matter if we decide to use implicit or explicit conversions, the mp-units will not allow unsafe operations to happen.
     
    If we extend the above example with unsafe conversions, the code will not compile, and we will have to fix the issues first before the conversion may be performed:
     UnsafeFixed 
    quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = height;  // Compile-time error (1)\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(h3));                            // Compile-time error (2)\nprint(Meter(h4));                            // Compile-time error (3)\nprint(Meter(h5));\n
     
       
    1. Truncation of value while converting from meters to kilometers.
      2.  
    2. Conversion of double to int is not value-preserving.
      3.  
    3. Truncation of value while converting from millimeters to meters.
      4.  
     
    quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = quantity{height}.force_in(km);\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(value_cast<int>(h3)));\nprint(Meter(h4.force_in(m)));\nprint(Meter(h5));\n
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#quantity-points-conversions","title":"Quantity points conversions","text":"
    To play with quantity point conversions, let's assume that we have a Timestamp strong type in our codebase, and we would like to start using mp-units to work with this abstraction.
     
    struct Timestamp {\n  int seconds;\n};\n
     
    As we described in The Affine Space chapter, timestamps should be modeled as quantity points rather than regular quantities.
     
    To allow the conversion between our custom Timestamp type and the quantity_point class template we need to provide the following in the partial specialization of the quantity_point_like_traits<T> type trait:
     
       
    • reference static data member that provides the quantity point reference (e.g., unit),
      •  
    • point_origin static data member that specifies the absolute point, which is the beginning of   our measurement scale for our points,
      •  
    • rep type that specifies the underlying storage type,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity being   the offset of the point from the origin,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     
    For example, for our Timestamp type, we could provide the following:
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Timestamp::seconds);\n  static constexpr rep to_numerical_value(Timestamp ts) { return ts.seconds; }\n  static constexpr Timestamp from_numerical_value(rep v) { return Timestamp(v); }\n};\n
     
    After that, we can check that the QuantityPointLike concept is satisfied:
     
    static_assert(mp_units::QuantityPointLike<Timestamp>);\n
     
    and we can write the following:
     
    void print(Timestamp ts) { std::cout << ts.seconds << \" s\\n\"; }\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n\n  Timestamp ts{42};\n\n  // implicit conversion\n  quantity_point qp = ts;\n\n  std::cout << qp.quantity_from_zero() << \"\\n\";\n\n  // explicit conversion\n  print(Timestamp(qp));\n}\n
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#interoperability-with-the-c-standard-library","title":"Interoperability with the C++ Standard Library","text":"
    In the C++ standard library, we have two types that handle quantities and model the affine space. Those are:
     
       
    • std::chrono::duration - specifies   quantities of time,
      •  
    • std::chrono::time_point - specifies   quantity points of time.
      •  
     
    The mp-units library comes with built-in interoperability with those types. It is enough to include the mp-units/systems/si/chrono.h file to benefit from it. This file provides:
     
       
    • partial specializations of quantity_like_traits and quantity_point_like_traits that provide   support for implicit conversions between std and mp_units types in both directions,
      •  
    • chrono_point_origin<Clock> point origin for std clocks,
      •  
    • to_chrono_duration and to_chrono_time_point dedicated conversion functions that result   in types exactly representing mp-units abstractions.
      •  
     
    Important
     
    Only a quantity_point that uses chrono_point_origin<Clock> as its origin can be converted to the std::chrono abstractions:
     
    inline constexpr struct ts_origin final : relative_point_origin<chrono_point_origin<system_clock> + 1 * h> {} ts_origin;\ninline constexpr struct my_origin final : absolute_point_origin<isq::time> {} my_origin;\n\nquantity_point qp1 = sys_seconds{1s};\nauto tp1 = to_chrono_time_point(qp1);  // OK\n\nquantity_point qp2 = chrono_point_origin<system_clock> + 1 * s;\nauto tp2 = to_chrono_time_point(qp2);  // OK\n\nquantity_point qp3 = ts_origin + 1 * s;\nauto tp3 = to_chrono_time_point(qp3);  // OK\n\nquantity_point qp4 = my_origin + 1 * s;\nauto tp4 = to_chrono_time_point(qp4);  // Compile-time Error (1)\n\nquantity_point qp5{1 * s};\nauto tp5 = to_chrono_time_point(qp5);  // Compile-time Error (2)\n
     
       
    1. my_origin is not defined in terms of chrono_point_origin<Clock>.
      2.  
    2. zeroth_point_origin is not defined in terms of chrono_point_origin<Clock>.
      3.  
     
    Here is an example of how interoperability described in this chapter can be used in practice:
     
    using namespace std::chrono;\n\nsys_seconds ts_now = floor<seconds>(system_clock::now());\n\nquantity_point start_time = ts_now;\nquantity speed = 925. * km / h;\nquantity distance = 8111. * km;\nquantity flight_time = distance / speed;\nquantity_point exp_end_time = start_time + flight_time;\n\nsys_seconds ts_end = value_cast<int>(exp_end_time.in(s));\n\nauto curr_time = zoned_time(current_zone(), ts_now);\nauto mst_time = zoned_time(\"America/Denver\", ts_end);\n\nstd::cout << \"Takeoff: \" << curr_time << \"\\n\";\nstd::cout << \"Landing: \" << mst_time << \"\\n\";\n
     
    The above may print the following output:
     
    Takeoff: 2023-11-18 13:20:54 UTC\nLanding: 2023-11-18 15:07:01 MST\n
    "},{"location":"users_guide/use_cases/wide_compatibility/","title":"Wide Compatibility","text":"
    The mp-units allows us to implement nice and terse code targeting a specific C++ version and configuration. Such code is easy to write and understand but might not be portable to some older environments.
     
    However, sometimes, we want to develop code that can be compiled on a wide range of various compilers and configurations. This is why the library also exposes and uses special preprocessor macros that can be used to ensure the wide compatibility of our code.
     
    Note
     
    Those macros are used in our short example applications as those are meant to be built on all of the supported compilers. Some still do not support std::format, C++ modules, or C++ versions newer than C++20.
    "},{"location":"users_guide/use_cases/wide_compatibility/#various-compatibility-options","title":"Various compatibility options","text":"
    Depending on your compiler's conformance, you can choose to use any of the below styles to write your code using mp-units:
     C++23C++20C++20 with header filesC++20 with header files + libfmtWide Compatibility 
    #include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <fmt/format.h>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << fmt::format(...) << \"\\n\";\n
     
    #include <iostream>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_MODULES\n#include <mp-units/compat_macros.h>\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\n// ...\n\nQUANTITY_SPEC(horizontal_length, isq::length);\n\n// ...\n\nstd::cout << MP_UNITS_STD_FMT::format(...) << \"\\n\";\n
     
    Tip
     
    Depending on your preferences, you can either write:
     
       
    • terse code directly targeting your specific compiler's abilities,
      •  
    • verbose code using preprocessor branches and macros that provide the widest compatibility   across various compilers.
      •  
    "},{"location":"users_guide/use_cases/wide_compatibility/#compatibility-macros","title":"Compatibility macros","text":"
    This chapter describes only the most essential tools the mp-units users need. All the compatibility macros can be found in the mp-units/compat_macros.h header file.
     
    Tip
     
    The mp-units/compat_macros.h header file is implicitly included when we use \"legacy\" headers in our translation units. However, it has to be explicitly included when we use C++20 modules, as those do not propagate preprocessor macros.
    "},{"location":"users_guide/use_cases/wide_compatibility/#QUANTITY_SPEC","title":"QUANTITY_SPEC(name, ...)","text":"
    Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code.
     
    This macro benefits from the new C++23 feature if available. Otherwise, it uses the CRTP idiom under the hood.
    "},{"location":"users_guide/use_cases/wide_compatibility/#mp_units_std_fmt","title":"MP_UNITS_STD_FMT","text":"
    Some of the supported compilers do not support std::format and related tools. Also, despite using a conformant compiler, some projects still choose to use fmtlib as their primary formatting facility (e.g., to benefit from additional features provided with the library).
     
    This macro resolves to either the std or fmt namespace, depending on the value of MP_UNITS_API_STD_FORMAT CMake option.
     
    To include the header files of the underlying text formatting framework, the following include should be used:
     
    #include <mp-units/ext/format.h>\n
    "},{"location":"users_guide/use_cases/wide_compatibility/#contracts","title":"Contracts","text":"
    The mp-units library internally does contract checking by default. It can be disabled with a Conan or CMake option. However, when enabled, it can use either gsl-lite or ms-gsl. To write a code that is independent from the underlying framework, the following preprocessor macros are exposed:
     
       
    • MP_UNITS_EXPECTS(expr)
      •  
    • MP_UNITS_EXPECTS_DEBUG(expr)
      •  
    • MP_UNITS_ASSERT(expr)
      •  
    • MP_UNITS_ASSERT_DEBUG(expr)
      •  
     
    Their meaning is consistent with respective gsl-lite.
     
    Also, to include the header files of the underlying framework, the following include should be used:
     
    #include <mp-units/ext/contracts.h>\n
    "},{"location":"users_guide/use_cases/working_with_legacy_interfaces/","title":"Working with Legacy interfaces","text":"
    In case we are working with a legacy/unsafe interface, we may need to extract the numerical value of a quantity and pass it to some third-party legacy unsafe interfaces.
     
    In such situations we can use .numerical_value_in(Unit) member function:
     
    void legacy_check_speed_limit(int speed_in_km_per_h);\n
     
    legacy_check_speed_limit((180 * km / (2 * h)).numerical_value_in(km / h));\n
     
    Such a getter will explicitly enforce the usage of a correct unit required by the underlying interface, which reduces a significant number of safety-related issues.
     
    The above code will not compile in case value truncation may happen. To solve the issue, we need to either use a value-preserving representation type or force the truncating conversion with .force_numerical_value_in(Unit):
     
    legacy_check_speed_limit((140 * mi / (2 * h)).force_numerical_value_in(km / h));\n
     
    The getters mentioned above always return by value as a quantity value conversion may be required to adjust it to the target unit. In case a user needs a reference to the underlying storage .numerical_value_ref_in(Unit) should be used:
     
    void legacy_set_speed_limit(int* speed_in_km_per_h) { *speed_in_km_per_h = 100; }\n
     
    quantity<km / h, int> speed_limit;\nlegacy_set_speed_limit(&speed_limit.numerical_value_ref_in(km / h));\n
     
    This member function again requires a target unit to enforce safety. This overload does not participate in overload resolution if the provided unit has a different scaling factor than the current one.
    "},{"location":"blog/archive/2025/","title":"2025","text":""},{"location":"blog/archive/2024/","title":"2024","text":""},{"location":"blog/archive/2023/","title":"2023","text":""},{"location":"blog/category/metrology/","title":"Metrology","text":""},{"location":"blog/category/wg21-updates/","title":"WG21 Updates","text":""},{"location":"blog/category/releases/","title":"Releases","text":""},{"location":"blog/page/2/","title":"Blog","text":""},{"location":"blog/archive/2024/page/2/","title":"2024","text":""}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Welcome to mp-units!","text":"
    mp-units is a compile-time enabled feature-rich Modern C++ modular/header-only library that provides compile-time dimensional analysis and unit/quantity manipulation. Its key strengths include safety, performance, and developer experience.
     
    It is the first library on the market that, besides being unit-safe and dimension-safe, is also quantity-safe.
     
    The library source code is hosted on GitHub with a permissive MIT license.
     Supported compilers 
    This library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
     
    Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality.
     
    Please refer to C++ compiler support chapter for more details.
     C++ modulesHeader files 
    #include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
     
    Output:
     
    Harvard Bridge length = 364.4 smoot (2034.6 ft, 620.14 m) \u00b1 1 \u03b5ar\n
     
    Try it on Compiler Explorer
     What is smoot? 
    The smoot (/\u02c8smu\u02d0t/) is a nonstandard unit of length created as part of an MIT fraternity prank. It is named after Oliver R. Smoot, a fraternity pledge to Lambda Chi Alpha, who, in October 1958, lay on the Harvard Bridge (between Boston and Cambridge, Massachusetts) and was used by his fraternity brothers to measure the length of the bridge.
     
    One smoot equals Oliver Smoot's height at the time of the prank (five feet and seven inches). The bridge's length was measured to be 364.4 smoots plus or minus one ear, with the \"plus or minus\" intended to express the measurement uncertainty.
     
    Oliver Smoot graduated from MIT with the class of 1962, became a lawyer, and later became chairman of the American National Standards Institute (ANSI) and president of the International Organization for Standardization (ISO).
     
    More on the smoot unit of length can be found at https://en.wikipedia.org/wiki/Smoot.
     
    Important: Help needed!
     
    The mp-units library might be the subject of ISO standardization for C++29. More on this can be found in the following ISO C++ proposals:
     
       
    • P1935: A C++ Approach to Physical Units,
      •  
    • P2980: A motivation, scope, and plan for a physical quantities and units library,
      •  
    • P3045: Quantities and units library.
      •  
     
    We are actively looking for parties interested in field-trialing the library.
    "},{"location":"api_reference/","title":"API Reference - mp-units","text":""},{"location":"release_notes/","title":"Release Notes","text":""},{"location":"release_notes/#mp-units","title":"mp-units","text":""},{"location":"release_notes/#2.5.0","title":"2.5.0 WIP","text":"
       
    • (!) feat: representation concepts improved
      •  
    • (!) feat: representation_of concept now also accepts a quantity_spec and accepts any representation character for quantity kinds
      •  
    • (!) feat: quantity::one() removed
      •  
    • (!) feat: Representation concept removed
      •  
    • feat: SymbolicArg applied to expression templates
      •  
    • feat: per and power made final
      •  
    • feat: derived_XXX are now constrained with SymbolicConstant
      •  
    • feat: prime factorization extended to any magnitude (thanks @chiphogg)
      •  
    • feat: cartesian_vector added
      •  
    • feat: equivalent now accept any units (even non-convertible)
      •  
    • feat: text output should fallback to the portable mode when UTF-8 is not used for text_encoding
      •  
    • feat: precondition added to to_u8string
      •  
    • feat: text output of scaled units is now enclosed in parenthesis (...) instead of brackets [...]
      •  
    • feat: abs(quantity) exposed for conforming freestanding implementations
      •  
    • feat: proper constraints for kind_of
      •  
    • feat: missing precondition added for quantity::op/
      •  
    • feat: quantity_spec conversions improved
      •  
    • feat: rankine unit added
      •  
    • feat: std::numeric_limits support added
      •  
    • feat: scaling_overflows_non_zero_values added to detect conversions overflowing rep
      •  
    • feat: deprecation messages now provide the release version where the deprecation happened
      •  
    • feat: electromagnetism.h updated to IEC80000-6-2022
      •  
    • feat: ConvertibleWithNumber introduced to improve convertibility of unit one with raw numbers
      •  
    • feat: lerp and midpoint for points added
      •  
    • feat: is_value_preserving customization point added
      •  
    • feat(example): is_vector specialization no longer needed for si_constants
      •  
    • (!) refactor: type_list moved to implementation details
      •  
    • (!) refactor: from now unit_symbol and dimension_symbol always returns std::string_view
      •  
    • (!) refactor: text_encoding renamed to character_set
      •  
    • (!) refactor: Magnitude renamed to UnitMagnitude and magnitude to unit_magnitude
      •  
    • (!) refactor: unit_magnitude moved to detail namespace
      •  
    • (!) refactor: absolute renamed to point
      •  
    • (!) refactor: power members refactored to be explicitly exposition only
      •  
    • (!) refactor: is_XXX customization points for representation types removed
      •  
    • (!) refactor: quantity_values renamed to representation values
      •  
    • (!) refactor: scalar and complex characters renamed to real_scalar and complex_scalar respectively + concepts refactoring
      •  
    • (!) refactor: MagConstant concept renamed to detail::is_mag_constant variable trait
      •  
    • refactor: mp_units.core defined in terms of core.h
      •  
    • refactor: MP_UNITS_NONCONST_TYPE introduced to benefit from the C++23 feature
      •  
    • refactor: SymbolicConstant concept refactored
      •  
    • refactor: explicit type of op/ for quantity and reference replaced with constrained placeholder
      •  
    • refactor: private unit_magnitude interface renamed to not use leading _
      •  
    • refactor: one_of concept removed and replaced with QSProperty in quantity_spec
      •  
    • refactor: std::is_trivial will be deprecated in C++26
      •  
    • refactor: SameQuantitySpec concept removed and replaced with direct comparison
      •  
    • refactor: unused SameReference concept removed
      •  
    • refactor: type_name_less introduced and used as a default predicate for expression templates
      •  
    • refactor: \"expression templates\" renamed to \"symbolic expressions\"
      •  
    • refactor: all_are_kinds removed and get_associated_quantity simplified
      •  
    • refactor: reference now returns explicit types for inverse, pow, sqrt, and cbrt
      •  
    • refactor: repeated concept checks removed from get_common_reference
      •  
    • refactor: std::assignable_from used in ValuePreservingTo concept
      •  
    • refactor: quantity constructor refactored to use another constructor with the result of sudo_cast
      •  
    • refactor: preconditions for quantity operations now use is_neq_zero
      •  
    • refactor: implicit expression variations used in quantity and quantity_point constraints
      •  
    • refactor: inverse() constraints improved
      •  
    • refactor: make_quantity_point introduced
      •  
    • refactor: point_origin_interface::op+ return type unified with the rest of the interfaces
      •  
    • refactor: std::convertible_to replaced with std::same_as in basic_fixed_string
      •  
    • refactor: less, ceil, and round refactored and improved + more unit tests for round
      •  
    • refactor: math_concepts.h removed and concepts replaced with explicit expression in constraints
      •  
    • refactor: visit_format_arg is deprecated in C++26
      •  
    • refactor: deprecated literal operators
      •  
    • refactor: constraints refactoring
      •  
    • (!) fix: electric_current_phasor, voltage_phasor, apparent_power switched to complex character
      •  
    • (!) fix: position_vector and displacement moved to a different place in a tree
      •  
    • (!) fix: velocity is now defined in terms of displacement instead of position_vector
      •  
    • fix: missing core.h added to CMake
      •  
    • fix: const was leaking to some SymbolicConstants
      •  
    • fix: make_reference should skip only the exact kinds deduced from a unit
      •  
    • fix: inconsistencies in get_common_quantity_spec() fixed
      •  
    • fix: unused convertible_kinds() argument removed
      •  
    • fix: compile-time branch condition fixed in quantity_point::point_for
      •  
    • fix: inverse(Quantity) fixed for subkinds of dimensionless
      •  
    • fix: point_origin_interface::op+ constraints fixed
      •  
    • fix: missing get_common_unit() overload added
      •  
    • fix: floor and ceil constraints fixed
      •  
    • fix: quantity characters fixed in electromagnetism quantities
      •  
    • fix: arg.visit support fixed
      •  
    • fix: expr_less now also sorts powers
      •  
    • fix: mag_constant workarounds branches for clang fixed
      •  
    • fix: checking for clang versions fixed in CMake scripts
      •  
    • fix: text stripping in type_name fixed
      •  
    • test: lots of tests for complex quantities
      •  
    • test: runtime unit tests refactored to have a bigger granularity (less top level tests)
      •  
    • test: surface tension replaced with entropy in an fmt test
      •  
    • test: test_package now is tested also with C++20 modules
      •  
    • test: tests for dimensionless quantities static data members
      •  
    • test: a few more natural units tests added
      •  
    • test: tests to check if quantity satisfies Scalar
      •  
    • test: add static tests for concept DimensionOf (thanks @jvocht)
      •  
    • test: quantity character concepts tests for quantities added
      •  
    • docs: ISQ part 6 released
      •  
    • docs: new chapter about our documentation added to the contributing guide
      •  
    • docs: directory name updated in the contributing guide
      •  
    • docs: mp-units Conan options added to conanfile.txt examples
      •  
    • docs: contracts Conan option default value description improved
      •  
    • docs: outdated note removed from the \"Text Output\" chapter
      •  
    • docs: a paragraph about additional formatting options removed (applicable only to quantity symbols which we do not support)
      •  
    • docs: Wroc\u0142aw 2024 meeting report
      •  
    • docs: explicit unit conversion example added to the \"Symbols of common units\" chapter
      •  
    • docs: \"Bringing Quantity-Safety To The Next Level\" blog post added
      •  
    • docs: quantity-safety mentioned in the docs
      •  
    • docs: complex character added to the \"Quantity character\" chapter
      •  
    • docs: intro to \"Value Conversions\" chapter added
      •  
    • docs: \"Scaling overflow prevention\" chapter added
      •  
    • docs: \"Concepts\" chapter updated
      •  
    • docs: old customization points removed from the \"Character of a Quantity\" chapter
      •  
    • docs: clang-19 issues mentioned in a compiler support table
      •  
    • docs(ref): document most of mp_units.core (thanks @JohelEGP)
      •  
    • build: CheckCacheVarValues CMake module file added
      •  
    • build: MP_UNITS_DEV_TIME_TRACE CMake option added
      •  
    • build: MP_UNITS_API_NO_CRTP removed from test_package CMake
      •  
    • build: require at least CMake 3.31 with Conan
      •  
    • build: clang-20 enabled in CI
      •  
    • build: clang-19 support removed from conanfile.py
      •  
    • build: clang-20.1 workaround added to package_info
      •  
    • build: update dependencies to gsl-lite/0.42.0, ms-gsl/4.1.0, fmt/11.1.4, and catch2/3.8.0
      •  
    • build: suppress warnings for gcc-12 in conanfile
      •  
    • ci: CI matrix generation added (thanks @burnpanck)
      •  
    • ci: import_std now checks if at least C++23 is being used
      •  
    • perf: caching of the results of heavy consteval functions execution added
      •  
    • perf: expr_projectable concept removed to improve compilation performance
      •  
    "},{"location":"release_notes/#2.4.0","title":"2.4.0 November 5, 2024","text":"
       
    • (!) feat: phase_velocity and group_velocity aliases removed from ISQ by ISO
      •  
    • feat: iec::bit using-declared in iec::unit_symbols
      •  
    • feat: common unit symbols now use EQUIV{u1, u2, ...} syntax
      •  
    • feat: scaled_unit symbol printing improved ([] around the entire unit, small magnitude values do not use a power of 10 anymore)
      •  
    • feat: scaled_unit does not have a priority over derived_unit anymore
      •  
    • feat: fractional exponents support added to mag_power
      •  
    • feat: tag types are now required to be empty
      •  
    • feat: magnitude text now obeys formatting parameters and knows how to print constants
      •  
    • feat: added support for printing powers of magnitude constants
      •  
    • feat: SymbolicConstant concept added
      •  
    • feat: common_unit selection algorithm improved to make rev + rad return rad
      •  
    • feat: litre text symbol changed from l to L to avoid ambiguity with 1
      •  
    • feat: alternative litre unit symbol L added to prevent ambiguities with 1
      •  
    • feat: Unicode unit symbols
      •  
    • feat: \u03c0 added as an alias for pi
      •  
    • feat: expr_pow extended to remove redundancy in callers
      •  
    • feat: DerivedDimensionExpr, DerivedQuantitySpecExpr and DerivedUnitExpr removed
      •  
    • feat: MagnitudeSpecExpr and PowerVBase removed and some functions renamed to limit possible ambiguity in overload resolution
      •  
    • feat: std::is_object constraint applied to value_type_t
      •  
    • feat: quantity_values are now defined on top of std::chrono::duration_values
      •  
    • feat: from now on truncation is not allowed in compound assignment
      •  
    • feat(example): currency example now uses chrono::time_point and has better interfaces
      •  
    • feat(example): treat_as_floating_point specializations for examples' types removed
      •  
    • (!) refactor: all iec quantity specifications are now deprecated and moved to isq
      •  
    • (!) refactor: mag_constant now takes a symbol and a value and the class deriving from it must be final
      •  
    • (!) refactor: op==(U1, U2) now checks for the same type (old behavior available as equivalent(U1, U2)) + convertible now verifies associated quantity_spec as well
      •  
    • (!) refactor: ascii -> portable, unicode -> utf8, 'A' -> 'P'
      •  
    • (!) refactor: char_traits removed from fixed_string
      •  
    • (!) refactor: convertibility traits and concepts refactored to use bool flags instead of wrappers
      •  
    • (!) refactor: tag types should not expose their members
      •  
    • refactor: convertible(U1, U2) implementation simplified
      •  
    • refactor: abs moved to constexpr_math.h
      •  
    • refactor: unit_symbol_impl simplified
      •  
    • refactor: unit_symbol_formatting moved to a dedicated header file
      •  
    • refactor: shorten_T removed
      •  
    • refactor: magnitude interface cleanup
      •  
    • refactor: derived_from_the_same_base_dimension no longer needed
      •  
    • refactor: one_of usage removed from the fixed_string deduction guides
      •  
    • refactor: quantity.h is not needed in constants.h (unit.h is enough)
      •  
    • refactor: SameDimension concept is not needed and can be inlined in DimensionOf
      •  
    • refactor: framework Unicode symbols are now spelled using their codes
      •  
    • refactor: QuantitySpecWithNoSpecifiers removed and kind_of definition simplified
      •  
    • refactor: treat_as_floating_point simplified and extended to use std::chrono::treat_as_floating_point_v
      •  
    • refactor: wrapped_type_t reuses std::indirectly_readable_traits
      •  
    • refactor: expr_fractions takes direct OneType type now instead of a trait
      •  
    • refactor: Unicode symbols description reworked based on the latest SG16 recommendations
      •  
    • refactor: Mutable concept applied to quantity and quantity_point
      •  
    • refactor: explicit cleanup for deduction guides of quantity and quantity_point
      •  
    • refactor: point_origin_interface::op- cleanup
      •  
    • refactor: QuantityLikeImpl refactored to conform to API Reference by @JohelEGP
      •  
    • refactor: get_complexity refactored to be 0-based and not account for a number of arguments in a list
      •  
    • refactor: get_complexity refactored to returned maximum complexity of an element (instead of the sum of elements)
      •  
    • refactor(test): derived_quantity refactored to child_quantity
      •  
    • fix: missing are_ingredients_convertible overloads added
      •  
    • fix: constraints for magnitude added for scaled_unit and fixed common_unit instantiating it incorrectly
      •  
    • fix: according to ISO 80000-16 % should always be prefixed with space
      •  
    • fix: extraneous space in unit symbol having only denominators removed
      •  
    • fix: explicit cast added to less for magnitudes to fix clang-arm64 conversion error
      •  
    • fix: common_unit handling fixed for some corner cases
      •  
    • fix: math functions constraints fixed
      •  
    • fix: operator*(M, U u) fixed for U being scaled_unit
      •  
    • fix: subsumption of QuantityKindSpec fixed
      •  
    • fix: ValuePreservingTo fixed to apply std::remove_cvref_t on FromRep
      •  
    • fix: compound assignment operations on quantities now behave the same as on the underlying representation types
      •  
    • fix: QuantityConvertibleTo used in quantity_point compound assignment
      •  
    • fix: convertible_kinds implementation fixed
      •  
    • fix(tests): freestanding build fixed
      •  
    • test: unit tests for the inverse of mag_constant added
      •  
    • test: Unicode symbols used in unit tests
      •  
    • test: more std::chrono tests added
      •  
    • test: commutativity tests added to ISQ
      •  
    • test: one kind_of test added to reference tests
      •  
    • test: pow<0> and pow<1> tests added for dimensions
      •  
    • test: more get_common_quantity_spec tests added
      •  
    • build: setting of some test_package CMake options enabled only for a cxx_modules build
      •  
    • ci: sudo apt update added for documentation.yml in hope that it will resolve missing system packages issue
      •  
    • ci: MSVC added to the CI
      •  
    • ci: the latest not-released docs will use \"HEAD\" as a version from now on
      •  
    • ci: documentation action should run on a new tag as well
      •  
    • ci: documentation action limited only to commits that change documentation files
      •  
    • ci: non-documentation actions should not run on tags
      •  
    • docs: missing systems added to the \"Project Structure\" chapter
      •  
    • docs: graphs of ISQ kind hierarchies improved
      •  
    • docs: category of the ISO meeting reports changed to \"WG21 Updates\"
      •  
    • docs: blog comments support added
      •  
    • docs: Part 1-5 articles of the ISQ series added
      •  
    • docs: \"Symbols of scaled units\" chapter added + minor updates to scaled and common units chapters
      •  
    • docs: conan profile updated to present gcc-14 instead of gcc-12 which is no longer supported
      •  
    • docs: \"Why derived units order is not preserved from the multiplication?\" chapter added to FAQ
      •  
    • docs: \"Many shades of the same unit\" extended with a note about the derived units order
      •  
    • docs: API Reference now presents index.html instead of full.hml
      •  
    "},{"location":"release_notes/#2.3.0","title":"2.3.0 September 27, 2024","text":"
       
    • (!) feat: delta and absolute construction helpers
      •  
    • (!) feat: Conan and CMake options changed as requested at ConanCenter code review
      •  
    • (!) feat: unit_can_be_prefixed removed - from now on all named units can be prefixed
      •  
    • feat: formatting functions for units and dimensions marked as constexpr to enable compile-time text formatting
      •  
    • feat: qp1.quantity_from(qp2) added
      •  
    • feat: non-member swap added for fixed_string
      •  
    • feat: simplified inplace_vector added
      •  
    • feat: text output for angular units improved (space before symbol removed)
      •  
    • feat: representation type template parameter added to value conversion functions
      •  
    • feat: all tags in the expression templates are now ordered by the type names
      •  
    • feat: convertibility of a quantity with a unit one with the raw value added
      •  
    • feat: import std; support added
      •  
    • feat: compute values for rational magnitude powers (thanks @chiphogg)
      •  
    • feat: value_cast<Representation, Unit>() complementary conversion function added
      •  
    • feat: hw_voltage example added
      •  
    • feat: MP_UNITS_IMPORT_STD and MP_UNITS_MODULES handled properly in test_package.cpp
      •  
    • feat: complex quantity character added
      •  
    • feat: iec::var unit added
      •  
    • feat: type_list_unique added
      •  
    • feat: for_each on std::tuple added
      •  
    • feat: common_unit support added
      •  
    • (!) refactor: quantity_point_like_traits now use numerical value instead of the quantity
      •  
    • (!) refactor: iec80000 system renamed to iec
      •  
    • (!) refactor: mag_pi is now mag<pi>
      •  
    • (!) refactor: common_XXX() functions renamed to get_common_XXX()
      •  
    • refactor: error messages-related improvements
      •  
    • refactor: [[nodiscard]] and consteval set for some magnitude-related functions
      •  
    • refactor: degree Celsius and Fahrenheit symbols text now use Unicode codepoints
      •  
    • refactor: dimension_symbol and units_symbol refactored to use inplace_vector
      •  
    • refactor: unit_symbol and dimension_symbol refactored for readability and consteval
      •  
    • refactor: binary operators of quantity and quantity_point are now hidden friends
      •  
    • refactor: tag types-related operators are now hidden friends as well
      •  
    • refactor: ValuePreservingTo concept added
      •  
    • refactor: perfect forwarding interfaces improved
      •  
    • refactor: Representation concepts now requires WeaklyRegular instead of std::regular
      •  
    • refactor: quantity_point default-constructibility removed from the quantity_from constraints
      •  
    • refactor: has_common_type_v simplified
      •  
    • refactor: is_power_of_quantity_spec and is_power_of_dim variable templates converted to concepts
      •  
    • refactor: unnecessary custom versions of is_specialization_of removed
      •  
    • refactor: is_derived_from_specialization_of_v added and applied to remove custom traits
      •  
    • fix: signatures of capacity functions of fixed_string fixed
      •  
    • fix: MP_UNITS_API_NO_CRTP handling fixed
      •  
    • fix: MP_UNITS_HOSTED branch added to core.h
      •  
    • fix: mkdocs dependencies fixed in the gitpod dockerfile
      •  
    • fix: MP_UNITS_API_CONTRACTS should have a priority over headers availability
      •  
    • fix: si.h and angular.h now properly include hacks.h to define MP_UNITS_HOSTED before its usage
      •  
    • fix: quantity scaling between different prefixes improved
      •  
    • fix: conversion operator to std::chrono types fixed
      •  
    • fix: std::format does not always use Char* as iterators
      •  
    • fix: complex_power & co fixed
      •  
    • fix: __cpp_deleted_function workaround for clang-19 added
      •  
    • test: conversion to chrono unit tests added
      •  
    • test: unit tests for creating a quantity from a volatile variable
      •  
    • test: increase tolerance for certain math tests to two epsilon by @burnpanck
      •  
    • test: std::complex-based quantities tests added
      •  
    • build: conanfile bumped to use catch2/3.7.0
      •  
    • build: conanfile bumped to use fmt/11.0.1
      •  
    • build: minimum required CMake version bumped to 3.25
      •  
    • build: duplicated cmake_minimum_required commands removed
      •  
    • build: minimum conan version set to 2.0.15
      •  
    • build: MSVC compilation enabled for the library part by @czjhoppe
      •  
    • build: Dockerfile updated for gitpod
      •  
    • build: generate() in test_package now correctly propagates project's options
      •  
    • build: target_include_directories is not needed anymore
      •  
    • build: target_compile_features now uses CMAKE_CXX_STANDARD
      •  
    • build: package_type is dynamically set in conanfile.py depending if we build modules or not
      •  
    • build(conan): packaging improved
      •  
    • ci: added test for upstream clang on macos-14, as an example for an arm64 platform by @burnpanck
      •  
    • style: pre-commit updated to clang-format-18.1.8
      •  
    • docs: \"Strong Angular System\" chapter added
      •  
    • docs: docs updated to use new spelling for Conan options
      •  
    • docs: \"Interface Introduction\" chapter updated
      •  
    • docs: St. Louis 2024 report added
      •  
    • docs: \"Radians and degrees support\" added
      •  
    • docs: Rework of \"Getting Started\" section
      •  
    • docs: \"API Reference\" support added (thanks @JohelEGP)
      •  
    • docs: \"Generating API reference\" chapter added
      •  
    • docs: minor formatting and spelling improvements to the \"CONTRIBUTING.md\"
      •  
    • docs: \"Unit symbols\" chapter added
      •  
    • docs: examples line numbers fixed
      •  
    • docs: \"Text Formatting\" tag removed from avg_speed example
      •  
    • docs: line breaks in mermaid graphs fixed
      •  
    • docs: 2.3.0 release added
      •  
    "},{"location":"release_notes/#2.2.1","title":"2.2.1 July 3, 2024","text":"
       
    • (!) feat: Conan and CMake options refactored
      •  
    "},{"location":"release_notes/#2.2.0","title":"2.2.0 June 14, 2024","text":"
       
    • (!) feat: C++ modules support added by @JohelEGP
      •  
    • (!) feat: New formatting specification implemented
      •  
    • (!) feat: has_unit_symbol support removed
      •  
    • (!) feat: ABI concerns resolved with introduction of u8 strings for symbols
      •  
    • (!) feat: API-related Conan, CMake, and preprocessor options redesigned
      •  
    • (!) feat: core.h removed
      •  
    • (!) feat: from now on units, dimensions, quantity specifications, and point origins have to be marked as final
      •  
    • feat: implicit point origins support added
      •  
    • feat: unit default point origin support added
      •  
    • feat: fma, isfinite, isinf, and isnan math function added by @NAThompson
      •  
    • feat: fma for quantity points added
      •  
    • feat: quantity_point support added for quantity_cast and value_cast
      •  
    • feat: value_cast<Unit, Representation> added
      •  
    • feat: value_cast<Quantity>(q), value_cast<Quantity>(qp) and value_cast<QuantityPoint>(qp) added by @burnpanck
      •  
    • feat: interconvertible(quantity_spec, quantity_spec) added
      •  
    • feat: qp.quantity_from_zero() added
      •  
    • feat: value_type type trait added
      •  
    • feat: do not print space between a number and percent or per_mille
      •  
    • feat: ppm parts per million added by @nebkat
      •  
    • feat: atan2 2-argument arctangent added by @nebkat
      •  
    • feat: fmod floating-point division remainder added by @nebkat
      •  
    • feat: remainder IEEE division remainder added by @nebkat
      •  
    • feat: std::format support added
      •  
    • feat: unit text output support added
      •  
    • feat: formatting error messages improved
      •  
    • feat: improve types readability by eliminating extraneous () in references, prefixes, and kind_of
      •  
    • feat: dimension and unit text output added
      •  
    • feat: some light and radiation ISQ quantities added
      •  
    • feat: allow configuring GSL library use
      •  
    • feat: freestanding support added
      •  
    • (!) refactor: zero_Fahrenheit renamed to zeroth_degree_Fahrenheit
      •  
    • (!) refactor: SI-related trigonometric functions moved to the si subnamespace
      •  
    • (!) refactor: math.h header file broke up to smaller pieces
      •  
    • (!) refactor: fixed_string interface refactored
      •  
    • (!) refactor: ReferenceOf does not take a dimension anymore
      •  
    • (!) refactor: 'o' replaced with '1' as a modifier for unit_symbol_solidus::one_denominator
      •  
    • (!) refactor: get_kind() now returns kind_of
      •  
    • (!) refactor: FMT macros moved to compat_macros.h
      •  
    • (!) refactor: fixed_string refactored to reflect the latest changes to P3094R2
      •  
    • (!) refactor: basic_symbol_text renamed to symbol_text
      •  
    • (!) refactor: ratio hidden as an implementation detail behind mag_ratio
      •  
    • (!) refactor: framework.h introduced
      •  
    • (!) refactor: type list tools made an implementation detail of the library
      •  
    • (!) refactor: header files with the entire system definitions moved up in the directory tree
      •  
    • (!) refactor: absolute_point_origin does not use CRTP anymore
      •  
    • refactor: system's units do not inherit from one another anymore
      •  
    • refactor: all units made final
      •  
    • refactor: math functions constraints refactored
      •  
    • refactor: si_quantities.h added to improve compile-times
      •  
    • refactor: validate_ascii_string refactored to is_basic_literal_character_set
      •  
    • refactor: underlying_type split to wrapped_type and value_type and used in code
      •  
    • refactor: code refactored to comply with clang-tidy
      •  
    • refactor: remove dependency on <ranges> header and switch to use an iterator-based copy algorithm
      •  
    • refactor: terminate replaced with abort and a header file added
      •  
    • refactor: most std::remove_const_t removed and some replaced with the GCC-specific workaround
      •  
    • refactor: not needed remove_reference_t and remove_cvref_t removed
      •  
    • refactor: binary operators of quantity and quantity_point are now hidden friends
      •  
    • fix: QuantityLike conversions required Q::rep instead of using one provided by quantity_like_traits
      •  
    • fix: quantity_spec[Unit] replaced with make_reference in value_cast
      •  
    • fix: ice_point is now defined with the integral offset from absolute_zero
      •  
    • fix: performance regression in sudo_cast fixed
      •  
    • fix: explicit object parameter support fixed
      •  
    • fix: missing version header file added to hacks.h
      •  
    • fix: quantity_cast to accept lvalue references (thanks @burnpanck)
      •  
    • fix: value_cast with lvalue references to quantity_point (thanks @burnpanck)
      •  
    • docs: project blog and first posts added
      •  
    • docs: project documentation layout refactored
      •  
    • docs: \"Interoperability with Other Libraries\" chapter added
      •  
    • docs: \"Framework Basics\" chapters updated and cleaned up
      •  
    • docs: smoot unit example added to the main page
      •  
    • docs: \"Code Example\" chapter renamed to \"Look and Feel\" and reordered in TOC to be after \"Quick Start\"
      •  
    • docs: \"Quick Start\" chapter reworked to be simpler and include quantity points
      •  
    • docs: \"Quantity points\" chapter extended
      •  
    • docs: \"The Affine Space\" chapter updated to reflect the recent design changes
      •  
    • docs: \"Working with Legacy interfaces\" chapter added
      •  
    • docs: \"Text Output\" chapter updated
      •  
    • docs: mkdocs social plugin enabled
      •  
    • docs: project logo and custom color scheme added
      •  
    • docs: minimum compiler requirements updated
      •  
    • docs: unit symbols admonition extended in the \"Quick Start\" chapter
      •  
    • docs: Cairo dependency described in the MkDocs section
      •  
    • docs: \"hello units\" example updated with dimensions output
      •  
    • docs: \"Text Output\" chapter updated with the recent formatting changes
      •  
    • docs: formatting grammar language changed to EBNF
      •  
    • docs: \"Project structure\" chapter expanded
      •  
    • docs: CITATION.cff updated
      •  
    • (!) build: Conan and CMake options refactored
      •  
    • (!) build: MP_UNITS_AS_SYSTEM_HEADERS renamed to MP_UNITS_BUILD_AS_SYSTEM_HEADERS
      •  
    • (!) build: MP_UNITS_BUILD_LA and MP_UNITS_IWYU CMake options now have _DEV_ in the name
      •  
    • build: gsl-lite updated to 0.41.0
      •  
    • build: catch2 updated to 3.5.1
      •  
    • build: fmt updated to 10.2.1
      •  
    • build: gitpod environment updated
      •  
    • build: check_cxx_feature_supported added
      •  
    • build: IWYU path handling fixed
      •  
    • build: IWYU enabled on GCC
      •  
    • build: CMAKE_EXPORT_COMPILE_COMMANDS flag enabled for the developer's build
      •  
    • build(conan): generate() now set cache_variables
      •  
    • build(conan): can_run check added before running tests
      •  
    • ci: Conan and CMake CI now use different cache names
      •  
    • ci: gcc-14 added
      •  
    • ci: clang-tidy CI added
      •  
    "},{"location":"release_notes/#2.1.1","title":"2.1.1 May 16, 2024","text":"
       
    • fix: unit tests compilation on gcc-14 fixed
      •  
    • fix: explicit this parameter support fixed
      •  
    "},{"location":"release_notes/#2.1.0","title":"2.1.0 December 9, 2023","text":"
       
    • (!) feat: inverse() support added for dimensions, quantity_spec, units, and references             (1 / s will now create quantity and not a Unit)
      •  
    • (!) feat: quantity_point does not provide zero() anymore
      •  
    • (!) feat: quantity_spec and its kind should not compare equal
      •  
    • (!) feat: mutating interface removed from fixed_string
      •  
    • (!) feat: common_type with a raw value is not needed anymore as for a long time now raw values are   not convertible to the dimensionless quantities
      •  
    • (!) feat: symbol_text definition simplified
      •  
    • (!) feat: users are now allowed to inherit their own types from absolute point origins
      •  
    • (!) feat: interoperability with other libraries redesigned
      •  
    • feat: basic_fixed_string(const CharT*, std::integral_constant<std::size_t, N>) constructor added
      •  
    • feat: isq::activity added and becquerel definition updated to benefit from it
      •  
    • feat: gray and sievert now have correct associated quantity kinds
      •  
    • feat: UnitCompatibleWith concept added and applied to in(U) and force_in(U) functions
      •  
    • feat: quantities can now be multiplied and divided by units (no parenthesis needed anymore)
      •  
    • feat: Magnitude / Unit operator added
      •  
    • feat: equality for dimensions now will allow derived classes as well (but not from derived_dimension)
      •  
    • feat: zero_Fahrenheit point origin added
      •  
    • feat: equivalent point origins handling improved
      •  
    • feat(example): unit symbols added to the currency example
      •  
    • (!) refactor: unit_symbol<fmt>(U) signature refactored and the resulting text can now also be used at runtime
      •  
    • (!) refactor: make_xxx factory functions replaced with two-parameter constructors
      •  
    • (!) refactor: unit_symbol changed to consteval
      •  
    • refactor: in(U) and force_in(U) now return auto to provide better diagnostics on clang
      •  
    • refactor: quantity operators constraints refactored
      •  
    • refactor: more type members added to fixed_string definition
      •  
    • refactor: unit_symbol_formatting enums now use std::int8_t as a representation type
      •  
    • fix: symbols of named dimensionless units with the ratio = 1 were not printed
      •  
    • fix: iterator is now properly updated for all cases in unit_symbol
      •  
    • fix: Fahrenheit conversion ratio was inverted
      •  
    • fix: CommonlyInvocableQuantities was overconstrained for the current library design
      •  
    • fix: are_ingredients_convertible now mandates explicit conversion for To dimensionless quantities
      •  
    • fix: quantity_point::point_for(PO) constraints fixed
      •  
    • fix(example): latitude and longitude fixed to include 0 for N and E respectively
      •  
    • ci: clang-17 enabled
      •  
    • ci: apple-clang-15 enabled
      •  
    • ci: Added C++23 builds to the CI matrix
      •  
    • docs: \"Getting Started\" chapters updated
      •  
    • docs: \"Basic Concepts\" and \"Interface Introduction\" chapters updated
      •  
    • docs: \"Design Overview\" chapter added and \"Concepts\" chapter reworked
      •  
    • docs: \"Output stream formatting\" chapter updated
      •  
    • docs: \"Default formatting\" chapter updated
      •  
    • docs: \"Derived unit symbols generation\" chapter added
      •  
    • docs: outdated affine space chapter updated
      •  
    • docs: CameCase concept identifiers FAQ added
      •  
    • docs: gravitational_potential_energy equation fixed on a graph
      •  
    • docs: YouTube video link updated to the C++ on Sea 2023
      •  
    • docs: ISO papers reference added to docs and README
      •  
    • docs: a representation type in a dimensionless quantity FAQ fixed
      •  
    • docs: titles added to some important admonitions
      •  
    • docs: \"Terms and Definitions\" slightly updated
      •  
    • docs: \"canonical unit\" added to glossary and its documentation in code was updated
      •  
    • docs: Design overview graph updated
      •  
    "},{"location":"release_notes/#2.0.0","title":"2.0.0 September 24, 2023","text":"
       
    • units namespace renamed to mp_units (#317)
      •  
    • header files in the <mp-units/...> rather then in <units/...> (#317)
      •  
    • the downcasting facility is removed (#383, #211, #32)
      •  
    • unified and simplified quantity creation (#274)
      •  
    • determining the best way to create a quantity (#413)
      •  
    • V2 quantity_point (#414)
      •  
    • introduction of quantity_spec to store not only dimension but also additional information about quantities (#405)
      •  
    • quantity now takes reference object, which aggregates quantity_spec and a unit and a representation type
      •  
    • units, prefixes, dimensions, quantity specifications, and references are passed as NTTPs to templates and provide arithmetic operations and comparison
      •  
    • expression templates consistently used in all derived types to increase the readability (#351, #166)
      •  
    • derived dimensions are now factors of only base dimensions (#281)
      •  
    • convertibility of derived quantities (#427)
      •  
    • dimensions, quantity specifications, units, and references are now composable, significantly reducing the number of definitions and resulting types
      •  
    • heavily simplified unit systems definitions (no need to define unnamed derived units, systems-specific dimensions, aliases for quantities, concepts, UDLs, ... anymore)
      •  
    • improved definition of all systems
      •  
    • support for ISO 80000 Part 3-6 quantities
      •  
    • faster than lightspeed constants (#169)
      •  
    • extensions to quantity formatting with fmt
      •  
    • quantity_kind removed
      •  
    • improved casting of unit with .in(Unit), .force_in(Unit) for quantity and quantity_spec
      •  
    • numerical value accessor safety improved with .numerical_value_in(Unit) and .force_numerical_value_in(Unit)
      •  
    • quantity can no longer be constructed with a raw value (#434)
      •  
    • Implicit construction of quantities from a value (#410)
      •  
    • quantity_point can no longer be constructed with just a quantity and an explicit PointOrigin is always needed
      •  
    • ceil and floor are dangerous (#432)
      •  
    • quecto, ronto, ronna, quetta new SI prefixes support
      •  
    • comparison against zero added (#487)
      •  
    • documentation rewritten from scratch
      •  
    • many smaller changes not possible to address with the previous design (#205, #210, #134)
      •  
    "},{"location":"release_notes/#0.8.0","title":"0.8.0 June 14, 2023","text":"
       
    • (!) refactor: common_quantity, common_quantity_for, common_quantity_point, common_quantity_kind, and common_quantity_point_kind removed
      •  
    • (!) refactor: named_derived_unit removed as it was not used
      •  
    • (!) refactor: derived_unit renamed to derived_scaled_unit
      •  
    • (!) refactor: unit renamed to derived_unit
      •  
    • (!) refactor: U::is_named removed from the unit types and replaced with NamedUnit concept
      •  
    • (!) refactor: PrefixFamily support removed
      •  
    • (!) refactor: mi(naut) renamed to nmi
      •  
    • (!) refactor: knot unit helper renamed to kn in FPS
      •  
    • (!) refactor: knot text symbol changed from \"knot\" to \"kn\"
      •  
    • refactor: quantity op+() and op-() reimplemented in terms of reference rather then quantity types
      •  
    • refactor(example): glide_computer now use dimensionless quantities with ranged_representation as rep
      •  
    • feat: HEP system support added (thanks @RalphSteinhagen)
      •  
    • feat: floor(), ceil(), and round() support added (thanks @hofbi)
      •  
    • feat: std::format support for compliant compilers added
      •  
    • feat: conversion helpers from mp-units to std::chrono types added
      •  
    • feat: math functions can now be safely used with user-defined types
      •  
    • feat: conversion from quantity_point to std::chrono::time_point added
      •  
    • feat: nautical_mile_per_hour and knot added to si::international system
      •  
    • (!) fix: add quantity_point::origin, like std::chrono::time_point::clock
      •  
    • fix: enable any prefixes for most of the named units (beside those that use prefixes already)
      •  
    • fix: hectare definition fixed to be a prefixed version of are + other units
      •  
    • fix: account for different dimensions in quantity_point_cast's constraint
      •  
    • fix: output stream operator now properly handles state
      •  
    • fix: fmt algorithms were overconstrained with forward_iterator
      •  
    • fix: CTAD for aliases fixed
      •  
    • fix: derived_ratio calculation
      •  
    • fix: fill_t assignment operator fixed
      •  
    • fix: improve downcast mode off
      •  
    • fix: radioactivity header compilation fixed
      •  
    • fix: si::hep::dim_momentum duplicated definition fixed
      •  
    • fix: fps can now coexist with international system
      •  
    • fix: public headers fixed to be standalone
      •  
    • test: standalone public headers tests added
      •  
    • (!) build: CMake generator in Conan is no longer obtained from an environment variable
      •  
    • (!) build: Required Conan version bumped to 1.48
      •  
    • (!) build: Conan 1.48 does not set CMAKE_BUILD_TYPE in the conan_toolchain.cmake anymore
      •  
    • build: AppleClang 13 support added (thanks @fdischner)
      •  
    • build: most of the conanfile.py refactored to be Conan 2.0 ready
      •  
    • build: validate() replaced with configure() to raise errors during conan install in Conan 1.X
      •  
    • build: minimum Conan version changed to 1.40
      •  
    • build: linear-algebra Conan repo is no needed anymore
      •  
    • build: Gitpod support added
      •  
    • build: clang-format-15 support added
      •  
    • build: export config to local build (#322)
      •  
    • build: fix export name of mp-units-system
      •  
    • build: fmt updated to 8.0.1
      •  
    • build: gsl-lite updated to 0.40.0
      •  
    • build: catch2 updated to 2.13.9
      •  
    • build: doxygen updated to 1.9.4
      •  
    • build: linear_algebra/0.7.0 switched to wg21-linear_algebra/0.7.2
      •  
    • ci: VS2022, gcc-11, clang-13, clang-14, and AppleClang 13 support added
      •  
    • ci: pre-commit support added (thanks @hofbi)
      •  
    • docs: Project documentation updated
      •  
    • docs: CITATION.cff file added
      •  
    • docs: CONTRIBUTING.md updated
      •  
    "},{"location":"release_notes/#0.7.0","title":"0.7.0 May 11, 2021","text":"
       
    • (!) refactor: ScalableNumber renamed to Representation
      •  
    • (!) refactor: output stream operators moved to the units/quantity_io.h header file
      •  
    • (!) refactor: Refactored the library file tree
      •  
    • (!) refactor: quantity::count() renamed to quantity::number()
      •  
    • (!) refactor: data system renamed to isq::iec80000 (quantity names renamed too)
      •  
    • (!) refactor: *deduced_unit renamed to *derived_unit
      •  
    • (!) refactor: got rid of a noble_derived_unit
      •  
    • refactor: quantity (kind) point updated to reflect latest changes to quantity
      •  
    • refactor: basic concepts, quantity and quantity_cast refactored
      •  
    • refactor: abs() definition refactored to be more explicit about the return type
      •  
    • feat: quantity (point) kind support added (thanks @johelegp)
      •  
    • feat: quantity references support added (thanks @johelegp)
      •  
    • feat: quantity aliases support addded
      •  
    • feat: interoperability with std::chrono::duration and other units libraries
      •  
    • feat: CTAD for dimensionless quantity added
      •  
    • feat: modulation_rate support added (thanks @go2sh)
      •  
    • feat: SI prefixes for isq::iec80000 support added (thanks @go2sh)
      •  
    • feat: a possibility to disable quantity UDLs support with UNITS_NO_LITERALS preprocessor define
      •  
    • feat: a support to define ISQ derived dimensions in terms of different number or order of components
      •  
    • perf: preconditions check do not influence the runtime performance of a Release build
      •  
    • perf: quantity_cast() generates less assembly instructions
      •  
    • perf: temporary string creation removed from quantity::op<<()
      •  
    • perf: value initialization for quantity value removed (left with a default initialization)
      •  
    • perf: limited the equivalent trait usage
      •  
    • perf: limited the C++ Standard Library headers usage
      •  
    • perf: rvalue references support added for constructors and getters
      •  
    • (!) fix: exp() has sense only for dimensionless quantities
      •  
    • (!) fix: dim_torque now properly divides by an angle (instead of multiply) + default unit name change
      •  
    • fix: quantity's operators fixed to behave like the underlying types do
      •  
    • fix: quantity_cast() fixed to work correctly with representation types not convertible from std::intmax_t
      •  
    • fix: ambiguous case for empty type list resolved
      •  
    • fix: downcasting facility for non-default-constructible types
      •  
    • fix: restore user-warnings within the library implementation
      •  
    • fix: the text symbol of foot_pound_force and foot_pound_force_per_second
      •  
    • fix: quantity modulo arithmetics fixed
      •  
    • (!) build: Conan testing version is now hosted on Artifactory
      •  
    • (!) build: Linear Algebra is now hosted on its Artifactory
      •  
    • (!) build: BUILD_DOCS CMake option renamed to UNITS_BUILD_DOCS
      •  
    • build: doxygen updated to 1.8.20
      •  
    • build: catch2 updated to 2.13.4
      •  
    • build: fmt updated to 7.1.3
      •  
    • build: ms-gsl replaced with gsl-lite/0.38.0
      •  
    • build: Conan generator switched to cmake_find_package_multi
      •  
    • build: Conan CMakeToolchain support added
      •  
    • build: CMake scripts cleanup
      •  
    • build: ccache support added
      •  
    • ci: CI switched from Travis CI to GitHub Actions
      •  
    "},{"location":"release_notes/#0.6.0","title":"0.6.0 September 13, 2020","text":"
       
    • feat: quantity_point support added (thanks @johelegp)
      •  
    • feat: Added angle as SI base dimension (thanks @kwikius)
      •  
    • feat: si::angular_velocity support added (thanks @mikeford3)
      •  
    • feat: FPS system added (thanks @mikeford3)
      •  
    • feat: Added support for mathematical function exp(quantity)
      •  
    • feat: Localization support for text output added (thanks @rbrugo)
      •  
    • feat: Added STL random number distribution wrappers (thanks @yasamoka)
      •  
    • (!) refactor: Refactored and cleaned up the library file tree
      •  
    • (!) refactor: q_* UDL renamed to _q_*
      •  
    • (!) refactor: UDLs with \"per\" in name renamed from *p* to *_per_*
      •  
    • (!) refactor: ratio changed to the NTTP kind
      •  
    • (!) refactor: exp and Exp renamed to exponent and Exponent
      •  
    • (!) refactor: Scalar concept renamed to ScalableNumber
      •  
    • (!) refactor: Dimensionless quantities redesigned to be of a quantity type
      •  
    • refactor: math.h function signatures refactored to use a Quantity concept (thanks @kwikius)
      •  
    • refactor: [[nodiscard]] added to many functions
      •  
    • fix: si::day unit symbol fixed to d (thanks @komputerwiz)
      •  
    • fix: si::mole unit symbol fixed to mol (thanks @mikeford3)
      •  
    • (!) build: gcc-9 is no longer supported (at least gcc-10 is required)
      •  
    • build: Visual Studio 16.7 support added
      •  
    • build: linear_algebra updated to 0.7.0/stable
      •  
    • build: fmt updated to 7.0.3
      •  
    • build: range-v3 updated to 0.11.0
      •  
    • build: catch2 updated to 2.13.0
      •  
    • build: doxygen updated to 1.8.18
      •  
    • build: ms-gsl 3.1.0 dependency added
      •  
    • build: Removed the dependency on a git submodule with common CMake scripts
      •  
    "},{"location":"release_notes/#0.5.0","title":"0.5.0 May 17, 2020","text":"
       
    • Major refactoring and rewrite of the library
      •  
    • Units are now independent from dimensions
      •  
    • Dimensions now depend on units (base or coherent units are provided in a class template)
      •  
    • Quantity gets a Dimension template parameter again (as unit does not provide information about   its dimension anymore)
      •  
    • Spaceship operator support added
      •  
    • Added official CGS system support
      •  
    • Added official data information system support
      •  
    • Repository file tree cleanup
      •  
    • ratio refactored to contain Exp template parameter (thanks a lot @oschonrock!)
      •  
    • SI fundamental constants added
      •  
    • q_ prefix applied to all the UDLs (thanks @kwikius)
      •  
    • unknown_unit renamed to unknown_coherent_unit
      •  
    • Project documentation greatly extended and switched to Sphinx
      •  
    • A few more usage examples added
      •  
    • ASCII-only output support added (thanks @yasamoka)
      •  
    • Representation values formatting extended (thanks @rbrugo)
      •  
    • Output streams formatting support added
      •  
    • Linear algebra from std::experimental::math support added
      •  
    • Named SI units and their dimensions added (thanks @rbrugo
      •  
    • libfmt updated to 6.2.0
      •  
    • Added absolute functions and epsilon to math.h (thanks @mikeford3)
      •  
    • Added a lot of prefixes to named units and introduced alias_unit (thanks @yasamoka)
      •  
    • Linking with Conan targets only when they exists (#98)
      •  
    • All physical dimensions and units put into physical namespace
      •  
    • CMake improvements
      •  
    • Velocity renamed to speed
      •  
     
    Many thanks to GitHub users @oschonrock, @kwikius, and @i-ky for their support in drafting a new library design.
    "},{"location":"release_notes/#0.4.0","title":"0.4.0 Nov 17, 2019","text":"
       
    • Support for derived dimensions in exp added
      •  
    • Added pow() and sqrt() operations on quantities
      •  
    • units removed from a std::experimental namespace
      •  
    • Downcasting facility refactored so the user does not have to write the boilerplate code anymore
      •  
    • From now on base dimensions should inherit from base_dimension class template
      •  
    • Added unit symbols definitions to base_dimension and derived units
      •  
    • Added support for operator<< on quantity
      •  
    • fmt support added
      •  
    • Derived unit factory helpers refactored
      •  
    • Refactored the way prefixed units are defined
      •  
    "},{"location":"release_notes/#0.3.1","title":"0.3.1 Sep 18, 2019","text":"
       
    • cmcstl2 dependency changed to range-v3 0.9.1
      •  
    "},{"location":"release_notes/#0.3.0","title":"0.3.0 Sep 16, 2019","text":"
       
    • The design as described on CppCon 2019 talk (https://youtu.be/0YW6yxkdhlU)
      •  
    • Applied the feedback from the Cologne evening session
      •  
    • upcasting_traits renamed to downcasting_traits
      •  
    • Dimension template parameter removed from quantity
      •  
    • units moved to a std::experimental namespace
      •  
    • Leading underscore prefix removed from UDLs
      •  
    • Added a few more derived dimensions
      •  
    • meter renamed to metre
      •  
    • Missing operator* added
      •  
    • Predefined dimensions moved to a dedicated directory
      •  
    • dimension_ prefix removed from names of derived dimensions
      •  
    • cmcstl2 library updated to 2019.09.19
      •  
    • base_dimension is a value provided as const& to the exp type
      •  
    • integrated with Compiler Explorer
      •  
    • gsl-lite dependency removed
      •  
    • Fractional dimension exponents support added
      •  
    • QuantityOf concept introduced
      •  
    • quantity_cast<U, Rep>() support added
      •  
    "},{"location":"release_notes/#0.2.0","title":"0.2.0 July 18, 2019","text":"
       
    • The design as described on C++Now 2019 talk (https://youtu.be/wKchCktZPHU)
      •  
    • Added C++20 features supported by gcc-9.1 (std::remove_cvref_t, down with typename, std::type_identity)
      •  
    • Compile-time performance optimizations (type_list, common_ratio, ratio, conditional_t)
      •  
    "},{"location":"release_notes/#0.1.0","title":"0.1.0 May 18, 2019","text":"
       
    • Initial library release
      •  
    • Begin semantic versioning
      •  
    • The last version to work with gcc-8
      •  
    "},{"location":"appendix/glossary/","title":"Glossary","text":""},{"location":"appendix/glossary/#iso-definitions","title":"ISO definitions","text":"
    Note
     
    The ISO terms provided below are only a few of many defined in the ISO/IEC Guide 99.
     quantity 
       
    • Property of a phenomenon, body, or substance, where the property has a magnitude that can   be expressed by means of a number and a reference.
      •  
    • A reference can be a measurement unit, a measurement procedure, a reference material,   or a combination of such.
      •  
    • A quantity as defined here is a scalar. However, a vector or a tensor, the components of   which are quantities, is also considered to be a quantity.
      •  
    • The concept \u2019quantity\u2019 may be generically divided into, e.g. \u2018physical quantity\u2019,   \u2018chemical quantity\u2019, and \u2018biological quantity\u2019, or \u2018base quantity\u2019   and \u2018derived quantity\u2019.
      •  
    • Examples of quantities are: length, radius, wavelength, energy, electric charge, etc.
      •  
     kind of quantity, kind 
       
    • Aspect common to mutually comparable quantities.
      •  
    • The division of the concept \u2018quantity\u2019 into several kinds is to some extent arbitrary, for example:
         
      • the quantities diameter, circumference, and wavelength are generally considered   to be quantities of the same kind, namely, of the kind of quantity called length,
        •  
      • the quantities heat, kinetic energy, and potential energy are generally considered   to be quantities of the same kind, namely of the kind of quantity called energy.
        •  
       
      •  
    • Quantities of the same kind within a given system of quantities   have the same quantity dimension. However, quantities   of the same dimension are not necessarily of the same kind.
         
      • For example, the quantities moment of force and energy are, by convention, not regarded   as being of the same kind, although they have the same dimension. Similarly for   heat capacity and entropy, as well as for number of entities, relative permeability,   and mass fraction.
        •  
       
      •  
     system of quantities 
       
    • Set of quantities together with a set of non-contradictory equations   relating those quantities.
      •  
    • Examples of systems of quantities are: the International System of Quantities,   the Imperial System, etc.
      •  
     base quantity 
       
    • Quantity in a conventionally chosen subset of a given   system of quantities, where no quantity in the   subset can be expressed in terms of the others.
      •  
    • Base quantities are referred to as being mutually independent since a base quantity   cannot be expressed as a product of powers of the other base quantities.
      •  
    • \u2018Number of entities\u2019 can be regarded as a base quantity in any   system of quantities.
      •  
     derived quantity 
       
    • Quantity, in a system of quantities, defined in   terms of the base quantities of that system.
      •  
     International System of Quantities, ISQ 
       
    • System of quantities based on the seven base quantities:   length, mass, time, electric current, thermodynamic temperature, amount of substance,   and luminous intensity.
      •  
    • This system of quantities is published in the ISO 80000 and IEC 80000 series Quantities and units.
      •  
    • The International System of Units (SI) is based on the ISQ.
      •  
     quantity dimension, dimension of a quantity, dimension 
       
    • Expression of the dependence of a quantity on the base quantities   of a system of quantities as a product of powers of factors corresponding   to the base quantities, omitting any numerical factor.
         
      • e.g. in the ISQ, the quantity dimension of force is denoted by \\(\\textsf{dim }F = \\mathsf{LMT}^{\u20132}\\).
        •  
       
      •  
    • A power of a factor is the factor raised to an exponent. Each factor is the dimension   of a base quantity.
      •  
    • In deriving the dimension of a quantity, no account is taken of its scalar, vector, or   tensor character.
      •  
    • In a given system of quantities:
         
      • quantities of the same kind have the same quantity dimension,
        •  
      • quantities of different quantity dimensions are always of different kinds,
        •  
      • quantities having the same quantity dimension are not necessarily of the same   kind.
        •  
       
      •  
    •  
      Symbols representing the dimensions of the base quantities in the ISQ are:
       Base quantity Symbol for dimension length \\(\\mathsf{L}\\) mass \\(\\mathsf{M}\\) time \\(\\mathsf{T}\\) electric current \\(\\mathsf{I}\\) thermodynamic temperature \\(\\mathsf{\u0398}\\) amount of substance \\(\\mathsf{N}\\) luminous intensity \\(\\mathsf{J}\\) 
      Thus, the dimension of a quantity \\(Q\\) is denoted by \\(\\textsf{dim }Q = \\mathsf{L}^\u03b1\\mathsf{M}^\u03b2\\mathsf{T}^\u03b3\\mathsf{I}^\u03b4\\mathsf{\u0398}^\u03b5\\mathsf{N}^\u03b6\\mathsf{J}^\u03b7\\) where the exponents, named dimensional exponents, are positive, negative, or zero.
       
      •  
     quantity of dimension one, dimensionless quantity 
       
    • quantity for which all the exponents of the factors corresponding to the     base quantities in its quantity dimension are zero.
      •  
    • The term \u201cdimensionless quantity\u201d is commonly used and is kept here for historical     reasons. It stems from the fact that all exponents are zero in the symbolic     representation of the dimension for such quantities.     The term \u201cquantity of dimension one\u201d reflects the convention in which the symbolic     representation of the dimension for such quantities is     the symbol \\(1\\).
      •  
    • The measurement units and values of quantities of     dimension one are numbers, but such quantities convey more information than a number.
      •  
    • Some quantities of dimension one are defined as the ratios of two     quantities of the same kind.
      •  
    • Numbers of entities are quantities of dimension one.
      •  
     measurement unit, unit of measurement, unit 
       
    • Real scalar quantity, defined and adopted by convention, with which any other   quantity of the same kind can be compared to express the ratio of the two   quantities as a number.
      •  
    • Measurement units are designated by conventionally assigned names and symbols.
      •  
    • Measurement units of quantities of the same quantity dimension   may be designated by the same name and symbol even when the quantities are   not of the same kind.
         
      • For example, joule per kelvin and J/K are respectively the name and symbol of both a   measurement unit of heat capacity and a measurement unit of entropy, which are generally   not considered to be quantities of the same kind.
        •  
       
      •  
    • However, in some cases special measurement unit names are restricted to be used with   quantities of specific kind only.
         
      • For example, the measurement unit \u2018second to the power minus one\u2019   (\\(\\mathsf{1/s}\\)) is called hertz (\\(\\mathsf{Hz}\\)) when used for frequencies and   becquerel (\\(\\mathsf{Bq}\\)) when used for activities of radionuclides. As another example,   the joule (\\(\\mathsf{J}\\)) is used as a unit of energy, but never as a unit of moment of   force, e.g. the newton metre (\\(\\mathsf{N\u00b7m}\\)).
        •  
       
      •  
    • Measurement units of quantities of dimension one are   numbers. In some cases, these measurement units are given special names, e.g. radian,   steradian, and decibel, or are expressed by quotients such as millimole per mole equal   to \\(10^{\u22123}\\) and microgram per kilogram equal to \\(10^{\u22129}\\).
      •  
     base unit 
       
    • Measurement unit that is adopted by convention for a base quantity.
      •  
    • In each coherent system of units, there is only one base unit   for each base quantity.
         
      • e.g. in the SI, the metre is the base unit of length. In the CGS systems,   the centimetre is the base unit of length.
        •  
       
      •  
    • A base unit may also serve for a derived quantity of the same   quantity dimension.
      •  
    • For number of entities, the number one, symbol \\(1\\), can be regarded as a base unit in   any system of units.
      •  
     derived unit 
       
    • Measurement unit for a derived quantity.
      •  
    • For example, the metre per second, symbol m/s, and the centimetre per second, symbol cm/s,   are derived units of speed in the SI. The kilometre per hour, symbol km/h, is a   measurement unit of speed outside the SI but accepted for use with   the SI. The knot, equal to one nautical mile per hour, is a measurement unit of speed   outside the SI.
      •  
     coherent derived unit 
       
    • Derived unit that, for a given system of quantities   and for a chosen set of base units, is a product of powers of   base units with no other proportionality factor than one.
      •  
    • A power of a base unit is the base unit raised to an exponent.
      •  
    • Coherence can be determined only with respect to a particular   system of quantities and a given set of base units.
         
      • For example, if the metre, the second, and the mole are base units, the metre per second is   the coherent derived unit of velocity when velocity is defined by the   quantity equation \\(v = \\mathsf{d}r/\\mathsf{d}t\\), and the mole per   cubic metre is the coherent derived unit of amount-of-substance concentration when   amount-of-substance concentration is defined by the quantity equation \\(c = n/V\\). The kilometre per hour and the knot, given as examples of derived units,   are not coherent derived units in such a system of quantities.
        •  
       
      •  
    • A derived unit can be coherent with respect to one   system of quantities but not to another.
         
      • For example, the centimetre per second is the coherent derived unit of speed in a CGS system   of units but is not a coherent derived unit in the SI.
        •  
       
      •  
    • The coherent derived unit for every derived quantity of dimension one   in a given system of units is the number one, symbol \\(1\\). The name and   symbol of the measurement unit one are generally not indicated.
      •  
     system of units 
       
    • Set of base units and derived units, together with   their multiples and submultiples, defined in accordance with given rules, for a given   system of quantities.
      •  
     coherent system of units 
       
    • System of units, based on a given system of quantities,   in which the measurement unit for each derived quantity is   a coherent derived unit.
      •  
    • A system of units can be coherent only with respect to a   system of quantities and the adopted base units.
      •  
    • For a coherent system of units, numerical value equations have   the same form, including numerical factors, as the corresponding   quantity equations.
      •  
     off-system measurement unit, off-system unit 
       
    • Measurement unit that does not belong to a given system of units.
      •  
    • For example, the electronvolt (about \\(1.602\\;18 \u00d7 10^{\u201319}\\;\\mathsf{J}\\)) is an   off-system measurement unit of energy with respect to the SI. Day, hour, minute   are off-system measurement units of time with respect to the SI.
      •  
     International System of Units, SI 
       
    • System of units, based on the International System of Quantities,   their names and symbols, including a series of prefixes and their names and symbols,   together with rules for their use, adopted by the General Conference on Weights and   Measures (CGPM).
      •  
     quantity value, value of a quantity, value 
       
    • Number and reference together expressing magnitude of a quantity.
         
      • For example, length of a given rod: \\(5.34\\;\\mathsf{m}\\) or \\(534\\;\\mathsf{cm}\\).
        •  
       
      •  
    • The number can be complex.
      •  
    • A quantity value can be presented in more than one way.
      •  
    • In the case of vector or tensor quantities, each component has a quantity value.
         
      • For example, force acting on a given particle, e.g. in Cartesian components   \\((F_x; F_y; F_z) = (\u221231.5; 43.2; 17.0)\\;\\mathsf{N}\\).
        •  
       
      •  
     numerical quantity value, numerical value of a quantity, numerical value 
       
    • Number in the expression of a quantity value, other than any number serving   as the reference
         
      • For example, in an amount-of-substance fraction equal to \\(3\\;\\mathsf{mmol/mol}\\), the numerical   quantity value is \\(3\\) and the unit is \\(\\mathsf{mmol/mol}\\). The unit \\(\\mathsf{mmol/mol}\\) is numerically equal to \\(0.001\\), but this number \\(0.001\\) is not part   of the numerical quantity value, which remains \\(3\\).
        •  
       
      •  
     quantity equation 
       
    • Mathematical relation between quantities in a given system of quantities,   independent of measure\u00adment units.
      •  
    • For example, \\(T = (1/2) mv^2\\) where \\(T\\) is the kinetic energy and \\(v\\) the speed   of a specified particle of mass \\(m\\).
      •  
     unit equation 
       
    • Mathematical relation between base units,   coher\u00adent derived units or other measurement units.
      •  
    • For example, \\(\\mathsf{J} := \\mathsf{kg}\\:\\mathsf{m}^2/\\mathsf{s}^2\\), where, \\(\\mathsf{J}\\),   \\(\\mathsf{kg}\\), \\(\\mathsf{m}\\), and \\(\\mathsf{s}\\) are the symbols for the joule, kilogram,   metre, and second, respectively. (The symbol \\(:=\\) denotes \u201cis by definition equal to\u201d   as given in the ISO 80000 and IEC 80000 series.). \\(1\\;\\mathsf{km/h} = (1/3.6)\\;\\mathsf{m/s}\\).
      •  
     numerical value equation, numerical quantity value equation 
       
    • Mathematical relation between numerical quantity values, based on   a given quantity equation and specified measurement units.
      •  
    • For example, in the quantity equation for kinetic energy of a particle,   \\(T = (1/2) mv^2\\), if \\(m = 2\\;\\mathsf{kg}\\) and \\(v = 3\\;\\mathsf{m/s}\\),   then \\({T} = (1/2)\\:\u00d7\\:2\\:\u00d7\\:3^2\\) is a numerical value equation giving the numerical value   \\(9\\) of \\(T\\) in joules.
      •  
    "},{"location":"appendix/glossary/#other-definitions","title":"Other definitions","text":"
    Info
     
    The below terms extend the official ISO glossary and are commonly referred to by the mp-units library.
     base dimension 
       
    • A dimension of a base quantity.
      •  
     derived dimension 
       
    • A dimension of a derived quantity.
      •  
    • Implemented as a symbolic expression being the result of the   dimension equation on base dimensions.
      •  
     dimension equation 
       
    • Mathematical relation between dimensions in a given   system of quantities, independent of measure\u00adment units.
      •  
     quantity kind hierarchy, quantity hierarchy 
       
    • Quantities of the same kind form a hierarchy that determines their:
         
      • convertibility (e.g. every width is a length, but width should not be   convertible to height)
        •  
      • common quantity type (e.g. width + height -> length)
        •  
       
      •  
     quantity character, character of a quantity, character 
       
    • Scalars, vectors and tensors are mathematical objects that can be used to denote   certain physical quantities and their values.   They are as such independent of the particular choice of a coordinate system,   whereas each scalar component of a vector or a tensor and each component vector   and component tensor depend on that choice.
      •  
    • A vector is a tensor of the first order and a scalar is a tensor of order zero.
      •  
    • For vectors and tensors, the components are quantities that can be   expressed as a product of a number and a unit.
      •  
    • Vectors and tensors can also be expressed as a numerical value vector or tensor,   respectively, multiplied by a unit.
      •  
    • Quantities of different characters support different set of operations.
         
      • For example, a quantity can be multiplied by another one only if any   of them has scalar character. Vectors and tensors can't be multiplied or divided,   but they support additional operations like dot and cross products, which   are not available for scalars.
        •  
       
      •  
    • The term \u2019character\u2019 was borrowed from the below quote:
      •  
     
    ISO 80000-1_2009
     
    In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
     quantity specification, quantity_spec 
       
    • An entity storing all the information about a specific quantity:
         
      • location in a quantity hierarchy
        •  
      • quantity equation
        •  
      • dimension of a quantity
        •  
      • quantity kind
        •  
      • quantity character
        •  
      • additional constraints (e.g. non-negative)
        •  
       
      •  
    • Dimension of a quantity is not enough to specify all the properties of   a quantity.
      •  
     unit with an associated quantity, associated unit 
       
    • Unit that is used to measure quantities of a specific kind in a given   system of units.
      •  
     quantity reference, reference 
       
    • According to its definition, quantity can be expressed by means of   a number and a reference
      •  
    • In the mp-units library, a reference describes all the required meta-information   associated with a specific quantity (quantity specification and   unit).
      •  
     canonical representation of a unit, canonical unit 
       
    • A canonical representation of a unit consists of:
         
      • a reference unit being the result of extraction of all the intermediate   derived units,
        •  
      • a magnitude being a product of all the prefixes and magnitudes of extracted scaled units.
        •  
       
      •  
    • All units having the same canonical unit are deemed equal.
      •  
    • All units having the same reference unit are convertible   (their magnitude may differ and is used during conversion).
      •  
     reference unit 
    See canonical representation of a unit
     absolute quantity point origin, absolute point origin 
       
    • An explicit point on an axis of values of a specific quantity type that serves   as an absolute reference point for all quantity points which definitions   are (explicitly or implicitly) based on it.
      •  
    • For example, mean sea level is commonly used as an absolute reference point to measure altitudes.
      •  
     relative quantity point origin, relative point origin 
       
    • An explicit, known at compile-time, point on an axis of values of a specific quantity   type serving as a reference for other quantities.
      •  
    • For example, an ice point is a quantity point with a value of \\(273.15\\;\\mathsf{K}\\) that   is used as the zero point of a degree Celsius scale.
      •  
     quantity point origin, point origin 
       
    • Either an absolute point origin or   a relative point origin.
      •  
     quantity point, absolute quantity 
       
    • An absolute quantity with respect to an origin.
      •  
    • For example, timestamp (as opposed to duration), altitude (as opposed to height),   absolute temperature (as opposed to temperature difference).
      •  
    "},{"location":"appendix/references/","title":"References","text":"ISO80000 
    ISO 80000-1:2009(E) \"Quantities and units \u2014 Part 1: General\", International Organization for Standardization.
     Quincey \"Angles in the SI: a detailed proposal for solving the problem, Quincey, Paul (1 October 2021). SIBrochure 
    The International System of Units (SI), International Bureau of Weights and Measures (20 May 2019), ISBN 978-92-822-2272-0.
    "},{"location":"blog/","title":"Blog","text":""},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/","title":"What's new in mp-units 2.0?","text":"
    After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from GitHub and Conan.
     
    The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe some of them in this post.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#why-20-if-10-was-never-released","title":"Why 2.0 if 1.0 was never released?","text":"
    Version 2 of the mp-units project is a huge change and a new quality for the users. We did not want to pretend that 2.0 is an evolutionary upgrade of the previous version of the project. It feels like a different product.
     
    We could start a new repo named \"mp-units-v2\" similarly to range-v3 but we decided not to go this path. We kept the same repo and made the scope of the changes and potential breakage explicit with a drastic bump in the project version.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-has-changed","title":"What has changed?","text":"
    The answer is \"nearly everything\". The whole library and its documentation were rewritten nearly from scratch.
     
    Here are the significant changes that the users can observe:
     
       
    •  
      Repository name
       
      If you didn't notice, the repository name was changed from \"mpusz/units\" to \"mpusz/mp-units\".
       
      •  
    •  
      Header files content and layout
       
      Previously, all the header files resided in the include/units directory. Now, they can be found in include/mp-units. The project file tree was significantly changed as well. Many files were moved to different subdirectories or renamed.
       
      •  
    •  
      Namespace
       
      Previously, all the definitions were provided in the units namespace, and now they are in the mp_units one.
       
      •  
    •  
      Abstractions, interfaces, definitions
       
      The interfaces of all of the types were refactored. We got unit symbols and a new way to construct a quantity and quantity_point. The readability of the generated types was improved thanks to the introduction of expression templates. Nearly all of the template arguments are now passed by values thanks to class NTTP extensions in C++20. As a result, unit definitions are much easier and terser. Also, the V2 has a powerful ability to model systems of quantities and provides definitions for many ISQ quantities.
       
      •  
    •  
      Conan 2.0
       
      Also, now we support Conan 2.0, which provides an updated way of handling dependencies.
       
      •  
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-is-gone","title":"What is gone?","text":"
    Some cornerstones of the initial design did not prove in practice and were removed while we moved to version 2.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#the-downcasting-facility","title":"The downcasting facility","text":"
    The first and the most important of such features was removing the downcasting facility. This feature is still a powerful metaprogramming technique that allows users to map long class template instantiations to nicely named, short, and easy-to-understand user's strong types.
     
    Such mapping works perfectly fine for 1-to-1 relationships. However, we often deal with N-to-1 connections in the quantities and units domain. Here are only a few such examples:
     
       
    • work and torque have the same dimension \\(L^2MT^{-2}\\),
      •  
    • becquerel and hertz have the same definition of \\(s^{-1}\\),
      •  
    • litre and cubic decimetre have the same factor.
      •  
     
    In the above examples, multiple entities \"wanted\" to register different names for identical class template instantiations, resulting in compile-time errors. We had to invent some hacks and workarounds to make it work, but we were never satisfied with the outcome.
     
    Additionally, this facility could easily lead to ODR violations or provide different results depending on which header files were included in the translation units. This was too vulnerable to be considered a good practice here.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-udls-anymore","title":"No UDLs anymore","text":"
    Over the years, we have learned that UDLs are not a good solution. More information on this subject can be found in the Why don't we use UDLs to create quantities? chapter.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-construction-of-a-quantity-from-a-raw-value","title":"No construction of a quantity from a raw value","text":"
    To improve safety, we no longer allow the construction of quantities from raw values. In the new design, we always need to explicitly specify a unit to create a quantity:
     
    quantity q1 = 42 * m;\nquantity<si::metre> = 2 * km;\nquantity q3(42, si::metre);\n
     
    The previous approach was reported to be error-prone under maintenance. More on this subject can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
    "},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#new-look-and-feel","title":"New look and feel","text":"
    Here is a concise example showing you the new look and feel of the library:
     
    #include <mp-units/format.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n#include <format>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity<isq::speed[m / s]> avg_speed(quantity<si::metre> d,\n                                      quantity<si::second> t)\n{ return d / t; }\n\nint main()\n{\n  auto speed = avg_speed(220 * km, 2 * h);\n  std::println(\"{}\", speed);  // 30.5556 m/s\n}\n
     
    All of the changes we provided, although breaking ones, resulted in much better, easier, and safer abstractions. These offer a new quantity on the market and hopefully will be appreciated by our users.
     
    Please check our new documentation to learn about the latest version of the project and find out how to benefit from all the new cool stuff we have here.
    "},{"location":"blog/2023/12/09/mp-units-210-released/","title":"mp-units 2.1.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe the most important of them in this post.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#no-more-parenthesis-while-creating-quantities-with-derived-units","title":"No more parenthesis while creating quantities with derived units","text":"
    The V2 design introduced a way to create a quantity by multiplying a raw value and a unit:
     
    quantity q1 = 42 * m;\n
     
    However, this meant that when we wanted to create a quantity having a derived unit, we had to put parenthesis around the unit equation or create a custom value of the named unit:
     
    quantity q2 = 60 * (km / h);\n\nconstexpr auto kmph = km / h;\nquantity q3 = 60 * kmph;\n\nquantity q4 = 50 * (1 / s);\n
     
    With the new version, we removed this restriction, and now we can type:
     
    quantity q5 = 60 * km / h;\nquantity q6 = 50 / s;\n
     
    As a side effect, we introduced a  breaking change . We can't use the following definition of hertz anymore:
     
    inline constexpr struct hertz : named_unit<\"Hz\", 1 / second, kind_of<isq::frequency>> {} hertz;\n
     
    and have to type either:
     
    inline constexpr struct hertz : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\n
     
    or
     
    inline constexpr struct hertz : named_unit<\"Hz\", inverse(second), kind_of<isq::frequency>> {} hertz;\n
     
    To be consistent, we applied the same change to the dimensions and quantity specifications definitions. Now, to define a frequency we have to type:
     C++23C++20Portable 
    inline constexpr struct frequency : quantity_spec<inverse(period_duration)> {} frequency;\n
     
    inline constexpr struct frequency : quantity_spec<frequency, inverse(period_duration)> {} frequency;\n
     
    QUANTITY_SPEC(frequency, inverse(period_duration));\n
    "},{"location":"blog/2023/12/09/mp-units-210-released/#make_xxx-factory-functions-replaced-with-two-parameter-constructors","title":"make_xxx factory functions replaced with two-parameter constructors","text":"
    In the initial version of the V2 framework, if someone did not like the multiply syntax to create a quantity we provided the make_quantity() factory function. A similar approach was used for quantity_point creation.
     
    This version removes those ( breaking change ) and introduces two parameter constructors:
     
    quantity q(42, si::metre);\nquantity_point qp(q, mean_sea_level);\n
     
    The above change encourages a better design and results in a terser code.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#improved-definitions-of-becquerel-gray-and-sievert","title":"Improved definitions of becquerel, gray, and sievert","text":"
    In the initial V2 version, we lacked the definitions of the atomic and nuclear physics quantities, which resulted in simplified and unsafe definitions of becquerel, gray, and sievert units. We still do not model most of the quantities from this domain, but we've added the ones that are necessary for the definition of those units.
     
    Thanks to the above, the following expressions will not compile:
     
    quantity q1 = 1 * Hz + 1 * Bq;\nquantity<si::sievert> q2 = 42 * Gy;\n
    "},{"location":"blog/2023/12/09/mp-units-210-released/#compatibility-with-other-libraries-redesigned","title":"Compatibility with other libraries redesigned","text":"
    Another significant improvement in this version was redesigning the way we provide compatibility with other similar libraries. The interfaces of quantity_like_traits and quantity_point_like_traits were changed and extended to provide conversion not only from but also to entities from other libraries ( breaking change ).
     
    We've also introduced an innovative approach that allows us to specify if such conversions should happen implicitly or if they need to be forced explicitly.
     
    More on this subject can be found in the Interoperability with Other Libraries chapter.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#point-origins-can-now-be-derived-from-each-other","title":"Point origins can now be derived from each other","text":"
    Previously, each class derived from absolute_point_origin was considered a unique independent point origin. On the other hand, it was OK to derive multiple classes from the same relative_point_origin, and those were specifying the same point in the domain. We found this confusing and limiting. This is why, in this version, the absolute_point_origin uses a CRTP idiom to be able to detect between points that should be considered different from the ones that should be equivalent.
     
    If we derive from the same instantiation of absolute_point_origin we end up with an equivalent point origin. This change allows us to provide different names for the same temperature points:
     
    inline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<absolute_zero + 273.15 * kelvin> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\n
     
    Please note that this is a  breaking change  as well.
    "},{"location":"blog/2023/12/09/mp-units-210-released/#unit-symbol-text-can-now-be-properly-used-at-runtime","title":"Unit symbol text can now be properly used at runtime","text":"
    The interface of the previous definition of unit_symbol function allowed the use of the returned buffer only at compile-time. This was too limiting as users often want to use unit symbols at runtime (e.g., print them to the console). The new version redesigned the interface of this function ( breaking change ) to return a buffer that can be properly used at both compilation and runtime:
     
    std::string_view unit1 = unit_symbol(m / s);\nstd::cout << unit1 << \"\\n\";     // m/s\nstd::string_view unit2 = unit_symbol<{.solidus = unit_symbol_solidus::never}>(m / s);\nstd::cout << unit2 << \"\\n\";     // m s\u207b\u00b9\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/","title":"mp-units 2.2.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    Among other features, this release provides long-awaited support for C++20 modules, redesigns and enhances text output formatting, and greatly simplifies quantity point usage. This post describes those and a few other smaller interesting improvements, while a much longer list of the most significant changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#c20-modules-and-project-structure-cleanup","title":"C++20 modules and project structure cleanup","text":"
    GitHub Issue #7 was our oldest open issue before this release. Not anymore. After 4.5 years, we finally closed it, even though the C++ modules' support is still really limited.
     
    Info
     
    To benefit from C++ modules, we need at least:
     
       
    • CMake 3.29.3
      •  
    • Ninja 1.11
      •  
    • clang-17
      •  
     
    In the upcoming months, hopefully, the situation will improve with the bug fixes in CMake, gcc-14, and MSVC.
     
    Note
     
    More requirements for C++ modules support can be found in the CMake's documentation.
     
    To enable the compilation and distribution of C++ modules, a cxx_modules Conan or MP_UNITS_BUILD_CXX_MODULES CMake option has to be enabled.
     
    With the above, the following C++ modules will be provided:
     
    flowchart TD\n    mp_units --- mp_units.systems --- mp_units.core
     C++ Module CMake Target Contents mp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems 
    The easiest way to use them is just to import mp_units; at the beginning of your translation unit (see the Quick Start chapter for some usage examples).
     
    Note
     
    C++20 modules support still have some issues when imported from the installed CMake target. See the following GitLab issue for more details.
     
    In this release, we also highly limited the number of CMake targets ( breaking change ). Now, they correspond exactly to the C++ modules they provide. This means that many smaller partial targets were removed. We also merged text output targets with the core library's definition.
     
    The table below specifies where we can now find the contents of previously available CMake targets:
     Before Now mp-units::utility mp-units::core mp-units::core-io mp-units::core mp-units::core-fmt mp-units::core mp-units::{system_name} mp-units::systems 
    While we were enabling C++ modules, we also had to refactor our header files slightly ( breaking change ). Some had to be split into smaller pieces (e.g., math.h), while others had to be moved to a different subdirectory (e.g., chrono.h).
     
    In version 2.2, the following headers have a new location or contents:
     Header File C++ Module Contents mp-units/math.h mp_units.core System-independent functions only mp-units/systems/si/math.h mp_units.systems Trigonometric functions using si::radian mp-units/systems/angular/math.h mp_units.systems Trigonometric functions using angular::radian mp-units/systems/si/chrono.h mp_units.systems std::chrono compatibility traits 
    Benefiting from this opportunity, we also cleaned up core and systems definitions ( breaking change ).
     
    Regarding the library's core, we removed core.h and exposed only one header framework.h that provides all of the library's framework so the user does not have to enumerate files like unit.h, quantity.h, and quantity_point.h anymore. Those headers are not gone, they were put to the mp-units/framework subheader. So they are still there if you really need them.
     
    Regarding the changes in systems definitions, we moved the wrapper header files with the entire system definition to the mp-units/systems subdirectory. Additionally, they now also include framework.h, so a system include is enough to use the library. Thanks to that our users don't have to write tedious code like the below anymore:
     NowBefore 
    #include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n\n// ...\n
     
    #include <mp-units/quantity_point.h>\n#include <mp-units/systems/cgs/cgs.h>\n#include <mp-units/systems/international/international.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n\n// ...\n
     
    Additionally, we merged all of the compatibility-related macros into one header file mp-units/compat_macros.h. This header file should be explicitly included before importing C++ modules if we want to benefit from the Wide Compatibility tools.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#better-control-over-the-librarys-api","title":"Better control over the library's API","text":"
    With this release, nearly all of the Conan and CMake build options were refactored with the intent of providing better control over the library's API.
     
    Previously, the library used the latest available feature set supported by a specific compiler. For example, quantity_spec definitions would use CRTP on an older compiler or provide a simpler API on a newer one thanks to the C++23 this deduction feature. This could lead to surprising results where the same code written by the user would compile fine on one compiler but not the other.
     
    From this release, all API extensions have their corresponding configuration options in Conan and CMake. With this, a user has full control over the API exposed by the library. Those options expose three values:
     
       
    • True - The feature is always enabled (the configuration error will happen if the compiler does   not support this feature)
      •  
    • False - The feature is disabled, and an older alternative is always used.
      •  
    • Auto - The feature is automatically enabled if the compiler supports it (old behavior).
      •  
     
    Additionally, some CMake options were renamed to better express the impact on our users ( breaking change ). For example, now CMake options include:
     
       
    • MP_UNITS_API_* - options affecting the library's API,
      •  
    • MP_UNITS_BUILD_* - options affecting the build process,
      •  
    • MP_UNITS_DEV_* - options primarily useful for the project developers or people who want to   compile our unit tests and examples.
      •  
    "},{"location":"blog/2024/06/14/mp-units-220-released/#configurable-contracts-checking","title":"Configurable contracts checking","text":"
    Before this release, the library always depended on gsl-lite to perform runtime contract and asserts checking. In this release we introduced new options to control if contract checking should be based on gsl-lite, ms-gsl, or may be completely disabled.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#freestanding-support","title":"Freestanding support","text":"
    From this release it is possible to configure the library in the freestanding mode. This limits the functionality and interface of the library to be compatible with the freestanding implementations.
     
    Info
     
    To learn more, please refer to the Build options chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#simplified-quantity-point-support","title":"Simplified quantity point support","text":"
    This release significantly simplifies the usage of quantity points and affine space abstractions in general.
     
    Previously, the user always had to define an explicit point origin even if the domain being modeled does not have such an explicit origin. Now, in such cases, we can benefit from the implicit point origins. For example:
     NowBefore 
    quantity_point price_usd{100 * USD};\n
     
    constexpr struct zero final : absolute_point_origin<currency> {} zero;\n\nquantity_point price_usd = zero + 100 * USD;\n
     
    As we can see above, the new design allows direct-initializing quantity_point class template from a quantity, but only if the former one is defined in terms of the implicit point origin. Otherwise, an explicit origin still always has to be provided during initialization.
     
    Also, we introduced the possibility of specifying a default point origin in the unit definition. With that, we could provide proper temperature scales without forcing the user to always use the origins explicitly. Also, a new member function, .quantity_from_zero(), was introduced that always returns the quantity from the unit's specific point origin or from the implicit point origin otherwise.
     NowBefore 
    quantity_point temp{20 * deg_C};\nstd::cout << \"Temperature: \" << temp << \" (\"\n          << temp.in(deg_F).quantity_from_zero() << \", \"\n          << temp.in(K).quantity_from_zero() << \")\\n\";\n
     
    quantity_point temp = si::zeroth_degree_Celsius + 20 * deg_C;\nstd::cout << \"Temperature: \" << temp << \" (\"\n          << temp.in(deg_F).quantity_from(usc::zeroth_degree_Fahrenheit) << \", \"\n          << temp.in(K).quantity_from(si::zeroth_kelvin) << \")\\n\";\n
     
    More information about the new design can be found in The Affine Space chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#unified-temperature-point-origins-names","title":"Unified temperature point origins names","text":"
    By omission, we had the following temperature point origins in the library:
     
       
    • si::zero_kelvin (for si::kelvin),
      •  
    • si::zeroth_degree_Celsius (for si::degree_Celsius),
      •  
    • usc::zero_Fahrenheit (for usc::degree_Fahrenheit).
      •  
     
    With this release, the last one was renamed to usc::zeroth_degree_Fahrenheit to be consistently named with its corresponding unit and with the si::zeroth_degree_Celsius ( breaking change ).
    "},{"location":"blog/2024/06/14/mp-units-220-released/#changes-to-units-definitions","title":"Changes to units definitions","text":"
    There were several known issues when units were deriving from each other (e.g., #512 and #537). We could either highly complicate the framework to allow these which could result in much longer compilation times or disallow inheriting from units at all. We chose the second option.
     
    With this release all of of the units must be marked as final. To enforce this we have changed the definition of the Unit<T> concept, which now requires type T to be final ( breaking change ).
     
    WG21 Study Group 16 (Unicode) raised concerns about potential ABI issues when different translation units are compiled with different ordinary literal encodings. Those issues were resolved with a change to units definitions ( breaking change ). It affects only units that specify both Unicode and ASCII symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal.
     
    This also means that the basic_symbol_text has fixed character types for both symbols. This is why it was renamed to symbol_text ( breaking change ).
     NowBefore 
    inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    inline constexpr struct ohm : named_unit<basic_symbol_text{\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    Note
     
    On C++20-compliant compilers it should be enough to type the following in the unit's definition:
     
    inline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/#changes-to-dimension-quantity-specification-and-point-origins-definitions","title":"Changes to dimension, quantity specification, and point origins definitions","text":"
    Similarly to units, now also all dimensions, quantity specifications, and point origins have to be marked final ( breaking change ).
     NowBefore 
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length final : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin  = absolute_zero;\ninline constexpr struct kelvin final : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point final : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\ninline constexpr struct degree_Celsius final : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n
     
    inline constexpr struct dim_length : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\ninline constexpr struct kelvin : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\ninline constexpr struct degree_Celsius : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n
     
    Please also note, that the absolute_point_origin does not use CRTP idiom anymore ( breaking change ).
    "},{"location":"blog/2024/06/14/mp-units-220-released/#improved-text-output","title":"Improved text output","text":"
    With this release, we can print not only whole quantities but also just their units or dimensions. Also, we fixed the std::format support so users can now enjoy full C++20 compatibility and don't have to use fmtlib anymore.
     
    We have also changed the grammar for quantities formatting ( breaking change ). It introduces the composition of underlying formatters that finally allows us to properly format user-defined representation types (assuming they have std::format support). Additionally, thanks to a new %? token, we can provide a custom format string that will properly print quantity of any unit.
     
    Here is a small preview of what is now available:
     
    using namespace mp_units::si::unit_symbols;\nusing namespace mp_units::international::unit_symbols;\nquantity q = (90. * km / h).in(mph);\n\nstd::cout << \"Number: \" << q.numerical_value_in(mph) << \"\\n\";\nstd::cout << \"Unit: \" << q.unit << \"\\n\";\nstd::cout << \"Dimension: \" << q.dimension << \"\\n\";\nstd::println(\"{::N[.2f]}\", q);\nstd::println(\"{:.4f} in {} of {}\", q.numerical_value_in(mph), q.unit, q.dimension);\nstd::println(\"{:%N in %U of %D:N[.4f]}\", q);\n
     
    Number: 55.9234\nUnit: mi/h\nDimension: LT\u207b\u00b9\n55.92 mi/h\n55.9234 in mi/h of LT\u207b\u00b9\n55.9234 in mi/h of LT\u207b\u00b9\n
     
    More on this subject can be found in the updated Text Output chapter.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#improved-casts","title":"Improved casts","text":"
    We added a new conversion function. value_cast<Unit, Representation> forces the conversion of both a unit and representation type in one step and always ensures that the best precision is provided.
     
    Also, we have finally added proper implementations of value_cast and quantity_cast for quantity points.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#even-better-error-messages","title":"Even better error messages","text":"
    This release made a few small refactorings that, without changing the user-facing API, allowed us to improve the readability of the generated types that can be observed in the compilation errors.
     
    Example 1 (clang):
     NowBefore 
    error: no matching function for call to 'time_to_goal'\n   26 |   const quantity ttg = time_to_goal(half_marathon_distance, pace);\n      |                        ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre>{}, double>,\n                                                                  speed:auto = quantity<derived_unit<second, per<kilo_<metre>>>{}, double>]\n   13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n      |                            ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre> > >{{{}}}>, isq::speed>' evaluated to false\n   14 |                                         QuantityOf<isq::speed> auto speed)\n      |                                         ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n   61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n      |                                     ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> > >{}, struct speed{{{}}})' evaluated to false\n  147 |   QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n      |                                                                         ^\n1 error generated.\nCompiler returned: 1\n
     
    error: no matching function for call to 'time_to_goal'\n   26 |   const quantity ttg = time_to_goal(half_marathon_distance, pace);\n      |                        ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre{{}}>{}, double>,\n                                                                  speed:auto = quantity<derived_unit<second, per<kilo_<metre{{}}>>>{}, double>]\n   13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n      |                            ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre{{}}> > >{{{}}}>, isq::speed>' evaluated to false\n   14 |                                         QuantityOf<isq::speed> auto speed)\n      |                                         ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre{{}}> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n   61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n      |                                     ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> >{{}, {{}}}>{}, struct speed{{{}}})' evaluated to false\n  147 |   QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n      |                                                                         ^\n1 error generated.\nCompiler returned: 1\n
     
    Example 2 (gcc):
     NowBefore 
    error: no matching function for call to 'Box::Box(quantity<reference<isq::height, si::metre>(), int>, quantity<reference<horizontal_length, si::metre>(), int>,\n                                                  quantity<reference<isq::width, si::metre>(), int>)'\n   27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n      |                                                                           ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length, si::metre>()>, quantity<reference<isq::width, si::metre>()>,\n                                          quantity<reference<isq::height, si::metre>()>)'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |   ^~~\nnote:   no known conversion for argument 1 from 'quantity<reference<isq::height, si::metre>(),int>'\n        to 'quantity<reference<horizontal_length, si::metre>(),double>'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\n
     
    error: no matching function for call to 'Box::Box(quantity<reference<isq::height(), si::metre()>(), int>, quantity<reference<horizontal_length(), si::metre()>(), int>,\n                                                  quantity<reference<isq::width(), si::metre()>(), int>)'\n   27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n      |                                                                           ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length(), si::metre()>()>, quantity<reference<isq::width(), si::metre()>()>,\n                                          quantity<reference<isq::height(), si::metre()>()>)'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |   ^~~\nnote:   no known conversion for argument 1 from 'quantity<reference<isq::height(), si::metre()>(),int>'\n        to 'quantity<reference<horizontal_length(), si::metre()>(),double>'\n   19 |   Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\n
    "},{"location":"blog/2024/06/14/mp-units-220-released/#mathh-header-changes","title":"math.h header changes","text":"
    This release provided lots of changes to the mp_units/math.h header file.
     
    First, we got several outstanding contributions:
     
       
    • fma, isfinite, isinf, and isnan math functions were added by @NAThompson,
      •  
    • ppm, atan2, fmod, and remainder were added by @nebkat.
      •  
     
    Thanks!
     
    Additionally, we changed the namespace for trigonometric functions using SI units. Now they are inside of the mp_units::si subnamespace and not in mp_units::isq like it was the case before ( breaking change ).
     
    Also, the header itself was split into smaller pieces that improve C++20 modules definitions.
    "},{"location":"blog/2024/06/14/mp-units-220-released/#ratio-made-an-implementation-detail-of-the-library","title":"ratio made an implementation detail of the library","text":"
    We decided not to expose ratio and associated interfaces in the public part of the library ( breaking change ). Standardization of it could be problematic as we have std::ratio already.
     
    Alternatively, as in the public interface it was always only used with mag, we introduced a new helper called mag_ratio to provide the magnitude of the unit defined in terms of a rational conversion factor. Here is a comparison of the code with previous and current definitions:
     NowBefore 
    inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\ninline constexpr struct foot final : named_unit<\"ft\", mag_ratio<1, 3> * yard> {} foot;\n
     
    inline constexpr struct yard : named_unit<\"yd\", mag<ratio{9'144, 10'000}> * si::metre> {} yard;\ninline constexpr struct foot : named_unit<\"ft\", mag<ratio{1, 3}> * yard> {} foot;\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/","title":"mp-units 2.3.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    This release fine-tunes many key features of the library. This post describes the most interesting improvements, while a much longer list of the changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#cmake-and-conan-options-changed","title":"CMake and Conan options changed","text":"
    During the review on the ConanCenter, we got feedback that we should improve the handling of options for which value is automatically determined based on the current configuration. Instead of explicitly setting the auto value, we defer the choice between True/False until the configuration stage and set it there once all the settings are known. auto value for such option was removed ( breaking change ).
     
    If you didn't set any value at the command line for such options, everything stays the same for you. However, some changes are needed if you explicitly used auto like below:
     
    conan install . -o 'mp-units:std_format=auto' -s compiler.cppstd=23 -b missing\n
     
    Now you have to either skip such an option to keep automatic deduction:
     
    conan install . -s compiler.cppstd=23 -b missing\n
     
    or set it explicitly to True or False to force a specific configuration:
     
    conan install . -o 'mp-units:std_format=True' -s compiler.cppstd=23 -b missing\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/#msvc-compiler-support","title":"MSVC compiler support","text":"
    The MSVC compiler has the most bugs in the C++20 support from all our compilers. However, with this release, we could apply many workarounds to the library's code to make it work. \ud83c\udf89
     
    Please note those workarounds were only applied to the library's code and not to our unit tests and examples. Trying to build the entire project on MSVC will inevitably fail to compile unless the MSVC bugs are resolved. MSVC developers still have some work to do.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#representation-type-template-parameter-added-to-value-conversion-functions","title":"Representation type template parameter added to value conversion functions","text":"
    Previously, changing a representation type was only possible with a value_cast<NewRep>(q) non-member function while a change of unit was supported by all value_cast<NewU>(q), q.in(NewU), and q.force_in(NewU). The rationale for it was that passing an explicit type to a member function template requires a template disambiguator when we are dealing with a dependent name (e.g., quantity type is determined based on a template parameter).
     
    During a discussion in LEWGI at the St. Louis WG21 Meeting, we decided to provide such additional overloads despite possible issues when a dependent name is used. In such case, a user needs to provide a template disambiguator or switch back to using value_cast:
     
    // non-dependent name\nauto f(quantity<m, int> q)             { return q.in<double>(km); }\nauto g(quantity<m, int> q)             { return value_cast<double, km>(q); }\n\n// dependent name\nauto h(QuantityOf<isq::length> auto q) { return q.template in<double>(km); }\nauto i(QuantityOf<isq::length> auto q) { return value_cast<double, km>(q); }\n
     
    The table below provides all the value conversion functions in mp-units that may be run on x being the instance of either quantity or quantity_point:
     Forcing Representation Unit Member function Non-member function No Same u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x) or value_cast<T, u>(x)"},{"location":"blog/2024/09/27/mp-units-230-released/#quantity-reference-specifiers","title":"Quantity reference specifiers","text":"
    The features described in this chapter directly solve an issue raised on std-proposals reflector. As it was reported, the code below may look correct, but it provides an invalid result:
     
    quantity Volume = 1.0 * m3;\nquantity Temperature = 28.0 * deg_C;\nquantity n_ = 0.04401 * kg / mol;\nquantity R_boltzman = 8.314 * N * m / (K * mol);\nquantity mass = 40.0 * kg;\nquantity Pressure = R_boltzman * Temperature.in(K) * mass / n_ / Volume;\nstd::cout << Pressure << \"\\n\";\n
     
    The problem is related to the accidental usage of a quantity rather than quantity_point for Temperature. This means that after conversion to kelvins, we will get 28 K instead of the expected 301.15 K, corrupting all further calculations.
     
    A correct code should use a quantity_point:
     
    quantity_point Temperature(28.0 * deg_C);\n
     
    This might be an obvious thing for domain experts, but new users of the library may not be aware of the affine space abstractions and how they influence temperature handling.
     
    After a lengthy discussion on handling such scenarios, we decided to:
     
       
    • make the above code deprecated ( breaking change ),
      •  
    • provide an alternative way to create a quantity with the delta quantity construction helper.
      •  
     
    Here are the main points of this new design:
     
       
    1. All references/units that specify point origin in their definition (i.e., si::kelvin, \u00a0 \u00a0si::degree_Celsius, and usc::degree_Fahrenheit) are excluded from the multiply syntax  ( breaking change ).
      2.  
    2.  
      A new delta quantity construction helper is introduced:
       
         
      • delta<m>(42) results with a quantity<si::metre, int>,
        •  
      • delta<deg_C>(5) results with a quantity<si::deg_C, int>.
        •  
       
      3.  
    3.  
      A new absolute quantity point construction helper is introduced:
       
         
      • absolute<m>(42) results with a quantity_point<si::metre, zeroth_point_origin<kind_of<isq::length>>{}, int>,
        •  
      • absolute<deg_C>(5) results with a quantity<si::metre, si::ice_point, int>.
        •  
       
      4.  
     
    Info
     
    Please note that si::kelvin is also excluded from the multiply syntax to prevent the following surprising issues:
     NowBefore 
    quantity q = delta<K>(300);\nquantity_point qp = absolute<K>(300);\nstatic_assert(q.in(deg_C) != qp.in(deg_C).quantity_from_zero());\n
     
    quantity q(300 * K);\nquantity_point qp(300 * K);\nstatic_assert(q.in(deg_C) != qp.in(deg_C).quantity_from_zero());\n
     
    We believe that the code enforced with new utilities makes it much easier to understand what happens here.
     
    With such changes to the interface design, the offending code will not compile as initially written. Users will be forced to think more about what they write. To enable the compilation, the users have to create explicitly:
     
       
    •  
      a quantity_point (the intended abstraction in this example) with any of the below syntaxes:
       
      quantity_point Temperature = absolute<deg_C>(28.0);\nauto Temperature = absolute<deg_C>(28.0);\nquantity_point Temperature(delta<deg_C>(28.0));\n
       
      •  
    •  
      a quantity (an incorrect abstraction in this example) with:
       
      quantity Temperature = delta<deg_C>(28.0);\nauto Temperature = delta<deg_C>(28.0);\n
       
      •  
     
    Thanks to the new design, we can immediately see what happens here and why the result might be incorrect in the second case.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#quantity_point_like_traits-are-based-on-numerical-value-instead-of-a-quantity","title":"quantity_point_like_traits are based on numerical value instead of a quantity","text":"
    In this release, we decided to fine-tune the traits that customize the conversion between custom quantity point types and the ones provided with mp-units ( breaking change ).
     
    Previously, such type traits were based on the quantity type. This was inconsistent with quantity_like_traits, that is working on raw values. Also, there are cases where a custom quantity point abstraction is not modelled with a quantity type. In such cases, the previous approach required additional types to be introduced for no good reason.
     NowBefore 
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<quantity<reference, rep>> to_quantity(Timestamp ts)\n  {\n    return ts.seconds * si::second;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_quantity(quantity<reference, rep> q)\n  {\n    return Timestamp(q.numerical_value_ref_in(si::second));\n  }\n};\n
     
    Note
     
    The old behavior is deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#magpi","title":"mag<pi>","text":"
    With this release, we introduced a new strongly-typed constant to create a magnitude involving scaling by pi. The solution used before was not consistent with magnitudes of integral values and also was leaking a floating-point value of std::numbers::pi_v<long double> to the resulting magnitude type. With the new approach, this is no longer the case, and the user-facing interface is more consistent:
     NowBefore 
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag<pi> / mag<180> * si::radian> {} degree;\n
     
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag_pi / mag<180> * si::radian> {} degree;\n
     
    Note
     
    The old mag_pi helper is marked as deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#common-units","title":"Common units","text":"
    Adding or subtracting two quantities of different units will force the library to find a common unit for those. This is to prevent data truncation. For the cases when one of the units is an integral multiple of the another, the resulting quantity will use a \"smaller\" one in its result. For example:
     
    static_assert((1 * kg + 1 * g).unit == g);\nstatic_assert((1 * km + 1 * mm).unit == mm);\nstatic_assert((1 * yd + 1 * mi).unit == yd);\n
     
    However, in many cases an arithmetic on quantities of different units will result in a yet another unit. This happens when none of the source units is an integral multiple of another. In such cases, the library returns a special type that denotes that we are dealing with a common unit of such an equation.
     
    Previously we returned a scaled unit calculated against our arbitrarily appointed reference unit. This resulted often in a long and messy type exposing the prime-factorized magnitude of the unit (implementation detail). In this release, we introduced a new common_unit wrapper for such cases:
     NowBefore 
    quantity q = 1 * km + 1 * mi;  // quantity<common_unit<international::mile, si::kilo_<si::metre>>{}, int>\n
     
    quantity q = 1 * km + 1 * mi;  // quantity<scaled_unit<magnitude<power_v<2, 3>{}, power_v<5, -3>{}>{}, si::metre>{}, int>\n
     
    Note
     
    A user should never explicitly instantiate a common_unit class template. The library's framework will do it based on the provided quantity equation.
     
    Such units need special printing rules for their symbols. As they represent a minimum set of common units resulting from the addition or subtraction of multiple quantities, from this release, we print all of them as a scaled version of the source unit. Previously we were printing them relative to some arbitrary reference unit (implementation detail) that often was not spelled by the user at all in the source code. For example the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\n
     
    will print:
     NowBefore 
    40771 ([1/25146] mi = [1/15625] km)\n108167 ([1/50292] mi = [1/57875] nmi)\n23 ([1/5] km/h = [1/18] m/s)\n
     
    40771 [8/125] m\n108167 [4/125] m\n23 [1/18] m/s\n
     
    Thanks to the above, it might be easier for the user to reason about the magnitude of the resulting unit and its impact on the value stored in the quantity.
     
    Info
     
    In order to provide common_unit strong type unit wrapper we had to rename all the common_XXX() functions to get_common_XXX() ( breaking change ).
    "},{"location":"blog/2024/09/27/mp-units-230-released/#superpowers-of-the-unit-one","title":"Superpowers of the unit one","text":"
    In this release, we also added a long-awaited change. From now on a quantity of a unit one can be:
     
       
    • implicitly constructed from the raw value,
      •  
    • explicitly converted to a raw value,
      •  
    • compared to a raw value.
      •  
     NowBefore 
    quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n  legacy(static_cast<int>(q));\n
     
    quantity<one> inc(quantity<one> q) { return q + 1 * one; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42 * one); q != 0 * one)\n  legacy(q.numerical_value_in(one));\n
     
    This property also expands to usual arithmetic operators.
     
    With the above change, we can now achieve the same results in a terser way:
     NowBefore 
    static_assert(10 * km / (5 * km) == 2);\nconst quantity gain = 1. / index;\n
     
    static_assert(10 * km / (5 * km) == 2 * one);\nconst quantity gain = 1. / index * one;\n
     
    Note
     
    Those rules do not apply to all the dimensionless quantities. It would be unsafe and misleading to allow such operations on units with a magnitude different than 1 (e.g., percent or radian).
    "},{"location":"blog/2024/09/27/mp-units-230-released/#import-std-support","title":"import std; support","text":"
    This release brings experimental support for import std;. The only compiler that supports it for now is clang-18+. Until all the compilers start to support it and CMake removes the experimental tag from this feature, we will also keep it experimental.
     
    As all of the C++ compilers are buggy for now, it is not allowed to bring the same definitions through the import std; and regular header files. This applies not only to the current project but also to all its dependencies. This is why, in order to use it with mp-units, we need to disable all the dependencies as well (enforced with conanfile.py). It means that we have to use std::format (instead of fmtlib) and remove functions contract checking.
     
    With the above assumptions, we can refactor our smoot example to:
     
    import mp_units;\nimport std;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n  constexpr quantity dist = 364.4 * smoot;\n  std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n               dist, dist.in(usc::foot), dist.in(si::metre));\n}\n
    "},{"location":"blog/2024/09/27/mp-units-230-released/#unit_can_be_prefixed-removed","title":"unit_can_be_prefixed removed","text":"
    Previously, the unit_can_be_prefixed type trait was used to limit the possibility to prefix some units that are officially known as non-prefixable (e.g., hour, minute).
     
    It turned out that it is not easy to determine whether some units can be prefixed. For example, for degree Celsius, the ISO 80000-5 standard explicitly states:
     
    Prefixes are not allowed in combination with the unit \u00b0C.
     
    On the other hand this NIST page says:
     
    Prefix symbols may be used with the unit symbol \u00baC and prefix names may be used with the unit name \u201cdegree Celsius.\u201d For example, 12 m\u00baC (12 millidegrees Celsius) is acceptable.
     
    It seems that it is also a common engineering practice.
     
    To prevent such issues, we decided to simplify the library's design and remove the unit_can_be_prefixed type trait ( breaking change ).
     
    From now on, every named unit in the library can be prefixed with the SI or IEC prefix.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#iec80000-system-renamed-to-iec","title":"iec80000 system renamed to iec","text":"
    As we mentioned IEC already, in this release, we decided to rename the name of the system and its corresponding namespace from iec80000 to iec ( breaking change ). This involves renaming of a defining header file and of the namespace it provides.
     
    With this change it should be easier to type the namespace name. This name is also more correct for some quantities and units that are introduced by IEC but not necessarily in the ISO/IEC 80000 series of documents (e.g., iec::var).
     
    Note
     
    The old iec80000 namespace in iec8000.h is marked as deprecated and will be removed in future releases.
    "},{"location":"blog/2024/09/27/mp-units-230-released/#error-messages-related-improvements","title":"Error messages-related improvements","text":"
    The readability of compile-time error messages is always a challenge for generic C++ libraries. However, for quantities and units library, generating readable errors is the most important requirement. If you do not make errors, you do not need such a library in your project .
     
    This is why we put lots of effort into improving here. Besides submitting compiler bugs to improve on their part, we also try to do our best here.
     
    Some compilers do not present the type resulting from calling a function within a template argument. This ends up with statements like get_quantity_spec(si::second{}) in the error message. Some less experienced users of the library may not know what this mean, and then why the conversion error happens.
     
    To improve this, we injected additional helper concepts into the definitions. It results with a bit longer but a more readable error in the end.
     
    For example:
     NowBefore 
    error: no matching member function for call to 'in'\n   15 | const quantity time_to_goal = (distance * speed).in(s);\n      |                               ~~~~~~~~~~~~~~~~~~~^~\nnote: candidate template ignored: constraints not satisfied [with ToU = struct second]\n  221 |   [[nodiscard]] constexpr QuantityOf<quantity_spec> auto in(ToU) const\n      |                                                          ^\nnote: because 'detail::UnitCompatibleWith<si::second, unit, quantity_spec>' evaluated to false\n  219 |   template<detail::UnitCompatibleWith<unit, quantity_spec> ToU>\n      |            ^\nnote: because '!AssociatedUnit<si::second>' evaluated to false\n  164 |   (!AssociatedUnit<U> || UnitOf<U, QS>) && detail::UnitConvertibleTo<FromU, U{}>;\n      |    ^\nnote: and 'UnitOf<si::second, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  164 |   (!AssociatedUnit<U> || UnitOf<U, QS>) && detail::UnitConvertibleTo<FromU, U{}>;\n      |                          ^\nnote: because 'detail::QuantitySpecConvertibleTo<get_quantity_spec(si::second{}), kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  141 |                  detail::QuantitySpecConvertibleTo<get_quantity_spec(U{}), QS> &&\n      |                  ^\nnote: because 'implicitly_convertible(kind_of_<struct time>{}, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{})' evaluated to false\n  151 |   implicitly_convertible(From, To);\n      |   ^\n1 error generated.\nCompiler returned: 1\n
     
    error: no matching member function for call to 'in'\n   15 | const quantity time_to_goal = (distance * speed).in(s);\n      |                               ~~~~~~~~~~~~~~~~~~~^~\nnote: candidate template ignored: constraints not satisfied [with U = struct second]\n  185 |   [[nodiscard]] constexpr QuantityOf<quantity_spec> auto in(U) const\n      |                                                          ^\nnote: because 'detail::UnitCompatibleWith<si::second, unit, quantity_spec>' evaluated to false\n  183 |   template<detail::UnitCompatibleWith<unit, quantity_spec> U>\n      |            ^\nnote: because '!AssociatedUnit<si::second>' evaluated to false\n  207 |   (!AssociatedUnit<U> || UnitOf<U, QS>)&&(detail::have_same_canonical_reference_unit(U{}, U2));\n      |    ^\nnote: and 'UnitOf<si::second, kind_of_<derived_quantity_spec<power<isq::length, 2>, per<isq::time> > >{}>' evaluated to false\n  207 |   (!AssociatedUnit<U> || UnitOf<U, QS>)&&(detail::have_same_canonical_reference_unit(U{}, U2));\n      |                          ^\nnote: because 'implicitly_convertible(get_quantity_spec(si::second{}), kind_of_<derived_quantity_spec<power<length, 2>, per<time> > >{})' evaluated to false\n  187 |   implicitly_convertible(get_quantity_spec(U{}), QS) &&\n      |   ^\n1 error generated.\nCompiler returned: 1\n
     
    Note
     
    The above error messages were stripped a bit of the additional information (file name, namespace name, nested curlies) to provide better readability.
    "},{"location":"blog/2024/11/05/mp-units-240-released/","title":"mp-units 2.4.0 released!","text":"
    A new product version can be obtained from GitHub and Conan.
     
    This release was unexpected. We planned a significant new feature to happen next, but while preparing for it, and also while writing API Reference documentation, we made so many vital fixes and improvements that we decided that they deserve a dedicated release first.
     
    This post describes the most significant improvements while a much longer list of the changes introduced by the new version can be found in our Release Notes.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#isq-quantities-cleanup","title":"ISQ quantities cleanup","text":"
    Initially, we kept quantities defined in \"IEC 80000-13: Information science and technology\" in a standalone iec80000 namespace, which was renamed to iec in the previous release. It turned out that this was incorrect. Those quantities are also a part of the ISQ. This is why, in this release, we moved all of them to the isq namespace ( breaking change ).
     
    From now on, iec namespace does not provide any quantities and serves purely as a system of units definition. It contains binary prefixes (based on the powers of two) and some units introduced by IEC (e.g., var, erlang, bit, or `baud).
     
    Note
     
    The quantities in iec namespace are now deprecated and will be removed in future releases.
     
    Also, it turns out that the latest ISO 80000-3 revision makes a small cleanup to the phase_speed and group_speed quantities. Those were always defined as scalar quantities but also had alternative names phase_velocity and group_velocity. This is misleading as velocity is typically considered a vector quantity. It is why those XXX_velocity aliases were removed from the ISO standard and from mp-units library ( breaking change ).
    "},{"location":"blog/2024/11/05/mp-units-240-released/#units-equality","title":"Units equality","text":"
    Previously we assumed that units like J, N m, and kg m\u00b2/s\u00b2 are equal. In some cases, this might not be entirely correct. Some quantities require a specific derived unit instead of a unit with a special name. For example:
     
       
    • N m should be used for moment of force (instead of J),
      •  
    • V A should be used for apparent power (instead of W).
      •  
     
    This is why, starting from this release units like J, N m, and kg m\u00b2/s\u00b2 will not compare equal ( breaking change ). However, they are deemed equivalent:
     
    static_assert(equivalent(J, N * m));\nstatic_assert(equivalent(W, V * A));\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#portable-text-output","title":"Portable text output","text":"
    From the very beginning, the text output of symbols could be formatted in two different ways:
     
       
    • Unicode,
      •  
    • portable using so-called ASCII alternatives.
      •  
     
    mp-units used the terms \"Unicode\" or \"ASCII\" and 'U' or 'A' formatting options for them. Even though those terms are widely understood in the C++ community, they are technically incorrect.
     
    During the recent SG16 meeting, we looked for proper alternatives and ended up with the \"portable\" and \"UTF-8\" terms ( breaking change ).
     
    From now on, we will provide the following:
     
       
    • text_encoding::utf8, symbol_text<N, M>::utf8(), and U formatting option,
      •  
    • text_encoding::portable, symbol_text<N, M>::portable(), and P formatting option.
      •  
     
    Note
     
    The old identifiers and formatting options are now deprecated and will be removed in future releases.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#char_traits-removed-from-fixed_string","title":"char_traits removed from fixed_string","text":"
    During the same SG16 meeting, the room was strongly against providing char_traits for fixed_string. This is why char_traits support was removed in this release ( breaking change ).
    "},{"location":"blog/2024/11/05/mp-units-240-released/#improved-units-text-output","title":"Improved units' text output","text":"
    In the previous release, we introduced common unit abstraction. Initially, all its components were printed in parenthesis which contained a list of all the scaled units separated with =. After some feedback, we decided to change it to a new syntax.
     
    For example, the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\n
     
    will print:
     NowBefore 
    40771 EQUIV{[1/25146 mi], [1/15625 km]}\n108167 EQUIV{[1/50292 mi], [1/57875 nmi]}\n23 EQUIV{[1/5 km/h], [1/18 m/s]}\n
     
    40771 ([1/25146] mi = [1/15625] km)\n108167 ([1/50292] mi = [1/57875] nmi)\n23 ([1/5] km/h = [1/18] m/s)\n
     
    As we can see above, the scaled units output changed as well. Now, the entire scaled unit is encapsulated within [...] brackets to better denote its scope.
     
    Additionally, small magnitudes of scaled units do not use the power of 10, and also scaled units do not have a composition priority over the derived units anymore.
     
    As a result of those changes, the following:
     
    constexpr Unit auto L_per_100km = L / (mag<100> * km);\nstd::cout << 6.7 * L_per_100km << \"\\n\";\n
     
    prints:
     NowBefore 
    6.7 L/[100 km]\n
     
    6.7 \u00d7 10\u207b\u00b2 l/km\n
     
    One more change that we can see above is that litre now use 'L' instead of 'l' for its symbol. The latter one too often is confused with the number 1.
     
    The next improvement adds proper formatting support for magnitudes. All of the formatting options that were working before for the unit symbols now also work for magnitudes.
     
    For example:
     
    using enum text_encoding;\nusing enum unit_symbol_solidus;\nusing usf = unit_symbol_formatting;\n\nstatic_assert(unit_symbol(mag<1> / (mag<2> * mag<pi>)*metre) == \"[2\u207b\u00b9 \ud835\udf0b\u207b\u00b9 m]\");\nstatic_assert(unit_symbol<usf{.solidus = always}>(mag<1> / (mag<2> * mag<pi>)*metre) == \"[1/(2 \ud835\udf0b) m]\");\nstatic_assert(unit_symbol<usf{.encoding = portable, .solidus = always}>(mag<1> / (mag<2> * mag<pi>)*metre) ==\n              \"[1/(2 pi) m]\");\n
     
    As we can see above, the library also learned how to print magnitude symbols. This required a change in the mag_constant definition. Now, it takes a magnitude symbol and has to be final like for other similar types in the library ( breaking change ):
     
    inline constexpr struct pi final : mag_constant<symbol_text{u8\"\u03c0\", \"pi\"}, std::numbers::pi_v<long double>> {} pi;\ninline constexpr auto \u03c0 = pi;\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#unicode-identifiers","title":"Unicode identifiers","text":"
    The example above introduced something interesting: a \u03c0 identifier for a variable. With the latest changes to the C++ language, we can officially use Unicode symbols as identifiers in the C++ code.
     
    In this release, we've added Unicode identifiers support not only for \u03c0 magnitude constant but also for unit symbols.
     
    Now we can type the following:
     With UTF-8 glyphsPortable 
    quantity resistance = 60 * k\u03a9;\nquantity capacitance = 100 * \u00b5F;\n
     
    quantity resistance = 60 * kohm;\nquantity capacitance = 100 * uF;\n
     
    This might make the source code easier to understand, but typing those identifiers can be tricky. Sometimes, the best solution to type it might be a copy-paste approach. If we do not like this idea, we can still use old portable identifiers for those as well.
    "},{"location":"blog/2024/11/05/mp-units-240-released/#convertibility-with-quantitylike-and-quantitypointlike-entities","title":"Convertibility with QuantityLike and QuantityPointLike entities","text":"
    In this release, we decided to fine-tune further the traits that customize the conversion between custom quantity and quantity point types and the ones provided with mp-units ( breaking change ).
     
    Previously, to_numerical_value and from_numerical_value returned a type wrapped in a special tag type describing the conversion type (explicit or implicit).
     
    This was a novel and experimental approach. Finally, we decided not to do it and used a bit more verbose but a more standard solution. From now on, we need to provide two additional static data members of type bool:
     
       
    • explicit_import - true means that the conversion to the mp-units abstraction is explicit,
      •  
    • explicit_export - true means that the conversion from the mp-units abstraction is   explicit.
      •  
     NowBefore 
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr rep to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr Timestamp from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  using rep = decltype(Timestamp::seconds);\n\n  static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts)\n  {\n    return ts.seconds;\n  }\n\n  static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v)\n  {\n    return Timestamp(v);\n  }\n};\n
    "},{"location":"blog/2024/11/05/mp-units-240-released/#symbolic-constants-implementation-should-be-implementation-defined","title":"Symbolic constants implementation should be implementation-defined","text":"
    In the process of writing API Reference, we decided to hide all the metadata associated with symbolic constants - tag types used to define units, dimensions, quantity specification, etc. ( breaking change ).
     
    All the types and values exposed by such types are needed only in the implementation details of the library. Users should not need them. Hiding those and making them implementation-defined gives other vendors the freedom to choose different ways to implement features of this library in their codebases.
     
    Important
     
    Based on Hyrum's Law some users may depend on this information already, and this release will break their code.
     
    If that is the case for you, we would love to hear about your use case and its rationale. It may mean that we should either:
     
       
    • extend the library's functionality to support your use case out of the box and keep those   members hidden,
      •  
    • restore public visibility of such members and enforce this in the API Reference so that all   the users of various library implementations may use them in the same way as you.
      •  
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/","title":"Bringing Quantity-Safety To The Next Level","text":"
    All quantities and units libraries need to be unit-safe. Most of the libraries on the market do this correctly. Some of them are also dimension-safe, which adds another level of protection for their users.
     
    mp-units is probably the only library on the market that additionally is quantity-safe. This gives a new quality and possibilities. I've described the major idea behind it, implementation details, and benefits to the users in the series of posts about the International System of Quantities.
     
    However, this is only the beginning. We've always planned more and worked on the extensions in our free time. In this post, I will describe:
     
       
    • What a quantity character is?
      •  
    • The importance of using proper representation types for the quantities.
      •  
    • The power of providing character-specific operations for the quantities.
      •  
    • Discuss implementation challenges and possible solutions.
      •  
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#quantity-characters","title":"Quantity characters","text":"
    A quantity character determines the properties and operations that can be performed on the numerical value of a quantity.
     
    Quantities defined by the ISQ may be of the following characters:
     
       
    • real scalar (e.g., time, width, speed, apparent power),
      •  
    • complex scalar (e.g., voltage phasor, complex power, impedance),
      •  
    • vector (e.g., displacement, velocity, force),
      •  
    • tensor (e.g., moment of inertia, stress, strain).
      •  
     
    From the beginning, mp-units V2 was meant to properly support quantities of various characters. By default, all quantity types are scalars, but we can set any other quantity character in a quantity_spec definition. For example:
     
    inline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\n
     
    Character of derived quantities is inherited from the quantity equation taking into account the operations and their ingredients. For example the below velocity quantity will automatically get a vector character without the need to explicitly state it in the definition:
     
    inline constexpr struct velocity final : quantity_spec<displacement / duration> {} velocity;\n
     
    Similarly, the below will yield a speed quantity of a scalar character:
     
    inline constexpr struct speed final : quantity_spec<magnitude(velocity)> {} speed;\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#representation-types","title":"Representation types","text":"
    mp-units V2 requires providing representation types compatible with a specific character set in its quantity_spec definition:
     
    template<Reference auto R, RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    For example, this allows us to check that vector representation type is used to construct a velocity quantity and to ensure that speed gets a scalar:
     
    quantity q = vector{1, 2, 3} * m / s;\nquantity velocity = isq::velocity(q);\n// quantity speed = isq::speed(q);     // Compile-time error\n
     
    Another example here may be a complex power quantity that should use a representation type modeling a complex number, but apparent power, active power, and reactive power should get scalars.
     
    As we can see above, in the case of q, we can use any representation type with a quantity kind that just specify a unit (simple quantities). However, we need to provide a compatible representation type when we want to use strongly-typed quantities and be quantity-safe.
     
    Such checks already prevent many simple but common errors of mixing similar quantities in a specific domain.
     
    Info
     
    It is a common engineering practice to use fundamental types for vector quantities when we know the direction of the vector. For example, in many cases, we use double to express velocity or acceleration. In such cases, negative values mean moving backward or decelerating. This is why we also decided to allow such use cases in the library. A scalar representation type that provides abs() member or non-member function or works with std::abs() is considered a one-dimensional vector type:
     
    quantity speed = isq::speed(60 * km / h);\nquantity velocity = isq::velocity(60 * km / h);\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#character-specific-operations","title":"Character-specific operations","text":"
    Checking the representation type is only the first step in bringing additional safety. The real power comes with implementing character-specific operations.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#current-state-of-the-art","title":"Current state of the art","text":"
    Most units libraries on the market (not only for C++) provide only regular arithmetic operations for scalars and don't constrain them for quantities of other characters. They also do not offer any character-specific operations.
     
    For example, let's look closer into vector quantities. Most of the libraries on the market will happily accept the following or similar code:
     
    auto force = get_force();\nauto length = get_length();\nauto work = force * length;\n
     
    They will also accept the following line:
     
    auto moment_of_force = force * length;\n
     
    Does it mean that moment of force and work are the same quantities? Of course not! It is just how naive most libraries are today.
     
    But first, to defend them, I must admit that the behavior above is partially OK. force * length could yield some specific quantity, but it is definitely not work or moment of force.
     
    There are two problems here:
     
       
    1. Libraries on the market are not aware of the characters of the quantities being used in the equation.    This means they can't prevent scalar arithmetic operations from being performed on vector quantities.    This typically leads to compile-time errors when a proper linear algebra representation type is    used in a quantity, as most linear algebra libraries will not overload operator* for vectors,    and those that do, treat it as a dot product, which returns a scalar.
      2.  
    2. None of the libraries allows us to constrain the return type of such multiplication with    a specific quantity type to specify exactly what we want to achieve. Most of them allow for replacing    auto with a type that describes just a unit, or, at best, the dimension. This means that all of    them are unit-safe, and some are also dimension-safe. However, this is not helpful here and does    not allow the library to do any additional compile-time checks on the resulting quantities.    The fact that we named the results as work or moment_of_force does not mean anything to    the compiler or the library being used.
      3.  
     
    This isn't good.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#benefits-of-quantity-safe-library","title":"Benefits of quantity-safe library","text":"
    As we've stated in the beginning, mp-units, besides being unit-safe and dimension-safe, is also quantity-safe. Let's see what it means.
     
    Note
     
    The features described below are planned for the next major release of the library and are not available on the master branch as of today.
     
    First, we repeat what other libraries did:
     
    quantity force = get_force();\nquantity length = get_length();\nquantity q1 = force * length;\n
     
    The code compiles as long as length is a scalar quantity with a scalar representation type. We can always multiply or divide a vector quantity (e.g., force) by a scalar one.
     
    However, things stop compiling when we want to convert the obtained result to a specific quantity type:
     
    // quantity moment_of_force = isq::moment_of_force(q1);  // Compile-time error\n// quantity work = isq::work(q1);                        // Compile-time error\n
     
    Neither moment of force nor work quantity can be created from a scalar length. We need very specific vector quantities of kind length to do that:
     
    quantity displacement = get_displacement();\nquantity position_vector = get_position_vector();\n
     
    Now, if we try to multiply the variables as before, we will end up with a compilation error:
     
    // quantity q2 = force * displacement;                   // Compile-time error\n// quantity q3 = force * position_vector;                // Compile-time error\n
     
    Multiplication on vectors is mathematically not defined. We have to use proper operations:
     
    quantity q2 = scalar_product(force, displacement);\nquantity q3 = scalar_product(force, position_vector);\nquantity q4 = vector_product(force, displacement);\nquantity q5 = vector_product(force, position_vector);\n
     
    All of the above compile and result in some quantities. After that, we can try to convert those results to our required quantities:
     
    quantity work = isq::work(q2).in[J];\n// quantity work = isq::work(q3);                        // Compile-time error\n// quantity work = isq::work(q4);                        // Compile-time error\n// quantity work = isq::work(q5);                        // Compile-time error\n
     
    Important
     
    It is essential to realize that just like multiplication and division are for scalars, vector and scalar products are for vectors. We never want to accept a quantity that accidentally was created with multiplication instead of division of its arguments or with the scalar product instead of a vector product, right?
     
    So we are done with work. Let's create a moment of force quantity as well. It might be surprising to many that none of the following code compiles:
     
    // quantity moment_of_force = isq::moment_of_force(q2);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q3);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q4);  // Compile-time error\n// quantity moment_of_force = isq::moment_of_force(q5);  // Compile-time error\n
     
    Do you know why it does not compile? Please try to think about it for a minute and figure out what is the problem before checking the answer below.
     !!! Spoiler alert !!! 
    Vector product is anti-commutative. Similarly to the division for scalars, for a vector product it is important to decide which quantity we put on the left and right-hand side of the operation.
     
    To make it compile, we need to reverse the arguments of a vector_product() operation:
     
    quantity q6 = vector_product(position_vector, force);\nquantity moment_of_force = isq::moment_of_force(q6);\n
     
    Do you start to see the need for such checks at compile-time already? 
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#explicit-conversions-are-not-really-needed","title":"Explicit conversions are not really needed","text":"
    You may be worried by the fact that we needed explicit quantity conversions above and that the code without them compiled fine. It might look like a safety pitfall, but it is really not an issue.
     
    The code above used a quantity CTAD placeholder which works a bit like auto. It accepts any quantity and deduced proper type for it. And all of the above operations resulted in some quantities, but often not the ones we were interested in.
     
    In the production code, we deal with strong types in many places (members in classes, function arguments and return types, etc.). In generic code, we should use concepts to constrain template parameters. This will be enough to guarantee quantity-safety.
     
    For example:
     
    void func1(quantity<isq::work[J]> w);\nvoid func2(QuantityOf<isq::moment_of_force> auto mof);\n\nfunc1(q2);\nfunc2(q6);\n// func1(q6);  // Compile-time error\n// func2(q2);  // Compile-time error\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#peeking-under-the-hood","title":"Peeking under the hood","text":"
    Let's look at the definitions of work and moment of force quantities to understand how and why the above works:
     
    inline constexpr struct work final : quantity_spec<scalar_product(force, displacement)> {} work;\ninline constexpr struct moment_of_force final : quantity_spec<vector_product(position_vector, force)> {} moment_of_force;\n
     
    scalar_product() and vector_product() functions are overloaded not only for quantity but also for quantity_spec types. The results of such operations are symbolic expressions that identify those operations. When used as a quantity recipe in a quantity_spec definition, they tell the library which derived quantities may be implicitly converted to our quantity.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#what-do-other-libraries-do","title":"What do other libraries do?","text":"
    I am probably not wrong in stating that none of the major C++ units libraries on the market provides vector or complex operations on quantities. This is why none of them will work when a proper representation type will be provided to a quantity. Trying to do any operations on a quantity with a linear algebra vector as its representation type will fail to compile.
     
    This is also mostly true for other programming languages. A great exception, and in fact the only library that I know which provides such operations, is Python's Pint (thanks to NumPy support).
     
    As other libraries do not support quantities of a vector type, they require users to create homogenous vectors of quantities and do all of the linear algebra operations with a 3rd party library. This approach can't be quantity-safe!
     
    In such scenarios, the units library can't detect if an external linear algebra library performs a scalar or vector product operation. It only observes the individual multiplications on scalar ingredients of an external vector type. This is actually why such multiplication operations are provided in other units libraries in the first place.
     
    Let's compare those approaches:
     Quantity-SafeAlso Quantity-SafeOther units libraries 
    quantity displacement_1 = isq::displacement(la::vector{1, 2, 3} * m);\nquantity displacement_2 = isq::displacement(la::vector{2, 1, 0} * m);\nquantity displacement = displacement_1 + displacement_2;\nquantity force = isq::force(la::vector{42, 42, 42} * N);\nquantity work = isq::work(scalar_product(force, displacement));\n
     
    quantity displacement_1 = la::vector{1, 2, 3} * m;\nquantity displacement_2 = la::vector{2, 1, 0} * m;\nquantity displacement = displacement_1 + displacement_2;\nquantity force = la::vector{42, 42, 42} * N;\nquantity<isq::work[J]> work = scalar_product(force, displacement);\n
     
    la::vector<quantity<si::metre>> displacement_1 = la::vector{1 * m, 2 * m, 3 * m};\nla::vector<quantity<si::metre>> displacement_2 = la::vector{2 * m, 1 * m, 0 * m};\nla::vector<quantity<si::metre>> displacement = displacement_1 + displacement_2;\nla::vector<quantity<si::newton>> force = la::vector{42 * N, 42 * N, 42 * N};\nquantity<si::joule> work = la::scalar_product(force, displacement);\n
     
    Of course, someone could argue that incorrect use of a vector product operation above would also be safe as it will not compile as the return type differs. Yes, it is true. However, please remember that there are more cases where errors may happen.
     
    For example, an external linear algebra library will not protect us from providing arguments to a vector product in an invalid order.
     
    Also, our work quantity will never be able to detect if what we are trying to assign to it is a result of a scalar product of two vector quantities of displacement and force, or maybe just some naive multiplication of scalar quantities that accidentally matched the dimensionality of the expected result.
     
    Please also remember that the quantity characters are not only about linear algebra. For example, in the case of complex quantities, we want to ensure that only:
     
       
    • the real part of a complex power is assigned to an active power,
      •  
    • the imaginary part of a complex power is assigned to an reactive power,
      •  
    • the modulus of a complex power is assigned to an apparent power.
      •  
     
    Mixing the above is a fatal error in power systems engineering.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#implementation-challenges","title":"Implementation challenges","text":"
    I had planned to implement the above features for a few years now but never had enough time to do it. Now, I am close to finishing the work. However, I've discovered a few interesting issues on the way, and I have to solve them before putting my code on the mainline and releasing the next mp-units version.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#modeling-magnitudes","title":"Modeling magnitudes","text":"
    Let's dig in a bit more into proper modelling of position vector and displacement quantities. First, we have to think to which scalar quantities their magnitude should convert to:
     
       
    • a magnitude of a position vector is equivalent to a radial distance quantity,
      •  
    • a magnitude of a displacement is a special case of a distance quantity.
      •  
     
    Taking the above into account, we should refactor our tree of quantities of kind length into the following:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- displacement[\"<b>displacement</b><br>{vector}\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    radial_distance --- position_vector[\"<b>position_vector</b><br>{vector}\"]\n    length --- wavelength[\"<b>wavelength</b>\"]
     
    Having the above, we can look a bit closer into how velocity and speed are defined in the ISQ:
     
    ISO 80000-3: Space and time
     
    velocity - vector quantity giving the rate of change of a position vector.
     
    speed - magnitude of the velocity.
     
    Change of a position vector is nothing else than a displacement. This means that velocity and speed can be defined as follows:
     
    inline constexpr struct velocity final : quantity_spec<displacement / duration> {} velocity;\ninline constexpr struct speed final : quantity_spec<magnitude(velocity)> {} speed;\n
     
    This is compatible with the ISQ definitions. However, we should check what it means from the engineering point of view. Let's assume that we want to calculate speed directly from a distance traveled and duration, without using any vector quantities like displacement or velocity:
     
    quantity<isq::distance[m]> distance = 42 * m;\nquantity<isq::duration[s]> duration = 2 * s;\n// quantity<isq::speed[m / s]> speed = distance / duration;  // Compile-time error\n
     
    The above does not compile because distance quantity is not implicitly convertible to magnitude(displacement). This is the same case as stating that not every length is a distance. We need to cast here explicitly. To fix it, we can do any of the below:
     
    quantity<isq::speed[m / s]> speed1 = isq::speed(distance / duration);\nquantity<isq::speed[m / s]> speed2 = magnitude(isq::displacement)(distance) / duration;\n
     
    Also, the following will work:
     
    quantity length_kind = 42 * m;\nquantity<isq::speed[m / s]> speed3 = length_kind / duration;\n
     
    If we do not specify a specific quantity type and just use an SI unit, then we deal with the kind of quantity. Such quantity can behave like any quantity from the hierarchy tree with the same character, so it is also the same as magnitude(isq::displacement).
     
    Question
     
    Is it good enough from the engineering and usability point of views? If you would like to share your thoughts, please provide your comments below the article.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#more-about-displacement-and-position-vector","title":"More about displacement and position vector","text":"
    As we've stated above, a change of position vector is a displacement. Let's try to calculate it here:
     
    quantity pos1 = isq::position_vector(vector{1, 2} * m);\nquantity pos2 = isq::position_vector(vector{2, 3} * m);\nquantity q7 = pos2 - pos1;\n// quantity<isq::displacement[m], vector> displacement = q7;  // Compile-time error\n// quantity displacement = isq::displacement(q7);             // Compile-time error\nquantity displacement = quantity_cast<isq::displacement>(q7);\n
     
    Again, the above might be surprising and considered a usability issue. Let me describe why the code behaves like that.
     
    As of today, the result of an addition or subtraction of two quantities is their common quantity type. When subtracting two position vectors we end up with a position vector. Looking at the above hierarchy tree, we can easily see that position vector and displacement are on different branches. This prevents implicit and explicit conversions between those. The only one allowed to force such a conversion is an explicit cast.
     
    If we think more about it, this makes a lot of sense. Position vector is not a special case of displacement or vice versa. Those should not be convertible. We do not want the code to compile when we accidentally pass a position vector to the numerator of the equation for velocity, right? What does calculating the velocity for a position vector mean?
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#affine-spaces-within-quantity-trees","title":"Affine spaces within quantity trees","text":"
    Also, let's look at the type of variable q7. We know that subtracting two quantities of the same type results in a quantity of the same type. This is also the case when we do it for position vectors. We will see the same resulting type when we add two position vectors as well. But wait... What does it actually mean to add two position vectors?
     
    Looks familiar? Yes, we can clearly see that we are dealing with yet another case of the affine space. This time, it is hidden within the quantities hierarchy tree. This also means that adding a position vector and a displacement should result in a position vector. Let's try to do it:
     
    quantity q8 = pos1 + displacement;                       // Often a compile-time error\n
     
    Unfortunately, this often fails on the very first step, even before assigning the result to the position vector quantity. The reason for this is that in the hierarchy tree, the first common node for position vector and displacement is distance, which is a scalar quantity. Trying to use a vector representation type for a scalar quantity yields an error as a result of already existing checks described in the Representation types chapter.
     
    However, the code will compile if we use the same representation type for scalar and vector quantity (e.g., int or double may be used as a vector representation type for a well-known axis). In this case, we will end up with:
     
    // quantity<isq::position_vector[m], vector> pos3 = q8;       // Compile-time error\nquantity<isq::position_vector[m], vector> pos3 = isq::position_vector(q8);\n
     
    We need to convert a distance explicitly to a position vector quantity to move \"down\" over a branch in a hierarchy tree.
     
    It is important to note that there are more quantities that may behave the same. For example, altitude/height and time/duration may also form similar affine spaces. More similar examples can be found in other hierarchy trees.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#extending-arithmetic-on-quantity-specifications","title":"Extending arithmetic on quantity specifications","text":"
    mp-units provided support for multiplication and division of quantity_spec from the beginning. It was needed to obtain derived quantities. Adding support for quantity characters also added special operations (e.g., magnitude(), scalar_product(), etc.) on quantity_spec arguments. If we want to support such affine space abstractions, we must also add support for addition and subtraction, which may yield different results.
     
    For example:
     
    static_assert(isq::length + isq::length == isq::length);\nstatic_assert(isq::height + isq::width == isq::length);\nstatic_assert(isq::altitude + isq::height == isq::altitude);\nstatic_assert(isq::height + isq::altitude == isq::altitude);\n\nstatic_assert(isq::length - isq::length == isq::length);\nstatic_assert(isq::height - isq::width == isq::length);\nstatic_assert(isq::altitude - isq::height == isq::altitude);\nstatic_assert(isq::altitude - isq::altitude == isq::height);\n
     
    Also, some operations should not compile. For example:
     
    // auto qs1 = isq::altitude + isq::altitude;  // Compile-time error\n// auto qs2 = isq::height - isq::altitude;    // Compile-time error\n
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#defining-affine-space-abstractions-in-a-quantity_spec","title":"Defining affine space abstractions in a quantity_spec","text":"
    We can add support for the above by adding point_for<QuantitySpec> attribute to the quantity_spec definition:
     
    inline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct altitude final : quantity_spec<length, point_for<height>> {} altitude;\ninline constexpr struct displacement final : quantity_spec<distance, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<radial_distance, point_for<displacement>, quantity_character::vector> {} position_vector;\n
     
    Thanks to the above, the library always knows a \"delta\" quantity for a \"point\" type. I've implemented this logic, got great results, and thought I was done. But next, I realized that I need to update a few more things.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#adding-support-to-quantity_point","title":"Adding support to quantity_point","text":"
    quantity_point is intended to model \"point\" quantities and return \"delta\" quantities on subtraction or by calling .quantity_from...() family of member functions. This is possible and can be done. I've finished most of the implementation already. However, two interesting questions arise:
     
       
    1. Should isq::altitude be reserved only for quantity_point and not available for    \"regular\"\u00a0quantity types?
      2.  
    2. Should isq::height apply only to quantity?
      3.  
     
    I think that question #1 makes a lot of sense. If we realize that quantity always represents \"delta\" quantities, what would a quantity of isq::altitude mean? However, forcing the usage of quantity_point might be too strict here. Some users are not familiar or comfortable with this abstraction. Also, we can't multiply or divide quantity points.
     
    Question
     
    Does anyone know a derived quantity built with altitude or time instant? If so, please let me know in the comments, as limiting \"point\" quantity_spec to quantity_point would prevent forming such derived quantities.
     
    Question #2 is also interesting. However, in this case, I think that the answer should be \"NO\". I can imagine a series of height measurements. Every physical measurement can be modeled as a quantity_point, so a quantity_point of height might make sense.
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#opening-can-of-worms","title":"Opening can of worms","text":"
    So far, so good. I thought I was done here and could continue my work on symbolic expressions for vector and complex quantities. However, I've realized that I've opened a can of worms. What about the convertibility of quantity_spec? How should common_quantity_spec() behave?
     
    Let's start with conversions. It might seem easy. isq::altitude and isq::height should not be convertible to each other. But more questions arise:
     
       
    1. Should it be possible to quantity_cast from isq::altitude to isq::height or vice versa?
      2.  
    2. Should isq::height be convertible to isq::length?
      3.  
    3. Should isq::length be explicitly convertible to isq::height?
      4.  
    4. Should isq::altitude be convertible to isq::length?
      5.  
    5. Should isq::length be explicitly convertible to isq::altitude?
      6.  
     
    The need for #1 will always probably mean an error in program logic, so quantity_cast could not work for such entities. This would be an exception to our conversion rules that always allow casting between branches of one tree.
     
    The answer to questions #2 and #3 is \"YES\".
     
    We might be tempted to say \"NO\" to questions #4 and #5 as isq::altitude is defined as \"point\" while isq::length is not specified as such. However, I've just realized that it is not the case.
     
    The proper answer to questions #4 and #5 is \"It depends\". If we are dealing with a quantity_point then converting from isq::altitude to isq::length or the other way around should work. However, it would probably be a bad idea for a quantity type.
     
    It turns out that common_quantity_spec() is similar. It is probably safe to state that it should not compile for isq::altitude and isq::height arguments. This means that we will not be able to compare such quantities as well. As those are different abstractions, preventing that might be an excellent idea.
     
    Again, it gets tricky if we consider passing isq::length and isq::altitude to it. For quantity_point it probably should work fine and fail to compile for quantity.
     
    The above means that to determine the conversion rules and common quantity specifications, we need to know the context in which the quantity_spec is being used. This sucks!
    "},{"location":"blog/2025/01/15/bringing-quantity-safety-to-the-next-level/#should-we-get-rid-of-a-quantity_point","title":"Should we get rid of a quantity_point?","text":"
    There are at least two ways of solving the above issue. In any case, we need to introduce a wrapper over the quantity_spec to denote it is being used in a \"point\" abstraction.
     
    A simpler solution could be implicitly amending the Reference provided to the quantity_point class template with point<...>. So, for example, we would have the following members in quantity_point<isq::altitude[m]>:
     
       
    • qp::quantity_spec == point<isq::altitude>,
      •  
    • qp::reference of a type reference<point<isq::altitude>, si::metre>.
      •  
     
    This should work but might be a bit confusing as members of the class template would not exactly contain the types of template parameters.
     
    A better solution might be removing a dedicated quantity_point abstraction and providing both functionalities through the quantity class template. I still haven't figured out the best syntax. Please let me know if you have good ideas in the comments below. Here are some rough ideas:
     Before After quantity_spec quantity<si::metre> quantity<si::metre> kind_of<isq::length> quantity_point<si::metre> quantity<point<si::metre>> point<kind_of<isq::length>> quantity_point<si::metre, mean_sea_level> quantity<point<si::metre, mean_sea_level>> point<kind_of<isq::length>> quantity<isq::height[m]> quantity<isq::height[m]> isq::height quantity_point<isq::height[m]> quantity<point<isq::height[m]>> point<isq::height> quantity_point<isq::altitude[m]> quantity<point<isq::altitude[m]>> point<isq::altitude> quantity_point<isq::altitude[m], mean_sea_level> quantity<point<isq::altitude[m], mean_sea_level>> point<isq::altitude> 
    I am still undecided about whether we should pursue this option, which would involve a huge design change in the library. It may even require bumping the library major version to V3.
     
    On the bright side, it would limit the number of abstractions in the library. It would also make the library more consistent with standards like ISO/IEC 80000, which talk about quantities and do not mention quantity points at all. This could also be useful before we start our work on the next big task - logarithmic quantities and units.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/","title":"Introducing absolute quantities","text":"
    This post introduces a new abstraction called an absolute quantity. It complements affine space abstractions (point and delta) and will most probably be a new default in the library when we release V3.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#affine-space-in-a-nutshell","title":"Affine space in a nutshell","text":"
    So far mp-units and other quantities and units libraries have been modeling two kinds of abstractions:
     
       
    1.  
      Points (modeled with quantity_point class template)
       
         
      • can be interpolated,
        •  
      • can be subtracted,
        •  
      • can't be added,
        •  
      • can't be multiplied or divided by another quantity or scalar,
        •  
      • some of them could be specified as non-negative,
        •  
      • specified relative to some absolute or relative point origin,
        •  
      • conversion to offset units (e.g., degree Celsius) accounts for offset.
        •  
       
      2.  
    2.  
      Deltas (modeled with quantity class template)
       
         
      • can be interpolated,
        •  
      • can be subtracted,
        •  
      • can be added,
        •  
      • can be multiplied and divided by another quantity and scalar,
        •  
      • may be negative as there is always a chance that we will subtract a larger value   from a smaller one,
        •  
      • don't use point origins in its definition,
        •  
      • conversion to offset units (e.g., degree Celsius) ignores the offset (just the conversion   factor is used).
        •  
       
      3.  
     
    Info
     
    More information on this subject can be found in the Affine Space chapter.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#issues","title":"Issues","text":"
    A current affine space implementation works well for many essential use cases. However, it also produces some issues.
     
       
    1. We can't print quantity points as, at least for today, we do not have the means to properly    describe the user-provided origin in the text output.
      2.  
    2. Quantity points are hard to use in physical equations to denote not-delta values.
      3.  
     
    To make both of the above work, a user needs to convert the quantity point to quantity with either qp.quantity_from_zero() or qp.quantity_from(some_origin) member functions.
     
    quantity_point m1(2 * kg);\nquantity_point m2(3 * kg);\nquantity_point m = m1 + m2.quantity_from_zero();\nquantity d_v = 30 * km / h;\nquantity E_k = m.quantity_from_zero() * pow<2>(d_v) / 2;\n\nstd::cout << \"Mass: \" << m.quantity_from_zero() << \"\\n\";\nstd::cout << \"Velocity: \" << d_v << \"\\n\";\nstd::cout << \"Kinetic energy: \" << E_k.in<double>(J) << \"\\n\";\n
     
    This is quite inconvenient and is a common reason for avoiding quantity point abstraction in many equations in source code where it would be a good fit otherwise.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#absolute-quantities","title":"Absolute quantities","text":"
    Despite the above drawbacks, affine space points are necessary to model some abstractions (e.g., temperatures in degrees Celsius, tared mass measurements, altitudes above some reference point, etc.) and do it really well. Constrained affine space arithmetic (e.g., preventing accidental addition of points) also improves the safety of our programs. This is why it is a valuable abstraction and should be used more even often than now.
     
    To improve the user experience and open the doors for new features in the future, we are considering adding a third abstraction for absolute quantities. In terms of properties, an absolute quantity will lie between points and deltas.
     Feature Point Absolute Delta Interpolation Subtraction Addition Multiply/Divide May be non-negative Relative to origin Absolute & relative Measured against nothing/void Can use offset units Conversion to offset units With offset No offset Text output 
    As we can see above, absolute quantities have only two limitations, and both are connected to the offset units' usage. They can't use those because they must remain absolute instead of being measured relative to some custom origin.
     
    Absolute quantities could be considered delta quantities that represent a whole -- the entire entity being measured. This is why we can represent a system mass by adding absolute masses of all system elements or a system energy by adding absolute temperatures of all the system elements.
     
    As those are more related to deltas than points, it is impossible to specify their origin points. This also allows us to print them, as we do not need any special text to describe their origin as they are always measured against nothing/void.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#interfaces-refactoring","title":"Interfaces refactoring","text":"
    As I mentioned in my previous post, we are seriously considering removing quantity_point class template and replacing it with a quantity_spec point wrapper. For example, quantity_point<isq::altitude[m]> will become quantity<point<isq::altitude[m]>>.
     
    I initially planned quantity<isq::mass> to be the same as quantity<delta<isq::mass>>, but it turns out that deltas probably should not be the default. It is consistent with how we write physical expressions on paper, right? Delta symbol (\u2206) is always \"verbose\" in physical equations, it would be nice for the C++ code to do the same. So, deltas will always need to be explicit.
     
    And this brings us to absolute quantities. They should actually be the default we are looking for. This is what we write as quantities in most of the physical equations. This is why we will not need any specifier to denote them.
     
    For example:
     
    inline constexpr struct tare final : relative_point_origin<quantity_point{2 * kg}> {} tare;\n\nquantity<point<isq::mass>>       m1(10 * kg);         // point quantity with an implicit point origin\nquantity<point<isq::mass, tare>> m2 = tare + 8 * kg;  // point quantity with an explicit relative point origin\nquantity<isq::mass> \u00a0 \u00a0 \u00a0 \u00a0      m3 = 15 * kg;        // absolute quantity (e.g., non-negative)\nquantity<delta<isq::mass>>       m13 = m1 - m3;       // delta quantity (e.g., may be negative)\nquantity<delta<isq::mass>>       m23 = m2 - m3;       // delta quantity (e.g., may be negative)\n
     
    With the above, the initial example may be refactored to:
     
    quantity m1 = 2 * kg;\nquantity m2 = 3 * kg;\nquantity m = m1 + m2;\nquantity d_v = delta<km / h>(30);\nquantity E_k = m * pow<2>(d_v) / 2;\n\nstd::cout << \"Mass: \" << m << \"\\n\";\nstd::cout << \"Velocity: \" << d_v << \"\\n\";\nstd::cout << \"Kinetic energy: \" << E_k.in<double>(J) << \"\\n\";\n
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#arithmetic","title":"Arithmetic","text":"
    Affine space arithmetic is well-defined. However, we are adding a new type to the library that lands between points and deltas. This is why we must agree on the arithmetic for all possible combinations.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#addition","title":"Addition","text":"
    Absolute quantities are deltas against nothing so adding them to a point yields another point.
     
    Adding a delta to them yields a delta, as a delta may represent only a part of something and a whole, and a part is not a whole. The delta may also be negative and greater than the absolute quantity, which may yield a negative value. This is why delta is a good result here.
     
    Only adding whole non-negative entities of the system yields a system being expressed as an entire non-negative entity. This is why adding absolute quantities results in an absolute quantity.
     Lhs \\ Rhs Point Absolute Delta Point Point Point Absolute Point Absolute Delta Delta Point Delta Delta"},{"location":"blog/2025/06/16/introducing-absolute-quantities/#subtraction","title":"Subtraction","text":"
    Similarly, during subtraction, regular affine space arithmetics for deltas apply. Subtracting an absolute quantity from a point yields a point, and trying to do the opposite does not make physical sense.
     
    Subtracting two non-negative absolute quantities may yield a negative value if we subtract a larger one from the smaller one, so the result should be a delta. A similar result may be obtained by subtracting a delta from absolute quantity or absolute quantity from a delta.
     Lhs \\ Rhs Point Absolute Delta Point Delta Point Point Absolute Delta Delta Delta Delta Delta 
    Info
     
    Based on the above assumptions, one of the lines of the below code can't compile:
     
    quantity temp1 = 270 * K;\nquantity temp2 = point<K>(300); \nquantity temp3 = temp2 - temp1;             // Point\n// quantity temp4 = temp1 - temp2;          // Compile-time error\nquantity temp5 = temp1 - temp2.absolute();  // Delta\n
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#motivating-example","title":"Motivating example","text":"
    Let's consider a room with a table and two glasses filled with fluid on top of it. Let's also assume that we want to stack one on top of the other and treat them as a system we observe.
     
     
    // absolute quantities\nquantity<isq::height[cm]> glass1_height = 20 * cm;\nquantity<isq::height[cm]> glass2_height = 15 * cm;\n\n// delta quantities\nquantity<delta<isq::height>[cm]> fluid_level = 16 * cm;\n\n// point quantities\ninline constexpr struct floor_level final : absolute_point_origin<isq::height> floor_level;\nquantity<point<isq::height[cm], floor_level>> table_top = floor_level + 1 * m;\n// quantity<point<isq::height[cm]>> glass1_top(glass1_height); // point against nothing (no length)\n\n// absolute results\nquantity system_height = glass1_height + glass2_height;\n\n// delta results\nquantity empty_height_res = glass1_height - fluid_level;\nquantity glass2_height_res = system_height - glass1_height;    // could result in an absolute quantity\nassert(glass2_height_res == glass2_height);\nquantity height_diff_res = glass2_height - glass1_height;      // but this one should definitely return delta\n\n// point results\nquantity<point<isq::height[cm], floor_level>> glass1_top = table_top + glass1_height;\nquantity point1 = glass1_top - glass1_height;\nassert(point1 == table_top);\n// quantity point2 = glass1_height - glass1_top; \u00a0 \u00a0          \u00a0// no sense - does not compile\n
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#new-opportunities","title":"New opportunities","text":"
    The new syntax simplifies API as one quantity class template will now serve all quantity variations (possibly even more in the future). It also allows us to model quantities that were impossible to express before without some workarounds.
     
    For example, we can now correctly calculate Carnot engine efficiency with any of the following:
     
    quantity temp_cold = 300. * K;\nquantity temp_hot = 500. * K;\nquantity carnot_eff_1 = 1. - temp_cold / temp_hot;\nquantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot;\n
     
    In the above code, we can easily create absolute or delta values of temperatures and do arithmetics on them. Previously, we had to create deltas from both points artificially with:
     
    quantity temp_cold = point<K>(300.);\nquantity temp_hot = point<K>(500.);\nquantity carnot_eff_1 = 1. - temp_cold.quantity_from_zero() / temp_hot.quantity_from_zero();\nquantity carnot_eff_2 = (temp_hot - temp_cold) / temp_hot.quantity_from_zero();\n
     
    It worked but was far from being physically pure and pretty.
    "},{"location":"blog/2025/06/16/introducing-absolute-quantities/#summary","title":"Summary","text":"
    We believe that adding absolute quantities will be a significant improvement in the library that will allow us to model physical equations in a terser, more correct, easier to write, understand, and maintain way.
     
    We plan to deliver the features mentioned in this post as a part of mp-units V3.
     
    Please share your feedback.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/","title":"International System of Quantities (ISQ): Part 1 - Introduction","text":"
    This post starts a series of articles about the International System of Quantities (ISQ). In this series, we will describe:
     
       
    • What is ISQ?
      •  
    • Which engineering problems does ISQ help to solve and how?
      •  
    • How to model and implement it in the programming language?
      •  
    • What is missing in the ISQ, and why is that a problem?
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#terms-and-definitions","title":"Terms and Definitions","text":"
    From our experience, many people, including experts in the domain, often tend to name things differently, or sometimes they use the same term while having a different meaning in mind. This is why it is essential to stick to one well-defined glossary of terms for metrology.
     
    The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM:
     
       
    • International Organization for Standardization (ISO),
      •  
    • International Bureau of Weights and Measures (BIPM).
      •  
     
    The above are identical and contain the same set of definitions. We provide both to point out that the biggest institutions in standardizing metrology agree on the same vocabulary.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#systems-of-quantities-vs-systems-of-units","title":"Systems of Quantities vs Systems of Units","text":"
    Here are the official definitions from our vocabulary:
     
    System of quantities
     
    A system of quantities is a set of quantities together with a set of noncontradictory equations relating those quantities.
     
    System of units
     
    A system of units is a set of base units and derived units, together with their multiples and submultiples, defined in accordance with given rules, for a given system of quantities.
     
    From the definition above, we can find out that the systems of quantities and units form a hierarchy:
     
    flowchart TD\n    system_of_quantities[\"System of Quantities\"]\n    system_of_quantities --- system_of_units1[System of Units #1]\n    system_of_quantities --- system_of_units2[System of Units #2]\n    system_of_quantities --- system_of_units3[System of Units #3]
     
    System of quantities defines quantities commonly used in engineering (e.g., length, time, mass, speed, energy, power, etc.) and relations between them. It does not assign any specific units to those quantities, though.
     
    Systems of units are the ones that assign units of measurement to quantities from a specific system of quantities they chose to model. Different systems of units are free to chose whatever they find suitable for specific quantities and do not have to be consistent/compatible with other such systems. For example:
     
       
    • SI decided to measure length in meters, mass in kilograms, and time in seconds,
      •  
    • CGS decided to measure length in centimeters, mass in grams, and time in seconds.
      •  
     
    Both systems of units above agree on the unit of time, but chose different units for other quantities. In the above example, SI chose a non-prefixed unit of metre for a base quantity of length while CGS chose a scaled centimetre. On the other hand, SI chose a scaled kilogram over the gram used in the CGS. Those decisions also result in a need for different coherent units for derived quantities. For example:
     Quantity SI CGS length metre (m) centimetre (cm) mass kilogram (kg) gram (g) time second (s) second (s) force newton (N) dyne energy joule (J) erg pressure pascal (Pa) barye 
    Often, there is no way to state which one is correct or which one is wrong. Each system of units has the freedom to choose whichever unit suits its engineering requirements and constraints the best for a specific quantity.
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#isq-vs-si","title":"ISQ vs SI","text":"
    Some of the systems of quantities and units have been used more over the years and have become more popular than others. Here are the official descriptions of the most popular systems used in engineering today:
     
    International System of Quantities (ISQ)
     
    The International System of Quantities (ISQ) is a system of quantities based on the seven base quantities: length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity.
     
    International System of Units (SI)
     
    The International System of Units (SI) is a system of units, based on the International System of Quantities, their names and symbols, including a series of prefixes and their names and symbols, together with rules for their use, adopted by the General Conference on Weights and Measures (CGPM).
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#the-international-system-of-quantities-isq-standardization","title":"The International System of Quantities (ISQ) standardization","text":"
    The set of quantities constituting the ISQ is defined in the series of ISO 80000 and IEC 80000 standards under the general title \"Quantities and units\".
     
    ISO 80000:
     
       
    • Part 1: General
      •  
    • Part 2: Mathematical signs and symbols to be used in the natural sciences and technology
      •  
    • Part 3: Space and time
      •  
    • Part 4: Mechanics
      •  
    • Part 5: Thermodynamics
      •  
    • Part 7: Light
      •  
    • Part 8: Acoustics
      •  
    • Part 9: Physical chemistry and molecular physics
      •  
    • Part 10: Atomic and nuclear physics
      •  
    • Part 11: Characteristic numbers
      •  
    • Part 12: Condensed matter physics
      •  
     
    IEC 80000:
     
       
    • Part 6: Electromagnetism
      •  
    • Part 13: Information science and technology
      •  
    • Part 15: Logarithmic and related quantities, and their units
      •  
    • Part 16: Printing and writing rules
      •  
    • Part 17: Time dependency
      •  
    "},{"location":"blog/2024/10/07/international-system-of-quantities-isq-part-1---introduction/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will describe typical issues with libraries that do not model systems of quantities.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/","title":"International System of Quantities (ISQ): Part 2 - Problems when ISQ is not used","text":"
    This article is the next one in our series about the ISQ. After introducing the basic terms and systems, this article will talk about the issues we face when we base the quantities and units library on just units or dimensions.
     
    Note
     
    The issues described in this article do not apply to the mp-units library. Its interfaces, even if when we decide only to use simple quantities that only use units, those are still backed up by quantity kinds under the framework's hood.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#limitations-of-units-only-solutions","title":"Limitations of units-only solutions","text":"
    Units-only is not a good design for a quantities and units library. It works to some extent, but plenty of use cases can't be addressed, and for those that somehow work, we miss important safety improvements provided by additional abstractions in this article series.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#no-way-to-specify-a-quantity-type-in-generic-interfaces","title":"No way to specify a quantity type in generic interfaces","text":"
    A common requirement in the domain is to write unit-agnostic generic interfaces. For example, let's try to implement a generic avg_speed function template that takes a quantity of any unit and produces the result. If we call it with distance in km and time in h, we will get km/h as a result, but if we call it with mi and h, we expect mi/h to be returned.
     
    template<Unit auto U1, typename Rep1, Unit auto U2, typename Rep2>\nauto avg_speed(quantity<U1, Rep1> distance, quantity<U2, Rep2> time)\n{\n  return distance / time;\n}\n\nquantity speed = avg_speed(120 * km, 2 * h);\n
     
    This function works but does not provide any type safety to the users. The function arguments can be easily reordered on the call site. Also, we do not get any information about the return type of the function or any safety measures to ensure that the function logic actually returns a quantity of speed.
     
    To improve safety, with a units-only library, we have to write the function in the following way:
     
    template<typename Rep1, typename Rep2>\nquantity<si::metre / si::second, decltype(Rep1{} / Rep2{})> avg_speed(quantity<si::metre, Rep1> distance,\n                                                                      quantity<si::second, Rep2> time)\n{\n  return distance / time;\n}\n\navg_speed(120 * km, 2 * h).in(km / h);\n
     
    Despite being safer, the above code decreased the performance because we always pay for the conversion at the function's input and output.
     
    Moreover, in a good library, the above code should not compile. The reason for this is that even though the conversion from km to m and from h to s is considered value-preserving, it is not true in the opposite direction. When we try to convert the result stored in an integral type from the unit of m/s to km/h, we will inevitably lose some data.
     
    We could try to provide concepts like ScaledUnitOf<si::metre> that would take a set of units while trying to constrain them somehow, but it leads to even more problems with the unit definitions. For example, are Hz and Bq just scaled versions of 1/s? If we constrain the interface to just prefixed units, then litre and a cubic metre or kilometre and mile will be incompatible. What about radian and steradian or a litre per 100 kilometre (popular unit of a fuel consumption) and a squared metre? Should those be compatible?
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#disjoint-units-of-the-same-quantity-type-do-not-work","title":"Disjoint units of the same quantity type do not work","text":"
    Sometimes, we need to define several units describing the same quantity but which should not convert to each other in the library's framework. A typical example here is currency. A user may want to define EURO and USD as units of currency, so both of them can be used for such quantities. However, it is impossible to predefine one fixed conversion factor for those, as a currency exchange rate varies over time, and the library's framework can't provide such an information as an input to the built-in conversion function. User's application may have more information in this domain and handle such a conversion at runtime with custom logic (e.g., using an additional time point function argument). If we would like to model that in a unit-only solution, how can we specify that EURO and USD are units of quantities of currency, but are not convertible to each other?
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#dimensions-to-the-rescue","title":"Dimensions to the rescue?","text":"
    To resolve the above issues, most of the libraries on the market introduce dimension abstraction. Thanks to that, we could solve the first issue of the previous chapter with:
     
    QuantityOf<dim_speed> auto avg_speed(QuantityOf<dim_length> auto distance,\n                                     QuantityOf<dim_time> auto time)\n{\n  return distance / time;\n}\n
     
    and the second one by specifying that both EURO and USD are units of dim_currency. This is a significant improvement but still has some issues.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#limitations-of-dimensions","title":"Limitations of dimensions","text":"
    Let's first look at the above solution again. A domain expert seeing this code will immediately say there is no such thing as a speed dimension. The ISQ specifies only 7 dimensions with unique symbols assigned, and the dimensions of all the ISQ quantities are created as a vector product of those. For example, a quantity of speed has a dimension of \\(L^1T^{-1}\\). So, to be physically correct, the above code should be rewritten as:
     
    QuantityOf<dim_length / dim_time> auto avg_speed(QuantityOf<dim_length> auto distance,\n                                                 QuantityOf<dim_time> auto time)\n{\n  return distance / time;\n}\n
     
    Most of the libraries on the market ignore this fact and try to model distinct quantities through their dimensions, giving a false sense of safety. A dimension is not enough to describe a quantity. This has been known for a long time now. The \"Measurement Data (Archive Report)\" report from 1996 says explicitly:
     
    Measurement Data (Archive Report)
     
    Dimensional analysis does not adequately model the semantics of measurement data.
     
    In the following chapters, we will see a few use cases that can't be solved with an approach that only relies on units or dimensions.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#si-units-of-quantities-of-the-same-dimension-but-different-kinds","title":"SI units of quantities of the same dimension but different kinds","text":"
    The SI provides several units for distinct quantities of the same dimension but different kinds. For example:
     
       
    • hertz (Hz) is a unit of frequency and becquerel (Bq) is a unit of activity.   Both are defined as \\(s^{-1}\\), and have the same dimension of \\(T^{-1}\\).
      •  
    • gray (Gy) is a unit of absorbed dose and sievert (Sv) is a unit of dose equivalent.   Both are defined as \\(m^2 s^{-2}\\), and have the same dimension of \\(L^2T^{-2}\\)
      •  
    • radian (rad) is a unit of plane angle defined as \\(m/m\\), and   steradian (sr) is a unit of solid angle defined as \\(m^2/m^2\\).   Both are quantities of dimension one, which also has its own units like one (1) and percent (%).
      •  
     
    There are many more similar examples in the ISO/IEC 80000 series. For example, storage capacity quantity can be measured in units of one, bit, octet, and byte.
     
    The above conflicts can't be solved with dimensions, and they yield many safety issues. For example, we can ask ourselves what should be the result of the following:
     
       
    1. quantity q = 1 * Hz + 1 * Bq;
      2.  
    2. quantity<Gy> q = 42 * Sv;
      3.  
    3. bool b = (1 * rad + 1 * bit) == 2 * sr;
      4.  
     
    None of the above code should compile, but most of the libraries on the market happily accept it and provide meaningless results. Some of them decide not to define one or more of the above units at all to avoid potential safety issues. For example, the Au library does not define Sv to avoid mixing it up with Gy.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#derived-quantities-of-the-same-dimension-but-different-kinds","title":"Derived quantities of the same dimension but different kinds","text":"
    Even if some quantities do not have a specially assigned unit, they may still have a totally different physical meaning even if they share the same dimension:
     
       
    • work vs. moment of force both of the same dimension \\(L^2MT^{-2}\\),
      •  
    • fuel consumption expressed in \\(\\frac{l}{100\\;km}\\) vs. area expressed in \\(m^2\\) both of the same   dimension \\(L^2\\).
      •  
     
    Again, we don't want to accidentally mix those.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#various-quantities-of-the-same-dimension-and-kinds","title":"Various quantities of the same dimension and kinds","text":"
    Even if we somehow address all the above, there are plenty of use cases that still can't be safely implemented with such abstractions.
     
    Let's consider that we want to implement a freight transport application to position cargo in the container. In majority of the products on the market we will end up with something like:
     
    class Box {\n  length length_;\n  length width_;\n  length height_;\npublic:\n  Box(length l, length w, length h): length_(l), width_(w), height_(h) {}\n  area floor() const { return length_ * width_; }\n  // ...\n};\n
     
    Box my_box(2 * m, 3 * m, 1 * m);\n
     
    Such interfaces are not much safer than just using plain fundamental types (e.g., double). One of the main reasons of using a quantities and units library was to introduce strong-type interfaces to prevent such issues. In this scenario, we need to be able to discriminate between length, width, and height of the package.
     
    A similar but also really important use case is in aviation. The current altitude is a totally different quantity than the distance to the destination. The same is true for forward speed and sink rate. We do not want to accidentally mix those.
     
    When we deal with energy, we should be able to implicitly construct it from a proper product of any mass, length, and time. However, when we want to calculate gravitational potential energy, we may not want it to be implicitly initialized from any expression of matching dimensions. Such an implicit construction should be allowed only if we multiply a mass with acceleration of free fall and height. All other conversions should have an explicit annotation to make it clear that something potentially unsafe is being done in the code. Also, we should not be able to assign a potential energy to a quantity of kinetic energy. However, both of them (possibly accumulated with each other) should be convertible to a mechanical energy quantity.
     
    mass m = 1 * kg;\nlength l = 1 * m;\ntime t = 1 * s;\nacceleration_of_free_fall g = 9.81 * m / s2;\nheight h = 1 * m;\nspeed v = 1 * m / s;\nenergy e = m * pow<2>(l) / pow<2>(t);                     // OK\npotential_energy ep1 = e;                                 // should not compile\npotential_energy ep2 = static_cast<potential_energy>(e);  // OK\npotential_energy ep3 = m * g * h;                         // OK\nkinetic_energy ek1 = m * pow<2>(v) / 2;                   // OK\nkinetic_energy ek2 = ep3 + ek1;                           // should not compile\nmechanical_energy me = ep3 + ek1;                         // OK\n
     
    Yet another example comes from the audio industry. In the audio software, we want to treat specific counts (e.g., beats, samples) as separate quantities. We could assign dedicated base dimensions to them. However, if we divide them by duration, we should obtain a quantity convertible to frequency and even be able to express the result in a unit of Hz. With the dedicated dimensions approach, this wouldn't work as the dimension of frequency is just \\(T^{-1}\\), which would not match the results of our dimensional equations. This is why we can't assign dedicated dimensions to such counts.
     
    The last example that we want to mention here comes from finance. This time, we need to model currency volume as a special quantity of currency. currency volume can be obtained by multiplying currency by the dimensionless market quantity. Of course, both currency and currency volume should be expressed in the same units (e.g., USD).
     
    None of the above scenarios can be addressed with just units and dimensions. We need a better abstraction to safely implement them.
    "},{"location":"blog/2024/10/14/international-system-of-quantities-isq-part-2---problems-when-isq-is-not-used/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will introduce the main ideas behind the International System of Quantities and describe how we can model it in the programming language.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/","title":"International System of Quantities (ISQ): Part 3 - Modeling ISQ","text":"
    The physical units libraries on the market typically only focus on modeling one or more systems of units. However, as we have learned, this is not the only system kind to model. Another, and maybe even more important, is a system of quantities. The most important example here is the International System of Quantities (ISQ) defined by ISO/IEC 80000.
     
    This article continues our series about the International System of Quantities. This time, we will learn about the main ideas behind the ISQ and describe how it can be modelled in a programming language.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"
    Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. Let's repeat briefly some of the problems described in more detail in the previous article. For example, let's see the following implementation:
     
    class Box {\n  area base_;\n  length height_;\npublic:\n  Box(length l, length w, length h) : base_(l * w), height_(h) {}\n  // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\n
     
    How do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do. 
     
    Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are distinct quantities.
     
    A similar issue is related to figuring out what should be the result of:
     
    auto res = 1 * Hz + 1 * Bq + 1 * Bd;\n
     
    where:
     
       
    • Hz (hertz) - unit of frequency,
      •  
    • Bq (becquerel) - unit of activity,
      •  
    • Bd (baud) - unit of modulation rate.
      •  
     
    All of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
     
    If the above example seems too abstract, let's consider Gy (gray - unit of absorbed dose) and Sv (sievert - unit of dose equivalent), or radian and steradian. All of those quantities have the same dimensions.
     
    Another example here is fuel consumption (fuel volume divided by distance, e.g., 6.7 l/100km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
     
    It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"
    As it was described in the previous article, dimension is not enough to describe a quantity. We need a better abstraction to ensure the safety of our calculations. It turns out that ISO/IEC 80000 comes with the answer:
     
    ISO 80000-1:2009
     
       
    • Quantities may be grouped together into categories of quantities that are   mutually comparable.
      •  
    • Mutually comparable quantities are called quantities of the same kind.
      •  
    • Two or more quantities cannot be added or subtracted unless they belong to the same category   of mutually comparable quantities.
      •  
    • Quantities of the same kind within a given system of quantities have the same quantity   dimension.
      •  
    • Quantities of the same dimension are not necessarily of the same kind.
      •  
     
    ISO Guide also explicitly states:
     
    ISO Guide
     
    Measurement units of quantities of the same quantity dimension may be designated by the same name and symbol even when the quantities are not of the same kind. For example, joule per kelvin and J/K are respectively the name and symbol of both a measurement unit of heat capacity and a measurement unit of entropy, which are generally not considered to be quantities of the same kind. However, in some cases special measurement unit names are restricted to be used with quantities of specific kind only. For example, the measurement unit \u2018second to the power minus one\u2019 (1/s) is called hertz (Hz) when used for frequencies and becquerel (Bq) when used for activities of radionuclides. As another example, the joule (J) is used as a unit of energy, but never as a unit of moment of force, i.e. the newton metre (N \u00b7 m).
     
    The above quotes from ISO provide answers to all the issues mentioned above and in the previous article.
     
    More than one quantity may be defined for the same dimension:
     
       
    • quantities of different kinds (e.g., frequency, modulation rate, activity).
      •  
    • quantities of the same kind (e.g., length, width, altitude, distance, radius,   wavelength, position vector).
      •  
     
    Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are of different kinds, the expression provided above should not compile.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"
    ISO/IEC 80000 specifies hundreds of different quantities. Plenty of various kinds are provided, and often, each kind contains more than one quantity. It turns out that such quantities form a hierarchy of quantities of the same kind.
     
    For example, here are all quantities of the kind length provided in the ISO 80000-3:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    Each of the above quantities expresses some kind of length, and each can be measured with meters, which is the unit defined by the SI for quantities of length. However, each has different properties, usage, and sometimes even a different character (position vector and displacement are vector quantities).
     
    Forming such a hierarchy helps us define arithmetics and conversion rules for various quantities of the same kind.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#converting-between-quantities-of-the-same-kind","title":"Converting between quantities of the same kind","text":"
    Based on the hierarchy above, we can define the following quantity conversion rules:
     
       
    1.  
      Implicit conversions
       
         
      • Every width is a length.
        •  
      • Every radius is a width.
        •  
       
      static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\n
       
      Implicit conversions are allowed on copy-initialization:
       
      void foo(quantity<isq::length[m]> q);\n
       
      quantity<isq::width[m]> q1 = 42 * m;\nquantity<isq::length[m]> q2 = q1;  // implicit quantity conversion\nfoo(q1);                           // implicit quantity conversion\n
       
      2.  
    2.  
      Explicit conversions
       
         
      • Not every length is a width.
        •  
      • Not every width is a radius.
        •  
       
      static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\n
       
      Explicit conversions are forced by passing the quantity to a call operator of a quantity_spec type:
       
      void foo(quantity<isq::height[m]> q);\n
       
      quantity<isq::length[m]> q1 = 42 * m;\nquantity<isq::height[m]> q2 = isq::height(q1);  // explicit quantity conversion\nfoo(isq::height(q1));                           // explicit quantity conversion\n
       
      3.  
    3.  
      Explicit casts
       
         
      • height is never a width, and vice versa.
        •  
      • Both height and width are quantities of kind length.
        •  
       
      static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\n
       
      Explicit casts are forced with a dedicated quantity_cast function:
       
      void foo(quantity<isq::height[m]> q);\n
       
      quantity<isq::width[m]> q1 = 42 * m;\nquantity<isq::height[m]> q2 = quantity_cast<isq::height>(q1);  // explicit quantity cast\nfoo(quantity_cast<isq::height>(q1));                           // explicit quantity cast\n
       
      4.  
    4.  
      No conversion
       
         
      • time has nothing in common with length.
        •  
       
      static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\n
       
      Even the explicit casts will not force such a conversion:
       
      void foo(quantity<isq::length[m]>);\n
       
      quantity<isq::length[m]> q1 = 42 * s;    // Compile-time error\nfoo(quantity_cast<isq::length>(42 * s)); // Compile-time error\n
       
      5.  
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#comparing-adding-and-subtracting-quantities-of-the-same-kind","title":"Comparing, adding, and subtracting quantities of the same kind","text":"
    ISO/IEC 80000 explicitly states that width and height are quantities of the same kind, and as such they:
     
       
    • are mutually comparable,
      •  
    • can be added and subtracted.
      •  
     
    This means that we should be allowed to compare any quantities from the same tree (as long as their underlying representation types are comparable):
     
    static_assert(isq::radius(1 * m) == isq::height(1 * m));\n
     
    Also, based on our hierarchy above, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
     
    static_assert((isq::width(1 * m) + isq::height(1 * m)).quantity_spec == isq::length);\nstatic_assert((isq::thickness(1 * m) + isq::radius(1 * m)).quantity_spec == isq::width);\nstatic_assert((isq::distance(1 * m) + isq::path_length(1 * m)).quantity_spec == isq::path_length);\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#modeling-a-quantity-kind","title":"Modeling a quantity kind","text":"
    In the quantities and units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
     
    To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
     
    Important
     
    isq::length and kind_of<isq::length> are two different things.
     
    Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
     
    static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\n
     
    Additionally, the result of operations on quantity kinds is also a quantity kind:
     
    static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\n
     
    However, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
     
    static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\n
     
    Info
     
    Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
     
    static_assert(get_kind(isq::width) == kind_of<isq::length>);\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#how-do-systems-of-units-benefit-from-the-isq-and-quantity-kinds","title":"How do systems of units benefit from the ISQ and quantity kinds?","text":"
    Modeling a system of units is the most essential feature and a selling point of every physical units library. Thanks to that, the library can protect users from assigning, adding, subtracting, or comparing incompatible units and provide automated conversion factors between various compatible units.
     
    Probably all the libraries in the wild model the SI (or at least most of it), and many of them provide support for additional units belonging to various other systems (e.g., imperial).
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of units are based on systems of quantities","text":"
    Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. In order to create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
     
    The SI is explicitly stated to be based on the ISQ. Among others, it defines seven base units, one for each base quantity of ISQ. In the library, this is expressed by associating a quantity kind to a unit being defined:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\n
     
    The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
     
    Note
     
    For some systems of units (e.g., natural units), a unit may not have an associated quantity type. For example, if we define the speed of light constant as c = 1, we can define a system where both length and time will be measured in seconds, and speed will be a quantity measured with the unit one. In such case, the definition will look as follows:
     
    inline constexpr struct second final : named_unit<\"s\"> {} second;\n
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"
    Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation \\(s^{-1}\\). However, it also explicitly states:
     
    SI
     
    The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
     
    This is why it is important for the library to allow constraining such units to be used only with a specific quantity kind:
     
    inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\n
     
    With the above, hertz can only be used for frequencies, while becquerel should only be used for quantities of activity:
     
    quantity<isq::frequency[Hz]> q1 = 60 * Bq;   // Compile-time error\nquantity<isq::activity[Hz]> q2;              // Compile-time error\nquantity<isq::frequency[Hz]> q3 = 60 * Hz;   // OK\nstd::cout << q3.in(Bq) << \"\\n\";              // Compile-time error\n
     
    We know already that quantities of different kinds can't be compared, added, and subtracted. The following equation will not compile thanks to constraining derived units to be valid for specific kinds only:
     
    auto q = 1 * Hz + 1 * Bq;   // Fails to compile\n
     
    All of the above features improve the safety of our library and the products that are using it.
    "},{"location":"blog/2024/10/21/international-system-of-quantities-isq-part-3---modeling-isq/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will present how we can implement our ISQ model in a C++ programming language and we will point out some of the first issues that stand in our way.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/","title":"International System of Quantities (ISQ): Part 4 - Implementing ISQ","text":"
    Up until now, we have introduced the International System of Quantities and described how we can model its main aspects. This article will present how to implement those models in a programming language, and we will point out some of the first issues that stand in our way.
     
    In the previous article, we have already introduced a notion of quantity kind, provided kind_of<> specifier, and described how it helps in the modeling of the system of units (e.g., SI).
     
    Now, it is time to see how we can implement hierarchies of quantities of the same kind.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-length","title":"Modeling a hierarchy of kind length","text":"
    First, let's start with something easy - hierarchy of kind length. ISO 80000-3 does a good job of describing all relations between quantities in this case.
     
    We've seen this tree already:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    This is how we can model it in C++:
     
    inline constexpr struct dim_length final          : base_dimension<\"L\"> {} dim_length;\n\ninline constexpr struct length final              : quantity_spec<dim_length> {} length;\ninline constexpr struct width final               : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final              : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final           : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final            : quantity_spec<width> {} diameter;\ninline constexpr struct radius final              : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final         : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final            : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final     : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final          : quantity_spec<length> {} wavelength;\ninline constexpr struct displacement final        : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final     : quantity_spec<displacement> {} position_vector;\n
     
    Thanks to the expressivity and power of C++ templates, we can specify all quantity properties in one line of code. In the above code:
     
       
    • length takes the base dimension to indicate that we are creating a base quantity that will serve   as a root for a tree of quantities of the same kind,
      •  
    • width and following quantities are branches and leaves of this tree with the parent always   provided as the first argument to quantity_spec class template,
      •  
    • breadth is an alias name for the same quantity as width.
      •  
     
    Note
     
    Some quantities may be specified to have complex scalar, vector, or tensor character (e.g., displacement). The quantity character can be set with the last parameter of quantity_spec.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-energy","title":"Modeling a hierarchy of kind energy","text":"
    Base quantities are simple. It is more complicated when we start modeling derived quantities. Let's try to model the hierarchy for energy.
     
    When we look into the ISO/IEC 80000 standards, this task immediately stops being as easy as the previous one. Derived quantity equations often do not automatically form a hierarchy tree, and ISO/IEC standards do not provide a clear answer to inter-quantity dependencies. This is why it is often not obvious what such a tree should look like.
     
    Even more, ISO explicitly states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    Let's try anyway. The below presents some arbitrary hierarchy of derived quantities of kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    potential_energy --- gravitational_potential_energy[\"<b>gravitational_potential_energy</b><br><i>(mass * acceleration_of_free_fall * height)</i>\"]\n    potential_energy --- elastic_potential_energy[\"<b>elastic_potential_energy</b><br><i>(spring_constant * amount_of_compression<sup>2</sup>)</i>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b><br><i>(mass * speed<sup>2</sup>)</i>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    As we can see above, besides what we've already seen for length hierarchy, derived quantities may provide specific recipes that can be used to create them implicitly:
     
       
    •  
      energy is the most generic one and thus can be created from base quantities of mass,   length, and time. As those are also the roots of quantities of their kinds and all other   quantities from their trees are implicitly convertible to them, it means that an energy can be   implicitly constructed from any quantity of mass, length, and time:
       
      static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\n
       
      •  
    •  
      mechanical energy is a more \"specialized\" quantity than energy (not every energy is   a mechanical energy). It is why an explicit cast is needed to convert from either energy or   the results of its quantity equation:
       
      static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     isq::mechanical_energy));\n
       
      •  
    •  
      gravitational potential energy is not only even more specialized one but additionally,   it is special in a way that it provides its own \"constrained\"   quantity equation. Maybe not every   mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every   mass * acceleration_of_free_fall * height is.
       
      static_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n                                     gravitational_potential_energy));\n
       
      •  
     
    And here is the C++ code for it:
     
    inline constexpr struct energy final                         : quantity_spec<mass* pow<2>(length) / pow<2>(time)> {} energy;\ninline constexpr struct mechanical_energy final              : quantity_spec<energy> {} mechanical_energy;                                                            // differs from ISO 80000\ninline constexpr struct potential_energy final               : quantity_spec<mechanical_energy> {} potential_energy;                                                  // differs from ISO 80000\ninline constexpr struct gravitational_potential_energy final : quantity_spec<potential_energy, mass * acceleration_of_free_fall * height> {} potential_energy;        // not in ISO 80000\ninline constexpr struct elastic_potential_energy final       : quantity_spec<potential_energy, spring_constant * pow<2>(amount_of_compression)> {} potential_energy;  // not in ISO 80000\ninline constexpr struct kinetic_energy final                 : quantity_spec<mechanical_energy, mass* pow<2>(speed)> {} kinetic_energy;                               // differs from ISO 80000\ninline constexpr struct enthalpy final                       : quantity_spec<energy> {} enthalpy;                                                                     // differs from ISO 80000\ninline constexpr struct internal_energy final                : quantity_spec<enthalpy> {} internal_energy;                                                            // differs from ISO 80000\ninline constexpr auto thermodynamic_energy = internal_energy;\ninline constexpr struct Helmholtz_energy final               : quantity_spec<internal_energy> {} Helmholtz_energy;\ninline constexpr auto Helmholtz_function = Helmholtz_energy;\ninline constexpr struct Gibbs_energy final                   : quantity_spec<enthalpy> {} Gibbs_energy;\ninline constexpr auto Gibbs_function = Gibbs_energy;\n
     
    Again, the first parameter of quantity_spec determines the position in the tree. If a second argument is provided, it denotes a recipe for this quantity.
     
    With the above simple definitions we've automatically addressed our energy-related issues from the Various quantities of the same dimension and kinds chapter of the \"Part 2\" article.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#modeling-a-hierarchy-of-kind-dimensionless","title":"Modeling a hierarchy of kind dimensionless","text":"
    As the last example for this article, let's try to model and implement quantities of dimension one, often also called dimensionless quantities. This quantity hierarchy contains more than one quantity kind and more than one unit in its tree:
     
    flowchart TD\n    dimensionless[\"<b>dimensionless</b><br>[one]\"]\n    dimensionless --- rotation[\"<b>rotation</b>\"]\n    dimensionless --- thermodynamic_efficiency[\"<b>thermodynamic_efficiency</b><br><i>(work / heat)</i>\"]\n    dimensionless --- angular_measure[\"<b>angular_measure</b><br><i>(arc_length / radius)</i><br>[rad]\"]\n    angular_measure --- rotational_displacement[\"<b>rotational_displacement</b><br><i>(path_length / radius)</i>\"]\n    angular_measure --- phase_angle[\"<b>phase_angle</b>\"]\n    dimensionless --- solid_angular_measure[\"<b>solid_angular_measure</b><br><i>(area / pow<2>(radius))</i><br>[sr]\"]\n    dimensionless --- drag_factor[\"<b>drag_factor</b><br><i>(drag_force / (mass_density * pow<2>(speed) * area))</i>\"]\n    dimensionless --- storage_capacity[\"<b>storage_capacity</b><br>[bit]\"] --- equivalent_binary_storage_capacity[\"<b>equivalent_binary_storage_capacity</b>\"]\n    dimensionless --- ...
     
    To enable such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
     
    inline constexpr struct dimensionless final            : quantity_spec<detail::derived_quantity_spec<>{}> {} dimensionless;\ninline constexpr struct rotation final                 : quantity_spec<dimensionless> {} rotation;\ninline constexpr struct thermodynamic_efficiency final : quantity_spec<dimensionless, work / heat> {} efficiency;\ninline constexpr struct angular_measure final          : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct rotational_displacement final  : quantity_spec<angular_measure, path_length / radius> {} rotational_displacement;\ninline constexpr struct phase_angle final              : quantity_spec<angular_measure> {} phase_angle;\ninline constexpr struct solid_angular_measure final    : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct drag_factor final              : quantity_spec<dimensionless, drag_force / (mass_density * pow<2>(speed) * area)> {} drag_factor;\ninline constexpr struct storage_capacity final         : quantity_spec<dimensionless, is_kind> {} storage_capacity;\n
     
    With the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
     
    inline constexpr struct radian final    : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final       : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\n
     
    but still allow the usage of one and its scaled versions for such quantities.
     
    Note
     
    dimensionless is a special quantity which serves as an identity element in quantity equations. It is predefined in the library's framework and there is no way for the user to define it or something similar to it.
    "},{"location":"blog/2024/10/28/international-system-of-quantities-isq-part-4---implementing-isq/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will present how our ISQ model helps to address the remaining issues described in the Part 2 of our series.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/","title":"International System of Quantities (ISQ): Part 5 - Benefits","text":"
    In the previous articles, we introduced the International System of Quantities, described how we can model and implement it in a programming language, and presented the issues of software that does not use such abstraction to implement a units library.
     
    Some of the issues raised in Part 2 of our series were addressed in Part 3 already. This article will present how our ISQ model elegantly addresses the remaining problems.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#generic-but-safe-interfaces","title":"Generic but safe interfaces","text":"
    Let's start with the implementation of a generic utility function that would calculate the average speed based on provided arguments. The resulting quantity should use a derived unit of the provided arguments (e.g., km/h for km and h, m/s for m and s, ...).
     
    With C++ concepts backed up with ISQ quantities, we can simply type it as:
     
    constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    The above constrains the algorithm to proper quantity types and ensures that a quantity of speed is returned. The latter is essential not only for the users to better understand what the function does but also serves as a unit test for our implementation. It ensures that our quantity equations are correct in the implementation part of the function, and we indeed return a quantity of speed.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#non-convertible-units-of-currency","title":"Non-convertible units of currency","text":"
    Our second example was about disjoint units of currency. We want to use various units of currency but we can't provide compile-time known conversion factors between those as such ratios are only known at runtime.
     
    First, we define:
     
       
    • a new dimension for currency and a quantity type based on it,
      •  
    • set of disjoint units of currency for its quantity kind.
      •  
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct euro final : named_unit<\"EUR\", kind_of<currency>> {} euro;\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto EUR = euro;\ninline constexpr auto USD = us_dollar;\n\n}\n\nstatic_assert(!std::equality_comparable_with<quantity<euro, int>, quantity<us_dollar, int>>);\n
     
    Next, we can provide a custom currency exchange facility that accounts for a specific point in time:
     
    template<Unit auto From, Unit auto To>\n[[nodiscard]] double exchange_rate(std::chrono::sys_seconds timestamp)\n{\n  // user-provided logic...\n}\n\ntemplate<UnitOf<currency> auto To, QuantityOf<currency> From>\nQuantityOf<currency> auto exchange_to(From q, std::chrono::sys_seconds timestamp)\n{\n  const auto rate =\n    static_cast<From::rep>(exchange_rate<From::unit, To>(timestamp) * q.numerical_value_in(q.unit));\n  return rate * From::quantity_spec[To];\n}\n
     
    Finally, we can use our simple model in the following way:
     
    using namespace unit_symbols;\nusing namespace std::chrono;\n\nconst auto yesterday = time_point_cast<seconds>(system_clock::now() - hours{24});\nconst quantity price_usd = 100 * USD;\nconst quantity price_euro = exchange_to<euro>(price_usd, yesterday);\n\nstd::cout << price_usd << \" -> \" << price_euro << \"\\n\";\n// std::cout << price_usd + price_euro << \"\\n\";  // does not compile\n
     
    Note
     
    It would be better to model the above prices as quantity points, but this is a subject for a different article .
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#derived-quantities-of-the-same-dimension-but-different-kinds","title":"Derived quantities of the same dimension but different kinds","text":"
    Until now, the issues discussed have not actually required modeling of the ISQ. The introduction of physical dimensions would be enough, and indeed, this is what most of the libraries on the market do. However, we have more exciting challenges to solve as well.
     
    The next issue was related to different quantities having the same dimension. In many cases, we want to prevent conversions and any other compatibility between such distinct quantities.
     
    Let's try to implement our fuel consumption example. First, we define the quantity type and a handy identifier for a derived unit that we want to use:
     
    inline constexpr struct fuel_consumption final : quantity_spec<isq::volume / isq::length> {} fuel_consumption;\ninline constexpr auto L_per_100km = si::litre / (mag<100> * si::kilo<si::metre>);\n\nstatic_assert(fuel_consumption != isq::area);\nstatic_assert(fuel_consumption.dimension == isq::area.dimension);\n
     
    Next, we define two quantities. The first one is based only on a derived unit of L/[100 km], while the second uses a strongly typed quantity type:
     
    quantity q1 = 5.8 * L_per_100km;\nquantity q2 = fuel_consumption(6.7 * L_per_100km);\nstd::println(\"Fuel consumptions: {}, {}\", q1, q2);\n\nstatic_assert(implicitly_convertible(q1.quantity_spec, isq::area));\nstatic_assert(!implicitly_convertible(q2.quantity_spec, isq::area));\nstatic_assert(!explicitly_convertible(q2.quantity_spec, isq::area));\nstatic_assert(!castable(q2.quantity_spec, isq::area));\n
     
    As we can see, with just units (especially derived ones) and dimensions, we often can't achieve the same level of safety as with adequately modeled hierarchies of quantities. Only in case of q2 we can prevent incorrect conversions to a different quantity of the same dimension.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#various-quantities-of-the-same-dimension-and-kinds","title":"Various quantities of the same dimension and kinds","text":"
    In the previous example, area and fuel consumption were quantities of the same dimension but of different kinds. In engineering, there are also many cases where we need to model distinct quantities of the same kind.
     
    Let's try to improve the safety of our Box example.
     
    First, we need to extend our ISQ definitions by the horizontal length quantity and a horizontal area derived from it:
     
    inline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\ninline constexpr struct horizontal_area final : quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n
     
    Note
     
    isq::length denotes any quantity of length (not only the horizontal one).
     
    static_assert(implicitly_convertible(horizontal_length, isq::length));\nstatic_assert(!implicitly_convertible(isq::length, horizontal_length));\n\nstatic_assert(implicitly_convertible(horizontal_area, isq::area));\nstatic_assert(!implicitly_convertible(isq::area, horizontal_area));\n\nstatic_assert(implicitly_convertible(isq::length * isq::length, isq::area));\nstatic_assert(!implicitly_convertible(isq::length * isq::length, horizontal_area));\n\nstatic_assert(implicitly_convertible(horizontal_length * isq::width, isq::area));\nstatic_assert(implicitly_convertible(horizontal_length * isq::width, horizontal_area));\n
     
    With simple two lines of definition, we made the above logic automatically work without needing additional customization for special cases. Based on hierarchies of derived quantities and their recipes, the proposed model automatically inherits the properties of base quantities involved in the recipe. This makes the composition of derived quantities very easy, which is not true for alternative solutions based on tag types that do not compose their properties.
     
    Now we can refactor our Box to benefit from the introduced safe abstractions:
     
    class Box {\n  quantity<horizontal_length[m]> length_;\n  quantity<isq::width[m]> width_;\n  quantity<isq::height[m]> height_;\npublic:\n  Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n    length_(l), width_(w), height_(h)\n  {}\n\n  quantity<horizontal_area[m2]> floor() const { return length_ * width_; }\n  // ...\n};\n
     
    It is important to note that the safety can be enforced only when a user provides typed quantities as arguments to the functions:
     
    Box my_box1(2 * m, 3 * m, 1 * m);\nBox my_box2(2 * horizontal_length[m], 3 * isq::width[m], 1 * isq::height[m]);\nBox my_box3(horizontal_length(2 * m), isq::width(3 * m), isq::height(1 * m));\n
     
    Important
     
    It is up to the user to decide when and where to care about explicit quantity types and when to prefer simple unit-only mode.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#various-kinds-of-dimensionless-quantities","title":"Various kinds of dimensionless quantities","text":"
    Most of the quantities hierarchies describe only one kind. There are some exceptions, though. One of them is a hierarchy of dimensionless quantities. This tree defines quantities that denote:
     
       
    • counts (e.g., storage capacity),
      •  
    • ratios (e.g., efficiency),
      •  
    • angles (e.g., angular measure, solid angular measure),
      •  
    • scaled numbers.
      •  
     
    Each of the above could form a separate tree of mutually comparable quantities. However, all of them have a common property. Every quantity from this tree, despite often being measured in a dedicated unit (e.g., bit, rad, sr), should also be able to be measured in a unit one.
     
    We've seen how to model such a hierarchy in a previous article in our series. This time, we will see a simplified part of a concrete, real-life example for this use case.
     
    We often need to provide strong types for different counts in the digital signal processing domain. Abstractions like samples, beats, MIDI clock, and others should not be possible to be intermixed with each other:
     
    namespace ni {\n\ninline constexpr struct SampleCount final : quantity_spec<dimensionless, is_kind> {} SampleCount;\ninline constexpr struct UnitSampleAmount final : quantity_spec<dimensionless, is_kind> {} UnitSampleAmount;\ninline constexpr struct MIDIClock final : quantity_spec<dimensionless, is_kind> {} MIDIClock;\ninline constexpr struct BeatCount final : quantity_spec<dimensionless, is_kind> {} BeatCount;\n
     
    We should also be able to create derived quantities from those. For example, when we divide such a quantity by time we should get a new strong quantity that can be measured in both a dedicated unit (e.g., Smpl/s for sample rate) and hertz:
     
    inline constexpr struct SampleDuration final : quantity_spec<isq::period_duration> {} SampleDuration;\ninline constexpr struct SamplingRate final : quantity_spec<isq::frequency, SampleCount / SampleDuration> {} SamplingRate;\n\ninline constexpr auto Amplitude = UnitSampleAmount;\ninline constexpr auto Level = UnitSampleAmount;\ninline constexpr struct Power final : quantity_spec<Level * Level> {} Power;\n\ninline constexpr struct BeatDuration final : quantity_spec<isq::period_duration> {} BeatDuration;\ninline constexpr struct Tempo final : quantity_spec<isq::frequency, BeatCount / BeatDuration> {} Tempo;\n
     
    We can also define a collection of units associated with specific quantity kinds and their symbols:
     
    inline constexpr struct Sample final : named_unit<\"Smpl\", one, kind_of<SampleCount>> {} Sample;\ninline constexpr struct SampleValue final : named_unit<\"PCM\", one, kind_of<UnitSampleAmount>> {} SampleValue;\ninline constexpr struct MIDIPulse final : named_unit<\"p\", one, kind_of<MIDIClock>> {} MIDIPulse;\n\ninline constexpr struct QuarterNote final : named_unit<\"q\", one, kind_of<BeatCount>> {} QuarterNote;\ninline constexpr struct HalfNote final : named_unit<\"h\", mag<2> * QuarterNote> {} HalfNote;\ninline constexpr struct DottedHalfNote final : named_unit<\"h.\", mag<3> * QuarterNote> {} DottedHalfNote;\ninline constexpr struct WholeNote final : named_unit<\"w\", mag<4> * QuarterNote> {} WholeNote;\ninline constexpr struct EightNote final : named_unit<\"8th\", mag_ratio<1, 2> * QuarterNote> {} EightNote;\ninline constexpr struct DottedQuarterNote final : named_unit<\"q.\", mag<3> * EightNote> {} DottedQuarterNote;\ninline constexpr struct QuarterNoteTriplet final : named_unit<\"qt\", mag_ratio<1, 3> * HalfNote> {} QuarterNoteTriplet;\ninline constexpr struct SixteenthNote final : named_unit<\"16th\", mag_ratio<1, 2> * EightNote> {} SixteenthNote;\ninline constexpr struct DottedEightNote final : named_unit<\"q.\", mag<3> * SixteenthNote> {} DottedEightNote;\n\ninline constexpr auto Beat = QuarterNote;\n\ninline constexpr struct BeatsPerMinute final : named_unit<\"bpm\", Beat / si::minute> {} BeatsPerMinute;\ninline constexpr struct MIDIPulsePerQuarter final : named_unit<\"ppqn\", MIDIPulse / QuarterNote> {} MIDIPulsePerQuarter;\n\nnamespace unit_symbols {\n\ninline constexpr auto Smpl = Sample;\ninline constexpr auto pcm = SampleValue;\ninline constexpr auto p = MIDIPulse;\n\ninline constexpr auto n_wd = 3 * HalfNote;\ninline constexpr auto n_w = WholeNote;\ninline constexpr auto n_hd = DottedHalfNote;\ninline constexpr auto n_h = HalfNote;\ninline constexpr auto n_qd = DottedQuarterNote;\ninline constexpr auto n_q = QuarterNote;\ninline constexpr auto n_qt = QuarterNoteTriplet;\ninline constexpr auto n_8thd = DottedEightNote;\ninline constexpr auto n_8th = EightNote;\ninline constexpr auto n_16th = SixteenthNote;\n\n}\n\n}  // namespace ni\n
     
    With the above, we can safely work with each quantity and use SI or domain-specific units as needed:
     
    using namespace ni::unit_symbols;\nusing namespace mp_units::si::unit_symbols;\n\nconst auto sr1 = ni::GetSampleRate();\nconst auto sr2 = 48'000.f * Smpl / s;\n\nconst auto samples = 512 * Smpl;\n\nconst auto sampleTime1 = (samples / sr1).in(s);\nconst auto sampleTime2 = (samples / sr2).in(ms);\n\nconst auto sampleDuration1 = (1 / sr1).in(ms);\nconst auto sampleDuration2 = (1 / sr2).in(ms);\n\nconst auto rampTime = 35.f * ms;\nconst auto rampSamples1 = (rampTime * sr1).force_in<int>(Smpl);\nconst auto rampSamples2 = (rampTime * sr2).force_in<int>(Smpl);\n\nstd::println(\"Sample rate 1 is: {}\", sr1);\nstd::println(\"Sample rate 2 is: {}\", sr2);\n\nstd::println(\"{} @ {} is {::N[.5f]}\", samples, sr1, sampleTime1);\nstd::println(\"{} @ {} is {::N[.5f]}\", samples, sr2, sampleTime2);\n\nstd::println(\"One sample @ {} is {::N[.5f]}\", sr1, sampleDuration1);\nstd::println(\"One sample @ {} is {::N[.5f]}\", sr2, sampleDuration2);\n\nstd::println(\"{} is {} @ {}\", rampTime, rampSamples1, sr1);\nstd::println(\"{} is {} @ {}\", rampTime, rampSamples2, sr2);\n
     
    The above prints:
     
    Sample rate 1 is: 44100 Hz\nSample rate 2 is: 48000 Smpl/s\n512 Smpl @ 44100 Hz is 0.01161 s\n512 Smpl @ 48000 Smpl/s is 10.66667 ms\nOne sample @ 44100 Hz is 0.02268 ms\nOne sample @ 48000 Smpl/s is 0.02083 ms\n35 ms is 1543 Smpl @ 44100 Hz\n35 ms is 1680 Smpl @ 48000 Smpl/s\n
     
    We can also do a bit more advanced computations to get the following:
     
    auto sampleValue = -0.4f * pcm;\nauto power1 = sampleValue * sampleValue;\nauto power2 = -0.2 * pow<2>(pcm);\n\nauto tempo = ni::GetTempo();\nauto reverbBeats = 1 * n_qd;\nauto reverbTime = reverbBeats / tempo;\n\nauto pulsePerQuarter = value_cast<float>(ni::GetPPQN());\nauto transportPosition = ni::GetTransportPos();\nauto transportBeats = (transportPosition / pulsePerQuarter).in(n_q);\nauto transportTime = (transportBeats / tempo).in(s);\n\nstd::println(\"SampleValue is: {}\", sampleValue);\nstd::println(\"Power 1 is: {}\", power1);\nstd::println(\"Power 2 is: {}\", power2);\n\nstd::println(\"Tempo is: {}\", tempo);\nstd::println(\"Reverb Beats is: {}\", reverbBeats);\nstd::println(\"Reverb Time is: {}\", reverbTime.in(s));\nstd::println(\"Pulse Per Quarter is: {}\", pulsePerQuarter);\nstd::println(\"Transport Position is: {}\", transportPosition);\nstd::println(\"Transport Beats is: {}\", transportBeats);\nstd::println(\"Transport Time is: {}\", transportTime);\n
     
    which prints:
     
    SampleValue is: -0.4 PCM\nPower 1 is: 0.16000001 PCM\u00b2\nPower 2 is: -0.2 PCM\u00b2\nTempo is: 110 bpm\nReverb Beats is: 1 q.\nReverb Time is: 0.8181818 s\nPulse Per Quarter is: 960 ppqn\nTransport Position is: 15836 p\nTransport Beats is: 16.495832 q\nTransport Time is: 8.997726 s\n
     
    Info
     
    More about this example can be found in \"Exploration of Strongly-typed Units in C++: A Case Study from Digital Audio\" CppCon 2023 talk by Roth Michaels.
    "},{"location":"blog/2024/11/04/international-system-of-quantities-isq-part-5---benefits/#to-be-continued","title":"To be continued...","text":"
    In the next part of this series, we will discuss the challenges and issues related to the modeling of the ISQ with a programming language.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/","title":"International System of Quantities (ISQ): Part 6 - Challenges","text":"
    This article might be the last one from our series. This time, we will discuss the challenges and issues with modeling of the ISQ in software.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#articles-from-this-series","title":"Articles from this series","text":"
       
    • Part 1 - Introduction
      •  
    • Part 2 - Problems when ISQ is not used
      •  
    • Part 3 - Modeling ISQ
      •  
    • Part 4 - Implementing ISQ
      •  
    • Part 5 - Benefits
      •  
    • Part 6 - Challenges
      •  
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#ambiguity","title":"Ambiguity","text":"
    Some quantity names are ambiguous. It is not a problem of ISQ but of the English language and the way we communicate things. When I say: \"Every width is a length, but not every length is a width\" most people understand this right away. However, the same people trying to model our 3D box problem try to do it as follows:
     
    class Box {\n  quantity<isq::length[m]> length_;\n  quantity<isq::width[m]> width_;\n  quantity<isq::height[m]> height_;\npublic:\n  // ...\n};\n
     
    This looks correct at first sight. Only when we think about the sentence mentioned above will we realize that this implementation has a problem. We intended to specify three orthogonal dimensions of the box, each of which will be a strong quantity that is not convertible to others. But we've failed.
     
    When we look at the tree of quantities of length we immediately see that both width and height are special lengths so they are convertible to it.
     
    To implement our task correctly, we had to define and use a new quantity of kind length:
     
    inline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n
     
    We do not propose adding horizontal length to ISO 80000-3. There are probably other similar cases as well, but so far, this was the most common and obvious one we've encountered.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#no-common-quantities","title":"No common quantities","text":"
    ISO 80000-1:2009 explicitly states:
     
    Quote
     
    Two or more quantities cannot be added or subtracted unless they belong to the same category of mutually comparable quantities.
     
    This means that we should be able to add and subtract any quantities as long as they belong to the same kind. However, ISO/IEC documents do not provide any rules or even hints about what should be the result of such operations.
     
    If it is possible to add radius and distance, then what quantity should be provided in return? Undoubtedly, the resulting quantity type can't be the same as any of the arguments. It is not a radius or distance. It is some closer unspecified length, though.
     
    Info
     
    Finding the correct solution took us many months of experimentation and implementation. Based on the hierarchy tree of quantities, we can define conversion rules and what a common quantity should be.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-consistency","title":"Lack of consistency","text":"
    The documents of ISO/IEC 80000 are not 100% consistent, and programming languages do not like inconsistencies.
     
    For example:
     
       
    • time is mentioned as a base quantity of ISQ in ISO 80000-1 chapter 4.5.
      •  
    •  
      ISO 80000-3 \"Space and time\", does not define a quantity of time. It provides a duration   quantity (item 3-9) with symbol t, and states in the Remarks section:
       
      Quote
       
      Duration is often just called time.
       
      •  
    •  
      Other parts (e.g., IEC 80000-6 \"Electromagnetism\") often say:
       
      Quote
       
      ... t is time (ISO 80000-3)
       
      •  
     
    To be consistent, ISO/IEC should either:
     
       
    • change ISO 80000-1 chapter 4.5 and all references in other parts to use duration (unlikely),
      •  
    • or add time as an alias name to duration in the definition 3-9 of ISO 80000-3.
      •  
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-definitions","title":"Lack of definitions","text":"
    ISQ defines derived quantities in terms of other quantities provided in the series. However, some definitions mention quantities that are not defined in the ISQ at all.
     
    For example, weight is defined as \\(F_\\textsf{g} = m\\;g\\), where \\(m\\) is the mass of the body (item 4-1 of ISO 80000-4 \"Mechanics\"), and \\(g\\) is the local acceleration of free fall (ISO 80000-3).
     
    The problem here is that ISO 80000-3 never defines a quantity with a symbol \\(g\\) or named as a local acceleration of free fall. The closest one we have is acceleration (item 3-11) with a symbol \\(a\\).
     
    Info
     
    To have a proper definition of weight in mp-units that is not defined in terms of just any kind of acceleration, we have added isq::acceleration_of_free_fall in our definitions as an extension to the original ISQ set of quantities.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#not-engineering-friendly","title":"Not engineering-friendly","text":"
    Many quantities have proper physical definitions, but they are sometimes not engineering-friendly.
     
    For example, velocity is defined as a rate of change of position vector \\(v = \\frac{\\textsf{d}r}{\\textsf{d}t}\\), where \\(r\\) denotes the position vector (item 3\u20111.10) and \\(t\\) the duration (item 3\u20119).
     
    Next, a speed quantity is defined as the magnitude of velocity. Despite being physically correct, requiring every speed to be derived from the vector quantity of velocity in software would be inconvenient. If this was the only case, people would always need to use vector representations of position vectors to talk about speeds, which differs from what we do in practice. In practice, we divide any kind of length by time to get some kind of speed.
     
    ISO 80000-3 provides length, height, distance and other quantities of kind length that when divided by duration can serve really well to calculate speed.
     
    Info
     
    This is why in mp-units, we decided to divert from the official definition of speed and define it as:
     
    inline constexpr struct speed : quantity_spec<speed, length / time> {} speed;\n
     
    This allows us to create a quantity of kind speed from any quantity of length divided by time.
     
    Additionally, it is essential to note that for the needs of our library, defining velocity as position_vector / duration would be wrong. We miss the delta part here. Even though it is not mentioned in ISO 80000-3, the delta of position vectors is actually a displacement. This is why our velocity is defined as:
     
    inline constexpr struct velocity : quantity_spec<speed, displacement / duration> {} velocity;\n
     
    Please also note that velocity is defined as a more specialized quantity of speed.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#affine-space-agnostic","title":"Affine space agnostic","text":"
    The affine space is a powerful abstraction, allowing us to model some problems safer or more accurately. It has two types of entities:
     
       
    • point - a position specified with coordinate values (e.g., location, address, etc.),
      •  
    • displacement vector - the difference between two points (e.g., shift, offset, displacement,   duration, etc.).
      •  
     
    Vectors support all the arithmetics operations, but points have some limitations. It is not possible to:
     
       
    • add two points,
      •  
    • subtract a point from a vector,
      •  
    • multiply nor divide points with anything else.
      •  
     
    ISO/IEC series does not acknowledge this abstraction even though it would be really useful in some cases. Let's discuss the following two examples.
     
    What does it mean to add two altitudes? It is not meaningful. On the other hand, subtracting those should not result in an altitude, but in a quantity of height. Adding or subtracting height to/from altitude results in altitude. Subtracting altitude from height is meaningless again. Those quantities clearly model affine space. Maybe this is why ISQ defines them as one quantity type height/depth/altitude?
     
    What does it mean to add two position vectors? It is not meaningful again. However, subtracting those results in a displacement as we noted in the previous chapter. Adding or subtracting displacement to/from position vector results in another position vector, and subtracting position vector from displacement does not have physical sense. Again, those quantities perfectly model affine space. However, this time, those are defined as separate and independent quantities (i.e., displacement is not modeled as delta position vector or position vector is not modeled as a displacement from the origin of a coordinate system).
     
    Info
     
    Currently, mp-units does not enforce the affine space behavior for such quantities. Today, subtracting two altitudes result in an altitude and subtracting two position vectors result in a position vector. However, we plan to support automatic conversion to a proper quantity type on subtraction and addition shortly.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#non-negative-quantities","title":"Non-negative quantities","text":"
    Some quantities in the ISQ are defined as non-negative. This is a really interesting property that may be checked at runtime to increase safety. However, the number of such quantities is minimal. From a few hundred quantities provided by the ISO/IEC series, only the following have this property mentioned explicitly:
     
       
    • width/breadth,
      •  
    • thickness,
      •  
    • diameter,
      •  
    • radius.
      •  
     
    If height was defined separately from altitude, it could probably also join this group.
     
    Let's think a bit more about this. What does it mean that a quantity is non-negative? Indeed, it is hard to imagine something of a negative width or radius. However, if we subtract two widths, the second one may be larger. This will result in a negative quantity of width, violating our precondition. So, is it non-negative or not?
     
    Again, we have to talk about the affine space abstractions. Every empirical measurement can be expressed as a point. Such points for some quantities may be non-negative indeed.
     
    Non-negative quantities do not end on the ones provided above. For example, speed is a good example here as well. In general, all magnitudes of vector quantities will also have this property.
     
    When subtracting two points, we end up with a delta/displacement type, which may be negative even for quantities listed as non-negative in the ISQ. As stated in the previous chapter, having affine space abstractions acknowledged in ISQ would greatly help here.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-quantity-recipes","title":"Lack of quantity recipes","text":"
    Definition of many derived quantities provides their recipes in the form of quantity equations (e.g., weight equation in the previous chapter). However, some of them do not. Instead, they often provide a very generic description.
     
    For example, force is defined as:
     
    Quote
     
    vector (ISO 80000-2) quantity describing interaction between bodies or particles.
     
    This is not helpful for programming languages that like explicit definitions. Different vendors may interpret the above differently, which will result in different implementations that will not be compatible with each other.
     
    As the derived quantity of force has to be a vector quantity, it has to be defined in terms of at least one other vector quantity. We have a few to choose from:
     
       
    • displacement (\\(\\Delta{r}\\)),
      •  
    • velocity (\\(v\\)),
      •  
    • acceleration (\\(a\\)).
      •  
     
    It is not stated explicitly in ISQ which one of those should be used and how.
     
    Info
     
    In mp-units we decided to define force as \\(F = m\\;a\\).
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#lack-of-generic-quantities-and-name-conflicts","title":"Lack of generic quantities and name conflicts","text":"
    In the previous chapter, we complained about some definitions needing to be more complex or generic. On the other hand, we also lack some generic quantities in ISQ that could serve as a root for a quantity hierarchy tree.
     
    For example:
     
       
    • ISO 80000-4 \"Mechanics\" defines power <mechanics> as \\(P = F\\;v\\) (scalar product of force \\(F\\)   (item 4-9.1) acting to a body and its velocity \\(v\\) (ISO 80000-3)),
      •  
    • ISO 80000-6 \"Electromagnetism\" defines power as \\(p = u\\;i\\) (scalar quantity given by the   product of instantaneous voltage \\(u\\) (item 6-11.3) and instantaneous electric current \\(i\\)   (item 6-1)).
      •  
     
    First, the above definitions have somehow conflicting names which makes it hard for the programming languages to name them consistently by different vendors.
     
    Info
     
    In mp-units, we chose mechanical_power and electromagnetism_power for those.
     
    Second, we do not have any other more generic definition of power to put above those in the tree. Not having it makes it hard to answer what should be the result of:
     
    quantity q = isq::mechanical_power(42 * W) + isq::electromagnetism_power(60 * W);\n
     
    Info
     
    To solve the above problem, we have added isq::power in mp-units, that has a really generic definition of:
     
    inline constexpr struct power : quantity_spec<mass* pow<2>(length) / pow<3>(time)> {} power;\n
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#invalid-definitions-order","title":"Invalid definitions order","text":"
    Energy is defined a bit better than power, but still not without issues.
     
    The first time ISQ mentions energy is in the ISO 80000-4 \"Mechanics\". It defines potential energy, kinetic energy, and a mechanical energy as the sum of the first two. Right after that a mechanical work/work is defined.
     
    Then ISO 80000-5 \"Thermodynamics\" defines energy <thermodynamics> as:
     
    Quote
     
    ability of a system to do work (ISO 80000-4).
     
    Next, internal energy/thermodynamic energy is defined in terms of the change of heat.
     
    From the above, it seems that what is called energy <thermodynamics> should actually be the root of our tree and probably be provided in Part 4 before the mechanical energy is defined.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#hierarchies-of-derived-quantities","title":"Hierarchies of derived quantities","text":"
    Derived quantities of the same kind are often independently defined in the ISQ. The ISO/IEC 80000 series often does not suggest any hierarchy between those. Even more, it states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    Because of this, it is unknown or ambiguous how to form a hierarchy tree for such quantities.
     
    To get some sense of the complexity here, let's look again at our tree of quantities of a kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    Not being exact means that every vendor may implement it differently. This will result in:
     
       
    •  
      different convertibility rules among quantities:
       
      static_assert(implicitly_convertible(isq::potential_energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mechanical_energy, isq::potential_energy));\n
       
      •  
    •  
      different common quantities resulting from the arithmetics on various quantities of the same   kind:
       
      static_assert((isq::potential_energy(1 * J) + isq::kinetic_energy(1 * J)).quantity_spec == isq::mechanical_energy);\n
       
      •  
     
    It would be great if ISQ could provide specific division of quantities into kinds and more information about the position of each quantity within the hierarchy of quantities of the same kind.
     
    Important
     
    We can try to do this by ourselves, but it is tough. Probably no one, for sure we are not, is an expert in all the fields of ISO/IEC 80000 applicability.
     
    We need the help of subject matter experts who will help us build those trees for their domains and then verify that everything works as expected.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#the-same-or-a-different-kind","title":"The same or a different kind?","text":"
    Some quantities are more complicated than others. For example, power has:
     
       
    • real scalar quantities expressed in:
         
      • W (watts) (e.g., mechanical power, active power),
        •  
      • VA (volt-ampere) (e.g., apparent power),
        •  
      • var (e.g., reactive power),
        •  
       
      •  
    • complex scalar quantities expressed in VA (volt-ampere) (e.g., complex power).
      •  
     
    How should we model this? Maybe those should be two or three independent trees of quantities, each having its own unit?
     
    flowchart TD\n    power[\"<b>power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[W]\"]\n    power --- mechanical_power[\"<b>mechanical_power</b><br><i>(scalar_product(force, velocity))</i>\"]\n    power --- electromagnetism_power[\"<b>electromagnetism_power</b> | <b>instantaneous_power</b><br><i>(instantaneous_voltage * instantaneous_electric_current)</i>\"]\n    power --- active_power[\"<b>active_power</b><br><i>(1 / period * instantaneous_power * time)<br>(re(complex_power))</i>\"]\n\n    nonactive_power[\"<b>nonactive_power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[VA]\"]\n    nonactive_power --- reactive_power[\"<b>reactive_power</b><br><i>(im(complex_power))</i><br>[var]\"]\n\n    complex_power[\"<b>complex_power</b><br>{complex}<br><i>(voltage_phasor * electric_current_phasor)<br>(active_power + j * reactive_power)</i><br>[VA]\"]\n    complex_power --- apparent_power[\"<b>apparent_power</b><br><i>(voltage * electric_current)<br>(mod(complex_power))</i>\"]
     
    This will mean that we will not be able to add or compare active power, reactive power, and apparent power, which probably makes a lot of sense. However, it also means that the following will fail to compile:
     
    quantity apparent = isq::apparent_power(100 * VA);\nquantity active = isq::active_power(60 * W);\nquantity<isq::nonactive_power[VA]> q = sqrt(pow<2>(apparent) - pow<2>(active)); // Compile-time error\n
     
    Also the following will not work:
     
    quantity active = isq::active_power(60 * W);\nquantity reactive = isq::reactive_power(40 * var);\nquantity<isq::apparent_power[VA]> q = sqrt(pow<2>(active) + pow<2>(reactive)); // Compile-time error\n
     
    If we want the above to work maybe we need to implement the tree as follows?
     
    flowchart TD\n    power[\"<b>power</b><br><i>(mass * length<sup>2</sup> / time<sup>3</sup>)</i><br>[W]\"]\n    power --- mechanical_power[\"<b>mechanical_power</b><br><i>(scalar_product(force, velocity))</i>\"]\n    power --- electromagnetism_power[\"<b>electromagnetism_power</b> | <b>instantaneous_power</b><br><i>(instantaneous_voltage * instantaneous_electric_current)</i>\"]\n    power --- apparent_power[\"<b>apparent_power</b><br><i>(voltage * electric_current)<br>(mod(complex_power))</i><br>[VA]\"]\n    apparent_power --- active_power[\"<b>active_power</b><br><i>(1 / period * instantaneous_power * time)<br>(re(complex_power))</i>\"]\n    apparent_power --- nonactive_power[\"<b>nonactive_power</b><br><i>(sqrt(apparent_power<sup>2</sup> - active_power<sup>2</sup>))</i><br>\"]\n    nonactive_power --- reactive_power[\"<b>reactive_power</b><br><i>(im(complex_power))</i><br>[var]\"]\n    apparent_power --- complex_power[\"<b>complex_power</b><br>{complex}<br><i>(voltage_phasor * electric_current_phasor)<br>(active_power + j * reactive_power)</i>\"]
     
    However, the above allows direct addition and comparison of active power and nonactive power, and also will not complain if someone will try to use watt (W) as a unit of apparent power or reactive power.
     
    Again, ISQ does not provide a direct answer here.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#more-base-quantities","title":"More base quantities?","text":"
    Is ISQ really based on only seven base quantities? Let's look at the definition of traffic intensity in IEC 80000-13 \"Information science and technology\":
     
    Quote
     
    number of simultaneously busy resources in a particular pool of resources.
     
    It looks like a definition of a specialized dimensionless quantity or, more correctly, a quantity of dimension one. This would not be the only such case. Even in the same Part 13, we can find quantities like storage capacity with a similar property.
     
    Only when we look closer do we start to see differences. All dimensionless quantities, even if they have their own dedicated units, can also be measured in a unit of one (1). This is true for storage capacity (also measured in bits), angular measure (also measured in radians), _solid angular measure (also measured in steradians), and more.
     
    However, traffic intensity can only be measured in erlangs (E), not in a unit one (1). Does it mean that it is a \"hidden\" 8-th base quantity in ISQ? If so, should it have its own dimension as well?
     
    Angular quantities are another interesting case here. Scientists have written petitions and papers for years to make them an additional dimension in ISQ and SI. More about this can be found in our documentation's Strong Angular System chapter.
    "},{"location":"blog/2024/11/11/international-system-of-quantities-isq-part-6---challenges/#summary","title":"Summary","text":"
    ISQ is tremendous and solves many problems we had in modeling various subjects for years in software. As a result, we have more powerful tools in our hands that allow us to deliver safer products.
     
    Unfortunately, ISQ, contrarily to SI, is not widely recognized, and no libraries besides mp-units model it in any programming language. Keeping it behind a paywall does not help either. We hope that posts from this series will spread in the community, raise awareness of ISQ and its benefits, and encourage authors of other libraries to implement it in their products.
     
    Despite all the benefits, it is essential to realize that ISQ has many problems. International standards should be specified in such a way that there is no room for ambiguity in their interpretation by different parties trying to use them. As described above, this is not the case here.
     
    ISQ is not ready to be unambiguously modeled in software by various vendors. Here are the most important problems to solve to allow this:
     
       
    1. ISQ needs to define basic operations on quantities:
      2.  
     
    - what the result of addition and subtraction should be when arguments differ, \u00a0 \u00a0 - convertibility rules.
     
       
    1. The exact quantity equation recipe needs to be included for many derived quantities.
      2.  
    2. Many ISQ quantities do not provide their exact relation versus other quantities of the same    kind (no strict hierarchy).
      3.  
    3. Some missing quantities need to be included. Others would benefit from corrected names.
      4.  
     
    Additionally:
     
       
    • extending ISQ with affine space abstractions,
      •  
    • specifying more quantities as non-negative,
      •  
    • adding more base quantities (i.e., angle)
      •  
     
    could improve the safety of our programs and products that people depend on with their lives on a daily basis.
     
    I hope you enjoyed following this series and learned more about the International System of Quantities. Please try it out in your domain and share feedback with us. We always love to hear about the projects in which our library is being used and about use cases it helps address.
    "},{"location":"blog/2023/11/12/report-from-the-kona-2023-iso-c-committee-meeting/","title":"Report from the Kona 2023 ISO C++ Committee meeting","text":"
    Several groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the mp-units library.
     
    In the following years, we scoped on getting more feedback from the production and design. This resulted in version 2 of the mp-units library that resolved many issues the users and Committee members raised. The features and interfaces of this version are close to being the best we can get with the current version of the C++ language standard.
     
    We submitted three new proposals related to the standardization of the quantities and units library for the last ISO C++ Committee meeting:
     
       
    • P2980: A motivation, scope, and plan for a physical quantities and units library,
      •  
    • P2981: Improving our safety with a physical quantities and units library,
      •  
    • P2982: std::quantity as a numeric type.
      •  
     
    Those were reviewed and briefly discussed in several groups: Numerics (SG6), Safety & Security (SG23), and Library Evolution Working Group (LEWG). Most of the feedback was positive, and the Committee is interested in spending more time on such proposals.
     
    The following poll was taken by the LEWG:
     
    LEWG POLL: Given that our time is limited, more time should be promised for a quantities and units library
     Strongly in Favor In favor Neutral Against Strongly Against 10 13 4 0 0 
    Attendance: 22 + 6
     
    Number of Authors: 4
     
    Authors\u2019 position: 4x SF
     
    Outcome: Strong consensus in favor
     
    Additionally, some concerns were raised about the large scope of the proposal. We were encouraged to return with more details and design rationale in a unified paper. This is what we are working on now for the next Committee meeting that will happen in mid-March 2024 in Tokyo.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/","title":"Report from the St. Louis 2024 ISO C++ Committee meeting","text":"
    We made significant progress in the standardization of this library during the ISO C++ Committee meeting in St. Louis.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p30942r3-stdbasic_fixed_string","title":"P30942R3: std::basic_fixed_string","text":"
    First, the fixed_string was unanimously forwarded from the SG18 LEWG Incubator to the Library Evolution Working Group (LEWG). The group suggested a few minor changes to the paper, which resulted in the R3 version of the proposal.
     
    The paper is in excellent shape, and the entire wording is ready as well. Hopefully it will progress quickly through the remaining groups in the Committee.
    "},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p3045r1-quantities-and-units-library","title":"P3045R1: Quantities and units library","text":"
    In the SG6 (Numerics), we had a really efficient discussion about the recently raised usability issues with temperatures and the Minimal Viable Product (MVP) scope.
     
    The following polls were taken:
     
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, and quantity kinds. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 7 4 7 0 0 
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and quantities of the same kind. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 5 2 5 2 0 
    POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and affine spaces. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
     Strongly in Favor In favor Neutral Against Strongly Against 5 0 8 1 0 
    As we can see, there are no controversies about the first poll that states that the MVP should include at least:
     
       
    • units,
      •  
    • dimensions,
      •  
    • quantity kinds (e.g., frequency vs activity, plane angle vs solid angle,  fuel_consumption vs area).
      •  
     
    The next polls add either:
     
       
    • quantities of the same kind (e.g., length vs width vs wavelength, potential energy vs kinetic energy),
      •  
    • the affine space abstractions (i.e., point origins and quantity_point).
      •  
     
    SG6 considered those less important, but no one was strongly against including those in the MVP. We were asked to return with better motivation and usage examples for those features.
     
    If you are depending on quantities of the same kind or quantity points in your project and you would like to see them in the std library, please let us know about your use cases.
     
    Besides SG6, we spent six hours in the SG18 LEWG Incubator discussing the details of the library design. The proposal was very well received, and we got a few valuable comments and suggestions that we will apply to the next version of the paper.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/","title":"Report from the Tokyo 2024 ISO C++ Committee meeting","text":"
    The Tokyo 2024 meeting was a very important step in the standardization of this library. Several WG21 groups reviewed proposals, and the feedback was really good.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p3045r0-quantities-and-units-library","title":"P3045R0: Quantities and units library","text":"
    The Study Group 6 (Numerics) discussed the proposal for several hours. The initial feedback was positive. There were some concerns related to the description and design of the affine space abstractions in the library. Besides that, the people in the room liked what they saw.
     
    We run a few polls in SG6 as well:
     
    POLL: The syntax number * unit is the right solution for constructing quantities. Not allowing reordering the operands is correct.
     Strongly in Favor In favor Neutral Against Strongly Against 5 4 1 0 1 
    POLL: Not defining any UDLs is the right solution.
     
    No objection to unanimous consent.
     
    The paper was also briefly discussed in SG18 LEWG Incubator, and the initial feedback was also positive. No polls were taken.
     
    SG16 Unicode does not meet during ISO C++ Committee F2F meetings. Still, the text output chapter paper was also reviewed by it during an online meeting before Tokyo. We got good feedback and are expected to return with the updated version. No polls were taken.
    "},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p30942r1-stdbasic_fixed_string","title":"P30942R1: std::basic_fixed_string","text":"
    In the SG18 LEWG Incubator, before we started to talk about P3045R0, we spent a few hours discussing the design of the std::basic_fixed_string, which is proposed for C++26. The group gave excellent feedback, and if the R2 version addresses it properly, the paper is expected to progress to LEWG (Library Evolution Working Group) in St. Louis.
     
    Plenty of polls were taken:
     
    POLL: We should promise more committee time to pursuing std::basic_fixed_string, knowing that our time is scarce and this will leave less time for other work.
     Strongly in Favor In favor Neutral Against Strongly Against 11 0 0 0 0 
    POLL: Should the constructor from a string literal be consteval?
     Strongly in Favor In favor Neutral Against Strongly Against 6 3 2 0 0 
    POLL: Do we want to add .view()?
     Strongly in Favor In favor Neutral Against Strongly Against 3 5 3 0 0 
    POLL: Do we want the .size member to be an integral_constant<size_t, N> (and .empty to be bool_constant<N==0>)?
     Strongly in Favor In favor Neutral Against Strongly Against 5 2 2 2 0 
    POLL: Should the index operator[] return a reference to const?
     Strongly in Favor In favor Neutral Against Strongly Against 2 2 3 3 0 
    POLL: Should the constructor from a string literal have a precondition that txt[N] == 0?
     Strongly in Favor In favor Neutral Against Strongly Against 6 1 2 0 2"},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/","title":"Report from the Wroc\u0142aw 2024 ISO C++ Committee meeting","text":"
    The Wroc\u0142aw 2024 meeting was another efficient step in the standardization of this library. We've spent the entire day on the joint LEWGI and SG6 discussion and got lots of feedback. We've also introduced std::fixed_string to LEWG for C++26.
    "},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/#p3045r4-quantities-and-units-library","title":"P3045R4: Quantities and units library","text":"
    We have presented the following chapters of our proposal to LEWGI and SG6. We reviewed all the usage examples, discussed composing symbols for derived dimensions and units, and looked into formatting specifications for quantities. We also discussed the minimal scope of the proposal.
     
    We got plenty of feedback on:
     
       
    • the paper itself,
      •  
    • naming of specific entities in the library,
      •  
    • usage examples,
      •  
    • text output and formatting.
      •  
     
    We were also asked to extend the library to provide text output support for quantity points.
     
    You can expect all of those changes to appear in the next release.
    "},{"location":"blog/2024/11/25/report-from-the-wroc%C5%82aw-2024-iso-c-committee-meeting/#p30942r5-stdbasic_fixed_string","title":"P30942R5: std::basic_fixed_string","text":"
    The paper was well received. However, Barry Revzin submitted P3380 paper in September. This started a discussion about the scope of this proposal. Should we:
     
       
    • limit it to just a non-mutating interface (as proposed) and maybe rename it to \u00a0 std::string_literal,
      •  
    • add range slicing interface (as we support composition already),
      •  
    • add some basic mutation interface through non-const operator[],
      •  
    • refactor to fully blown std::inplace_string if P3380 successfully  progresses through EWG.
      •  
    "},{"location":"getting_started/contributing/","title":"Contributing","text":"
    \ud83d\udc4d\ud83c\udf89 First off, thanks for taking the time to contribute! \ud83c\udf89\ud83d\udc4d
    "},{"location":"getting_started/contributing/#mp-units-documentation","title":"mp-units documentation","text":"
    Before contributing, it is highly recommended to familiarize yourself with our official documentation.
     
    This file is also a part of it, and this is why it has non-standard Markdown formatting (which can be seen when reading in a regular Markdown renderer). To benefit from full mkdocs rendering, please switch to the Contributing chapter of our documentation.
    "},{"location":"getting_started/contributing/#where-to-start","title":"Where to start?","text":"
    If you are looking for a good issue to start with, please check the following:
     
       
    • good first issue - issues that   should be pretty simple to implement,
      •  
    • help wanted - issues that typically are   a bit more involved than beginner issues,
      •  
    • high priority - things to fix ASAP   but often of higher complexity.
      •  
    "},{"location":"getting_started/contributing/#gitpod","title":"Gitpod","text":"
    The easiest way to start coding is to jump straight into Gitpod environment. You can either click the button below
     
     
    or prefix any mp-units URL (main branch, other branches, issues, PRs, ...) in your web browser with gitpod.io/# (e.g., https://gitpod.io/#https://github.com/mpusz/mp-units).
     
    The above environment provides you with:
     
       
    • all supported compilers for Linux development and the latest version of build tools like cmake   and conan,
      •  
    • all Conan dependencies preinstalled on the machine,
      •  
    • all documentation generation tools ready to use,
      •  
    • completed prebuilds for all targets (Debug and Release builds for each compiler),
      •  
    • VSCode preconfigured to benefit from all the above.
      •  
    "},{"location":"getting_started/contributing/#building-testing-and-packaging","title":"Building, testing, and packaging","text":"
    Alternatively, please refer to our official docs for download, build, and install instructions with the below changes if you want to set up a development environment on your local machine.
    "},{"location":"getting_started/contributing/#conan-configuration-properties","title":"Conan configuration properties","text":"user.mp-units.build:all 
    Enables compilation of all the source code, including tests and examples. To support this, it requires some additional Conan build dependencies described in Repository directory tree and dependencies. It also runs unit tests during the Conan build (unless tools.build:skip_test configuration property is set to True).
     user.mp-units.build:skip_la 
    If user.mp-units.build:all is enabled, among others, Conan installs the external wg21-linear_algebra dependency and enables the compilation of linear algebra-based tests and usage examples. Such behavior can be disabled with this option.
     user.mp-units.analyze:clang-tidy 
    Enables clang-tidy analysis.
    "},{"location":"getting_started/contributing/#cmake-options-for-mp-units-project-developers","title":"CMake options for mp-units project developers","text":"MP_UNITS_DEV_BUILD_LA 
     2.2.0 \u00b7  ON/OFF (Default: ON)
     
    Enables building code depending on the linear algebra library.
     MP_UNITS_DEV_IWYU 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Enables include-what-you-use analysis.
     MP_UNITS_DEV_CLANG_TIDY 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Enables clang-tidy analysis.
     MP_UNITS_DEV_TIME_TRACE 
     2.5.0 \u00b7  NONE/ALL/MODULES/HEADERS (Default: NONE)
     
    Enables compilation performance data collection with -ftime-trace for clang compilers.
     
    All our unit tests compile only for headers and never for modules. To allow fair comparison, MODULES and HEADERS do not enable the data collection for unit tests. This means that they affect only the core, systems, and examples.
     
    Please use ALL to profile unit tests as well.
    "},{"location":"getting_started/contributing/#building-the-entire-repository","title":"Building the entire repository","text":"
    To build all the mp-units source code (with unit tests and examples), you should:
     
       
    1. Use the CMakeLists.txt from the top-level directory.
      2.  
    2. Run Conan with user.mp-units.build:all = True.
      3.  
     
    git clone https://github.com/mpusz/mp-units.git && cd mp-units\nconan build . -pr <your_conan_profile> -s compiler.cppstd=23 -c user.mp-units.build:all=True -b missing\n
     
    The above will download and install all of the dependencies needed for the development of the library, build all of the source code, and run unit tests.
     
    If you prefer to build the project via CMake rather than Conan, then you should replace the conan build with conan install command and then follow with a regular CMake build and testing:
     
    conan install . -pr <your_conan_profile> -s compiler.cppstd=23 -c user.mp-units.build:all=True -b missing\ncmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target all_verify_interface_header_sets\ncmake --build --preset conan-release --target test\n
     
    Hint
     
    To ensure that we always build all the targets and to save some typing of the Conan commands, we can set the following in the ~/.conan2/global.conf:
     
    user.mp-units.build:all=True\n
    "},{"location":"getting_started/contributing/#packaging","title":"Packaging","text":"
    To test CMake installation and Conan packaging run:
     
    conan create . --user <username> --channel <channel> -pr <your_conan_profile> -s compiler.cppstd=23 \\\n               -c user.mp-units.build:all=True -b missing\n
     
    The above will create a Conan package and run tests provided in ./test_package directory.
     
    In case you would like to upload mp-units package to the Conan server, do the following:
     
    conan upload -r <remote-name> --all mp-units/2.2.0@<user>/<channel>\n
    "},{"location":"getting_started/contributing/#building-documentation","title":"Building documentation","text":"
    We are building our documentation using Material for MkDocs. The easiest way to install all the required dependencies is with pip:
     
    pip install -U mkdocs-material mkdocs-rss-plugin\n
     
    Additionally, a Cairo Graphics library is required by Material for MkDocs. Please follow the official MkDocs documentation to install it.
     
    After that, you can either:
     
       
    •  
      easily start a live server to preview the documentation as you write
       
      mkdocs serve\n
       
      •  
    •  
      build the documentation
       
      mkdocs build\n
       
      •  
    "},{"location":"getting_started/contributing/#generating-api-reference","title":"Generating API reference","text":"
    We need to take a few steps to set up our environment so that we are ready to generate API reference documents.
     
    First, we need to satisfy the requirements described in https://github.com/cplusplus/draft and https://github.com/Eelis/cxxdraft-htmlgen. On the Ubuntu platform, this is equivalent to the following instructions run from the user's home directory:
     
    sudo apt install latexmk texlive-latex-recommended texlive-latex-extra texlive-fonts-recommended lmodern\nsudo apt install haskell-stack graphviz nodejs npm ghc cabal-install\nnpm install split mathjax-full mathjax-node-sre mathjax-node-cli\ncabal update\n
     
    On some platforms, installing mathjax-node-cli through npm does update the system's PATH environment variable resulting in tex2html not found errors. In such cases we need to add the .bin folder to the PATH environment variable manually:
     
    echo \"export PATH=\\\"~/node_modules/.bin:\\$PATH\\\"\" >> ~/.bashrc && source ~/.bashrc\n
     
    Next, we need to clone the following git repositories:
     
       
    • https://github.com/JohelEGP/jegp.cmake_modules
      •  
    • standardese_sources_base branch of https://github.com/JohelEGP/draft
      •  
    • standardese_sources_base branch of https://github.com/JohelEGP/cxxdraft-htmlgen
      •  
     
    For example:
     
    git clone https://github.com/JohelEGP/jegp.cmake_modules.git --depth=1\ngit clone https://github.com/JohelEGP/draft.git --branch=standardese_sources_base --depth=1\ngit clone https://github.com/JohelEGP/cxxdraft-htmlgen.git --branch=standardese_sources_base --depth=1\n
     
    Now, we are ready to start building our API reference. First, we need to configure CMake with the following:
     
    cmake -S docs/api_reference/src -B build/docs/api_reference \\\n      -DCMAKE_MODULE_PATH=\"<path to gh:JohelEGP/jegp.cmake_modules>/modules\" \\\n\u00a0 \u00a0 \u00a0 -DJEGP_STANDARDESE_SOURCES_GIT_REPOSITORY=\"<path to gh:JohelEGP/draft>\" \\\n      -DJEGP_CXXDRAFT_HTMLGEN_GIT_REPOSITORY=\"<path to gh:JohelEGP/cxxdraft-htmlgen>\"\n
     
    Then we need to build the docs with CMake:
     
    cmake --build build/docs/api_reference\n
     
    In the end, we need to move the generated documentation to the docs/api_reference/gen subdirectory:
     
    mv build/docs/api_reference/mp-units.html docs/api_reference/gen\n
     
    or just link the entire directory:
     
    ln -sf ../../build/docs/api_reference/mp-units.html docs/api_reference/gen\n
    "},{"location":"getting_started/contributing/#before-committing-git-changes","title":"Before committing git changes","text":"
    There are a few steps recommended to check before committing and pushing your changes to the git repository.
    "},{"location":"getting_started/contributing/#naming-conventions","title":"Naming conventions","text":"
    Here are the main rules for naming things in this repo:
     
       
    • types, functions, variables use standard_case,
      •  
    • template parameters use PascalCase,
      •  
    • C++ concept names, for now, use PascalCase, but we plan to change it  (see GitHub Issue #93 for more details).
      •  
    "},{"location":"getting_started/contributing/#unified-code-formatting","title":"Unified code formatting","text":"
    A formatting standard is enforced with the pre-commit script. Before committing your changes, please do the following:
     
    pip install -U pre-commit\npre-commit run --all-files\n
     
    This will run:
     
       
    • clang-format for code formatting with the .clang-format file provided in the repo,
      •  
    • cmake-format to format the CMake files,
      •  
    • some other checks (e.g., python script checkers, whitespaces, etc.).
      •  
     
    The script will run on all the files in the repo and will apply the changes in place when needed. After the script is done, please make sure to review and stage all those changes for the git commit.
    "},{"location":"getting_started/contributing/#backward-compatibility","title":"Backward compatibility","text":"
    Before submission, please remember to check if the code compiles fine on the supported compilers. The CI will check it anyway, but it is good to check at least some of the configurations before pushing changes. Especially older compilers can be tricky as those do not have full C++20 conformance. The official list of supported compilers can always be found in the C++ compiler support (API/ABI) chapter of our documentation.
    "},{"location":"getting_started/cpp_compiler_support/","title":"C++ compiler support (API/ABI)","text":"
    Info
     
    mp-units library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
     
    Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality. Newer features can be hidden behind some preprocessor macros providing a backward-compatible way to use them.
     
    The table below provides the minimum compiler version required to compile the code using a specific C++ feature:
     C++ Feature C++ version gcc clang apple-clang MSVC Minimum support 20 12+ 16+ && !19 15+ 194+  std::format 20 13+ 17+ 16+ 194+ C++ modules 20 None 17+ None None import std; 23 None 18+ None None Explicit this parameter 23 14+ 18+ None None clang-19 unfixable bug 
    Unfortunately, clang-19 does not build mp-units because of an unfixable bug in the compiler.
     MSVC bugs 
    MSVC still has a poor C++20 conformance. We had to make many workarounds to our codebase to make it compile on this compiler. Usage of such nasty preprocessor macros degrade the readability and maintainability of our code. This is why we've applied those patches to the main library code but not to unit tests and examples. Those still do not compile on MSVC.
     
    Here is a list of the most important MSVC bugs:
     
       
    • Syntax error when using non-type template parameters in templated class member function
      •  
    • Type always preferred over value when using qualified identifiers
      •  
     
    Please upvote them so they get a higher fixing priority at Microsoft.
     
    Important
     
    Enabling/disabling features listed above may influence the API of the library and the ABI of the customers' projects.
    "},{"location":"getting_started/cpp_compiler_support/#stdformat","title":"std::format","text":"
       
    • Provides powerful text formatting capabilities   for C++.
      •  
    • An alternative fmtlib library can be used instead if
         
      • the C++ language feature is not supported,
        •  
      • the customer's project did not switch to std::format yet (even when the compiler   supports it).
        •  
       
      •  
    • To write code with wide compatibility   a dedicated macro may be used.
      •  
    • Tested with __cpp_lib_format feature test macro.
      •  
    • Related build options:
         
      • Conan: std_format
        •  
      • CMake: MP_UNITS_API_STD_FORMAT
        •  
       
      •  
    "},{"location":"getting_started/cpp_compiler_support/#c-modules","title":"C++ modules","text":"
       
    • Provide new way to share declarations and definitions across translation units.
      •  
    • If used, the library will distribute both \"old-style\" headers and module interface units
         
      • associated with the same CMake targets.
        •  
       
      •  
    • Even with full compiler support, a user may still decide to not pay for C++ modules compilation   if they are not needed by the customer's project.
      •  
    • Feature test macro is not used for testing here because even if the compiler does not support   the entire C++ feature (e.g. header units), it is enough to build modules for this library.
      •  
    • Related build options:
         
      • Conan: cxx_modules
        •  
      • CMake: MP_UNITS_BUILD_CXX_MODULES
        •  
       
      •  
     
    Note
     
    More requirements for C++ modules support can be found in the CMake's documentation.
    "},{"location":"getting_started/cpp_compiler_support/#import-std","title":"import std;","text":"
       
    • If enabled, the library will obtain all the definitions from the std namespace via   import std; instead of the \"old-style\" header includes.
      •  
    • Related build options:
         
      • Conan: import_std
        •  
      • CMake: CMAKE_CXX_MODULE_STD
        •  
       
      •  
    "},{"location":"getting_started/cpp_compiler_support/#explicit-this-parameter","title":"Explicit this parameter","text":"
       
    • This feature removes the need for the usage of the CRTP idiom in the   quantity_spec definitions.
      •  
    • To write code with wide compatibility   a dedicated macro may be used.
      •  
    • Tested with __cpp_explicit_this_parameter feature test macro.
      •  
    • Related build options:
         
      • Conan: no_crtp
        •  
      • CMake: MP_UNITS_API_NO_CRTP
        •  
       
      •  
    "},{"location":"getting_started/faq/","title":"Frequently Asked Questions","text":""},{"location":"getting_started/faq/#why-do-we-spell-metre-instead-of-meter","title":"Why do we spell metre instead of meter?","text":"
    This is how the BIPM defines it in the SI Brochure (British English spelling by default).
    "},{"location":"getting_started/faq/#why-dont-we-use-udls-to-create-quantities","title":"Why don't we use UDLs to create quantities?","text":"
    Many reasons make UDLs a poor choice for a physical units library:
     
       
    1. UDLs work only with literals (compile-time known values). Our observation is that besides    the unit tests, there are only a few compile-time known quantity values used in the production    code. Please note that for physical constants, we recommend using    Faster-than-lightspeed Constants.
      2.  
    2.  
      Typical implementations of UDLs tend to always use the widest representation type available.    In the case of std::chrono::duration, the following is true:
       
      using namespace std::chrono_literals;\nauto d1 = 42s;\nauto d2 = 42.s;\nstatic_assert(std::is_same_v<decltype(d1)::rep, std::int64_t>);\nstatic_assert(std::is_same_v<decltype(d2)::rep, long double>);\n
       
      3.  
     
    When such UDL is intermixed in arithmetics with any quantity type of a shorter representation    type, it will always expand it to the longest one. In other words, such long type spreads until    all types use it everywhere.
     
       
    1.  
      While increasing the coverage for the library, we learned that many unit symbols conflict with    built-in types or numeric extensions. A few of those are: F (farad), J (joule), W (watt),    K (kelvin), d (day), l or L (litre), erg, ergps. Usage of the _ prefix would make    it work for mp-units, but in case the library is standardized, those naming collisions would    be a big issue. This is why we came up with the _q_ prefix that would become q_ after    standardization (e.g., 42q_s), which is not that nice anymore.
       
      2.  
    2.  
      UDLs with the same identifiers defined in different namespace can't be disambiguated in the C++    language. If both SI and CGS systems define _q_s UDL for a second unit, then it would not be possible    to specify which one to use in case both namespaces are \"imported\" with using directives.
       
      3.  
    3.  
      Another bad property of UDLs is that they do not compose. A coherent unit of angular momentum would    have a UDL specified as _q_kg_m2_per_s. Now imagine that we want to make every possible user happy.    How many variations of that unit would we predefine for differently scaled versions of all unit    ingredients?
       
      4.  
    4.  
      UDLs are also really expensive to define and specify. Typically, for each unit, we need two    definitions. One for integral and another one for floating-point representation. Before the    V2 framework, the coherent unit of angular momentum was defined as:
       
      constexpr auto operator\"\" _q_kg_m2_per_s(unsigned long long l)\n{\n  gsl_Expects(std::in_range<std::int64_t>(l));\n  return angular_momentum<kilogram_metre_sq_per_second, std::int64_t>(static_cast<std::int64_t>(l));\n}\n\nconstexpr auto operator\"\" _q_kg_m2_per_s(long double l)\n{\n  return angular_momentum<kilogram_metre_sq_per_second, long double>(l);\n}\n
       
      5.  
    "},{"location":"getting_started/faq/#why-cant-i-create-a-quantity-by-passing-a-number-to-a-constructor","title":"Why can't I create a quantity by passing a number to a constructor?","text":"
    A quantity class template in the mp-units library has no publicly available constructor taking a raw value. Such support is provided by the std::chrono::duration and was pointed out to us as a red flag safety issue by a few parties already.
     
    Consider the following structure and a code using it:
     
    struct X {\n  std::vector<std::chrono::milliseconds> vec;\n  // ...\n};\n
     
    X x;\nx.vec.emplace_back(42);\n
     
    Everything works fine for years until, at some point, someone changes the structure to:
     
    struct X {\n  std::vector<std::chrono::microseconds> vec;\n  // ...\n};\n
     
    The code continues to compile just fine, but all the calculations are off now. This is why we decided to not follow this path.
     
    In the mp-units library, both a number and a unit have to always be explicitly provided in order to form a quantity.
     
    Note
     
    The same applies to the construction of quantity_point using an explicit point origin. To prevent similar safety issues during maintenance, the initialization always requires providing both a quantity and a PointOrigin that we use as a reference point.
    "},{"location":"getting_started/faq/#why-a-dimensionless-quantity-is-not-just-a-fundamental-arithmetic-type","title":"Why a dimensionless quantity is not just a fundamental arithmetic type?","text":"
    In the initial design of this library, the resulting type of division of two quantities was their common representation type:
     
    static_assert(std::is_same_v<decltype(10 * km / (5 * km)), int>);\n
     
    First of all, this was consistent with std::chrono::duration behavior. Additional reasoning behind it was not providing a false impression of a strong quantity type for something that looks and feels like a regular number. Also, all of the mathematic and trigonometric functions were working fine out of the box with such representation types, so we did not have to rewrite sin(), cos(), exp(), and others.
     
    However, the feedback we got from the production usage was that such an approach is really bad for generic programming. It is hard to handle the result of the two quantities' division (or multiplication) as it might be either a quantity or a fundamental type. If we want to raise such a result to some power, we must use units::pow or std::pow depending on the resulting type. Those are only a few issues related to such an approach.
     
    Moreover, suppose we divide quantities of the same dimension but with units of significantly different magnitudes. In that case, we may end up with a really small or a huge floating-point value, which may result in losing lots of precision. Returning a dimensionless quantity from such cases allows us to benefit from all the properties of scaled units and is consistent with the rest of the library.
     
    Note
     
    More information on the current design can be found in the Dimensionless Quantities chapter.
    "},{"location":"getting_started/faq/#why-derived-units-order-is-not-preserved-from-the-multiplication","title":"Why derived units order is not preserved from the multiplication?","text":"
    It might be surprising, but the quantities and units multiplication order does not impact the order of components in the derived unit. Let's try the following example:
     
    std::println(\"{}\", 42 * kW * h);\nconstexpr auto kWh = kW * h;\nstd::println(\"{}\", 42 * kWh);\n
     
    The above prints:
     
    42 h kW\n42 h kW\n
     
    Some users could expect to see 42 kWh or 42 kW h in the output. It is not the case and for a very good reason. As stated in Simplifying the resulting symbolic expressions, to be able to reason about and simplify units, the library needs to order them in an appropriate order.
     
    Maybe this default order could be improved a bit, but according to international standards, there is no generic ordering rule. Various quantities use different, often domain-specific, ordering of derived unit components.
     
    Let's see what SI says here:
     Derived quantity Symbol Derived unit expressed in terms of base units electric field strength V m\u207b\u00b9 kg m s\u207b\u00b3 A\u207b\u00b9 electric charge density C m\u207b\u00b3 A s m\u207b\u00b3 exposure (x- and \u03b3-rays) C kg\u207b\u00b9 A s kg\u207b\u00b9 
    However, there is a workaround. A user can define its own named unit for a derived unit and provide the custom symbol text that suits the project's requirements. For example, the above case could be addressed with:
     
    inline constexpr struct kilowatt_hour final : named_unit<\"kWh\", kW * h> {} kilowatt_hour;\ninline constexpr auto kWh = kilowatt_hour;\n
     
    With the above, we can refactor the above code to:
     
    std::println(\"{}\", 42 * kWh);\nstd::println(\"{}\", (42 * kW * h).in(kWh));\n
     
    Both lines will produce an expected \"42 kWh\" unit in the output.
     
    Important
     
    Please note that this makes the entire \"kWh\" a single, indivisible entity that is not subject to simplification rules. This means that 42 * kWh / (2 * h) will result with 21 kWh/h rather than 21 kW. To get the latter, the user needs to explicitly provide a new derived unit:
     
    std::println(\"{}\", (42 * kWh / (2 * h)).in(kW));\n
    "},{"location":"getting_started/faq/#why-do-the-identifiers-for-concepts-in-the-library-use-camelcase","title":"Why do the identifiers for concepts in the library use CamelCase?","text":"
    Initially, C++20 was meant to use CamelCase for all the concept identifiers. All the concepts from the std::ranges library were merged with such names into the standard document draft. Frustratingly, CamelCase concepts got dropped from the C++ standard at the last moment before releasing C++20. Now, we are facing the predictable consequences of running out of names.
     
    As long as some concepts in the library could be easily named with a standard_case there are some that are hard to distinguish from the corresponding type names, such as Quantity, QuantityPoint, QuantitySpec, or Reference. This is why we decided to use CamelCase consistently for all the concept identifiers to make it clear when we are talking about a type or concept identifier.
     
    However, we are aware that this might be a temporary solution. In case the library gets standardized, we can expect the ISO C++ Committee to bikeshed/rename all of the concept identifiers to a standard_case, even if it will result in a harder to understand code.
     
    Note
     
    In case you have a good idea of how to rename existing concepts to the standard_case, please let us know in the associated GitHub Issue.
    "},{"location":"getting_started/faq/#why-utf-8-quantity-symbols-are-used-by-default-instead-of-portable-characters","title":"Why UTF-8 quantity symbols are used by default instead of portable characters?","text":"
    Both C++ and ISO 80000 are standardized by the ISO. ISO 80000 and the SI standards specify UTF-8 symbols as the official unit names for some quantities (e.g. \u03a9 symbol for the resistance quantity). As the mp-units library will be proposed for standardization as a part of the C++ Standard Library we have to obey the rules and be consistent with ISO specifications.
     
    Note
     
    We do understand engineering reality and the constraints of some environments. This is why the library has the option of Portable Quantity Symbols.
    "},{"location":"getting_started/faq/#why-dont-we-have-cmake-options-to-disable-the-building-of-tests-and-examples","title":"Why don't we have CMake options to disable the building of tests and examples?","text":"
    Over time, many people provided PRs proposing adding options to build tests and examples conditionally. Here are a few examples:
     
       
    • Add CMake options for disabling docs, examples and tests
      •  
    • build: add options to disable part of the build
      •  
    • CMake Refactoring and Option Cleanup
      •  
     
    We admit this is a common practice in the industry, but we also believe this is a bad pattern.
     
    First, the only need for such options comes when a user wants to use add_subdirectory() in CMake to handle dependencies. Such an approach does not scale and should be discouraged. There is little use for such a practice in times when we have dedicated package managers like Conan.
     
    The second thing is that our observation is that many people are fixed on disabling \"unneeded\" subdirectories from compilation, but they do not see or address the biggest issue, which is polluting user's build environment with our development-specific settings. Propagating our restrictive compilation flags to user's project is not the best idea as it might cause a lot of harm if this project stops to compile because of that.
     
    Last but not least, not having those options is on purpose. Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
     
    This is why our projects have two entry points:
     
       
    • ./CMakeLists.txt is to be used by projects developers to build ALL the project code with really   restrictive compilation flags,
      •  
    • ./src/CMakeLists.txt contains only a pure library definition and should be used by the customers   that prefer to use CMake's add_subdirectory() to handle the dependencies.
      •  
     
    Note
     
    For more details on this please refer to the CMake + Conan: 3 Years Later - Mateusz Pusz lecture that Mateusz Pusz provided at the C++Now 2021 conference.
    "},{"location":"getting_started/installation_and_usage/","title":"Installation And Usage","text":"
    This chapter provides all the necessary information to obtain mp-units and build the user's source code using it.
    "},{"location":"getting_started/installation_and_usage/#obtaining-dependencies","title":"Obtaining dependencies","text":"
    This library assumes that most of the dependencies will be provided by the Conan Package Manager. If you want to obtain required dependencies by other means, some modifications to the library's CMake files might be needed.
     Conan quick intro 
    In case you are not familiar with Conan, to install it (or upgrade) just do:
     
    pip install -U conan\n
     
    After that, you might need to add a custom profile file for your development environment in ~/.conan2/profiles directory. An example profile can look as follows:
     ~/.conan2/profiles/gcc12
    [settings]\narch=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.cppstd=20\ncompiler.libcxx=libstdc++11\ncompiler.version=14\nos=Linux\n\n[conf]\ntools.build:compiler_executables={\"c\": \"gcc-14\", \"cpp\": \"g++-14\"}\n
     
    Setting the language version
     
    Please note that the mp-units library requires at least C++20 to be set in a Conan profile or forced via the Conan command line. If we do the former, we will not need to provide -s compiler.cppstd=20 every time we run a Conan command line (as provided in the command line instructions below).
     
    Using Ninja as a CMake generator for Conan
     
    It is highly recommended to set Ninja as a CMake generator for Conan. To do so, we could create a ~/.conan2/global.conf file that will set tools.cmake.cmaketoolchain:generator to one of the Ninja generators. For example:
     ~/.conan2/global.conf
    tools.cmake.cmaketoolchain:generator=\"Ninja Multi-Config\"\n
     
    Separate build folders for different configurations
     
    ~/.conan2/global.conf file may also set tools.cmake.cmake_layout:build_folder_vars which makes working with several compilers or build configurations easier. For example, the below line will force Conan to generate separate CMake presets and folders for each compiler and C++ standard version:
     ~/.conan2/global.conf
    tools.cmake.cmake_layout:build_folder_vars=[\"settings.compiler\", \"settings.compiler.version\", \"settings.compiler.cppstd\"]\n
     
    In such a case, we will need to use a configuration-specific preset name in the Conan instructions provided below rather than just conan-default and conan-release (e.g., conan-gcc-13-23 and conan-gcc-13-23-release)
     CMake with presets support 
    It is recommended to use at least CMake 3.23 to build this project to benefit from CMake Presets generated by Conan. All build instructions below assume that you have such support. If not, your CMake invocations have to be replaced with something like:
     
    mkdir build && cd build\ncmake .. -G \"Ninja Multi-Config\" -DCMAKE_TOOLCHAIN_FILE=<path_to_generators_dir>/conan_toolchain.cmake\ncmake --build . --config Release\n
     
    Tip
     
    In case you can't use CMake 3.23 but you have access to CMake 3.20 or later, you can append -c tools.cmake.cmaketoolchain.presets:max_schema_version=2 to the conan install command which will force Conan to use an older version of the CMake Presets schema.
    "},{"location":"getting_started/installation_and_usage/#build-options","title":"Build options","text":"
    Note
     
    Most of the below options are related to the C++ language features available in the compilers. Please refer to the C++ compiler support chapter to learn more about which C++ features are required for each option and which compilers support them.
    "},{"location":"getting_started/installation_and_usage/#conan-options","title":"Conan options","text":"cxx_modules 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Configures CMake to add C++ modules to the list of default targets.
     import_std 
     2.3.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Enables import std; usage.
     std_format 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
     no_crtp 
     2.2.0 \u00b7  True/False (Default: automatically determined from settings)
     
    Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
     contracts 
     2.2.0 \u00b7  none/gsl-lite/ms-gsl (Default: see below)
     
    Enables checking of preconditions and additional assertions in the code.
     
    If the automatically determined default for import_std is True, then the contracts option is set to none by default. gsl-lite otherwise.
     freestanding 
     2.2.0 \u00b7  True/False (Default: False)
     
    Configures the library in the freestanding mode. When enabled, the library's source code will build with the compiler's -ffreestanding compilation option without any issues.
     CMake options to set when Conan is not being used"},{"location":"getting_started/installation_and_usage/#cmake-options","title":"CMake options","text":"
    Conan will automatically set all the below CMake options based on its configuration (described above). Manual setting of the below CMake options is only needed when Conan is not being used.
     MP_UNITS_BUILD_AS_SYSTEM_HEADERS 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Exports library as system headers.
     MP_UNITS_BUILD_CXX_MODULES 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Adds C++ modules to the list of default targets.
     MP_UNITS_API_STD_FORMAT 
     2.2.0 \u00b7  ON/OFF (Default: automatically determined)
     
    Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
     MP_UNITS_API_NO_CRTP 
     2.2.0 \u00b7  ON/OFF (Default: automatically determined)
     
    Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
     MP_UNITS_API_CONTRACTS 
     2.2.0 \u00b7  NONE/GSL-LITE/MS-GSL (Default: GSL-LITE)
     
    Enables checking of preconditions and additional asserts in the code.
     MP_UNITS_API_FREESTANDING 
     2.2.0 \u00b7  ON/OFF (Default: OFF)
     
    Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
    "},{"location":"getting_started/installation_and_usage/#installation-and-reuse","title":"Installation and reuse","text":"
    There are many different ways of installing/reusing mp-units in your project. Below we mention only a few of many options possible.
     
    Important: Prefer using Conan if possible
     
    The easiest and most recommended way to obtain mp-units is with the Conan package manager. See Conan + CMake (release) for a detailed instruction.
    "},{"location":"getting_started/installation_and_usage/#conan-cmake-release","title":"Conan + CMake (release)","text":"
    Tip
     
    If you are new to the Conan package manager you may want to read Obtaining Dependencies and refer to the Consuming packages chapter of the official Conan documentation for more information.
     
    mp-units releases are hosted on Conan-Center. The following steps may be performed to obtain an official library release:
     
       
    1.  
      Create Conan configuration file (either conanfile.txt or conanfile.py) in your    project's top-level directory and add mp-units as a dependency of your project.    For example, the simplest file may look as follows:
       conanfile.txtconanfile.py 
      [requires]\nmp-units/2.4.0\n\n[options]\n# The below mp-units options are set to defaults by Conan.\n# Uncomment and set to an explicit value to override the defaults.\n#\n# mp-units*:cxx_modules=True\n# mp-units*:import_std=False\n# mp-units*:std_format=True\n# mp-units*:no_crtp=True\n# mp-units*:contracts=gsl-lite\n# mp-units*:freestanding=False\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\n
       
      from conan import ConanFile\nfrom conan.tools.build import can_run\nfrom conan.tools.cmake import CMake, cmake_layout\n\nclass MPUnitsTestConan(ConanFile):\n    settings = \"os\", \"arch\", \"compiler\", \"build_type\"\n    generators = \"CMakeDeps\", \"CMakeToolchain\"\n\n    def requirements(self):\n        self.requires(\n            \"mp-units/2.4.0\",\n            options={\n                # The below mp-units options are set to defaults by Conan.\n                # Uncomment and set to an explicit value to override the defaults.\n                #\n                # \"cxx_modules\": False,\n                # \"import_std\": False,\n                # \"std_format\": True,\n                # \"no_crtp\": True,\n                # \"contracts\": \"gsl-lite\",\n                # \"freestanding\": False,\n            },\n        )\n\n    def layout(self):\n        cmake_layout(self)\n\n    def build(self):\n        cmake = CMake(self)\n        cmake.configure()\n        cmake.build()\n        if can_run(self):\n            cmake.ctest(cli_args=[\"--output-on-failure\"])\n
       
      2.  
    2.  
      Import mp-units and its dependencies definitions with find_package:
       
      find_package(mp-units REQUIRED)\n
       
      3.  
    3.  
      Link your CMake targets with mp-units:
       
      target_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\n
       
      4.  
    4.  
      Download, build, and install Conan dependencies before running the CMake configuration step:
       conanfile.txt or conanfile.pyconanfile.py only 
      conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\ncmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target test\n
       
      conan build . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\n
       
      5.  
    "},{"location":"getting_started/installation_and_usage/#conan-cmake-live-at-head","title":"Conan + CMake (Live At Head)","text":"
    This chapter describes the procedure to Live At Head, which means using the latest stable version of mp-units all the time.
     
    Note
     
    Please note that even though the Conan packages that you will be using are generated ONLY for builds that are considered stable (passed our CI tests), some minor regressions may happen (CI and C++ build environments are not perfect yet). Also, please expect that the library interface might, and probably will, change occasionally. Even though we do our best, such changes might not be reflected in the project's documentation right away.
     
    The procedure is similar to the one described in Conan + CMake (release) with the following differences:
     
       
    1.  
      Before starting the previous procedure, add mp-units remote to your Conan configuration:
       
      conan remote add conan-mpusz https://mpusz.jfrog.io/artifactory/api/conan/conan-oss\n
       
      2.  
    2.  
      In your Conan configuration file, provide the package identifier of the mpusz/testing stream:
       conanfile.txtconanfile.py 
      [requires]\nmp-units/2.5.0@mpusz/testing\n\n[options]\n# The below mp-units options are set to defaults by Conan.\n# Uncomment and set to an explicit value to override the defaults.\n#\n# mp-units*:cxx_modules=True\n# mp-units*:import_std=False\n# mp-units*:std_format=True\n# mp-units*:no_crtp=True\n# mp-units*:contracts=gsl-lite\n# mp-units*:freestanding=False\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\n
       
      from conan import ConanFile\nfrom conan.tools.build import can_run\nfrom conan.tools.cmake import CMake, cmake_layout\n\nclass MPUnitsTestConan(ConanFile):\n    settings = \"os\", \"arch\", \"compiler\", \"build_type\"\n    generators = \"CMakeDeps\", \"CMakeToolchain\"\n\n    def requirements(self):\n        self.requires(\n            \"mp-units/2.5.0@mpusz/testing\",\n            options={\n                # The below mp-units options are set to defaults by Conan.\n                # Uncomment and set to an explicit value to override the defaults.\n                #\n                # \"cxx_modules\": False,\n                # \"import_std\": False,\n                # \"std_format\": True,\n                # \"no_crtp\": True,\n                # \"contracts\": \"gsl-lite\",\n                # \"freestanding\": False,\n            },\n        )\n\n    def layout(self):\n        cmake_layout(self)\n\n    def build(self):\n        cmake = CMake(self)\n        cmake.configure()\n        cmake.build()\n        if can_run(self):\n            cmake.ctest(cli_args=[\"--output-on-failure\"])\n
       
      Tip
       
      The identifiers of the latest packages can always be found in the project's README file or on the project's Artifactory.
       
      3.  
    3.  
      Force Conan to check for updated recipes with -u:
       
      conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing -u\n
       
      4.  
     Alternative installation scenarios"},{"location":"getting_started/installation_and_usage/#copy","title":"Copy","text":"
    As mp-units is a C++ header-only library you can simply copy all needed src/*/include subdirectories to your source tree.
     
    Note
     
    In such a case, you are on your own to ensure all the dependencies are installed and their header files can be located during the build. Please also note that some compiler-specific flags are needed to make the code compile without issues.
    "},{"location":"getting_started/installation_and_usage/#copy-cmake","title":"Copy + CMake","text":"
    If you copy the mp-units library source code from the project's ./src directory (not the entire repo from its root), you can reuse CMake targets defined by the library. To do so, you should use CMakeLists.txt file from the ./src directory:
     
    add_subdirectory(<path_to_mp_units_lib_folder>)\n# ...\ntarget_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\n
     
    Note
     
    You are still on your own to make sure all the dependencies are installed and their header and CMake configuration files can be located during the build.
     
    Important: Library users should not use the top-level CMake file
     
    Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. ./src/CMakeLists.txt contains only a pure library definition and should be used by the customers that prefer to use CMake's add_subdirectory() to handle the dependencies.
     
    To learn more about the rationale, please check our FAQ.
    "},{"location":"getting_started/installation_and_usage/#install","title":"Install","text":"
    If you don't want to use Conan in your project and just want to install the mp-units library on your file system, and use find_package(mp-units) from another repository to find it; it is enough to perform the following steps:
     
    conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\nmv CMakeUserPresets.json src\ncd src\ncmake --preset conan-default -DCMAKE_INSTALL_PREFIX=<your_installation_path>\ncmake --build --preset conan-release --target install\n
    "},{"location":"getting_started/introduction/","title":"Introduction","text":"
    mp-units is a Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation. The initial versions of the library were inspired by the std::chrono::duration but with each release, the interfaces diverged from the original to provide a better user experience.
     
    Info
     
    A brief introduction to the library's interfaces and the rationale for changes in version 2.0 of mp-units were provided in detail by Mateusz Pusz in the \"The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design\" talk at the C++ on Sea 2023 conference.
    "},{"location":"getting_started/introduction/#open-source","title":"Open Source","text":"
    mp-units is Free and Open Source, with a permissive MIT license. Check out the source code and issue tracking (for questions and support, reporting bugs, suggesting feature requests and improvements) at https://github.com/mpusz/mp-units.
    "},{"location":"getting_started/introduction/#with-the-users-experience-in-mind","title":"With the User's Experience in Mind","text":"
    Most of the critical design decisions in the library are dictated by the requirement of providing the best user experience possible. Other C++ physical units libraries are \"famous\" for their enormous and hard-to-understand error messages (one line of the error log often does not fit on one slide). The ultimate goal of mp-units is to improve this and make compile-time errors and debugging as easy and user-friendly as possible.
     
    To achieve this goal, several techniques are applied:
     
       
    • usage of C++20 concepts that improve   compile-times and the readability of error messages when compared to the traditional template   metaprogramming with SFINAE,
      •  
    • usage of strong types for framework entities (instead of type aliases),
      •  
    • usage of symbolic expressions to improve the readability of generated types,
      •  
    • limiting the number of template arguments to the bare minimum.
      •  
     
    Important: It is all about errors
     
    In many generic C++ libraries, compile-time errors do not happen often. It is hard to break std::string or std::vector in a way that won't compile with a huge error log. Physical quantities and units libraries are different. Generation of compile-time errors is the main reason to use such a library.
    "},{"location":"getting_started/introduction/#key-features","title":"Key Features","text":"Feature Description Safety - The affine space strong types (quantity and quantity_point)- Compile-time checked conversions of quantities and units- Unique support for many quantities of the same kind- Type-safe equations on scalar, vector, and tensor quantities and their units- Value-preserving conversions Performance - All the compile-time logic implemented as immediate (consteval) functions- As fast or even faster than working with fundamental types- No space size overhead needed to implement high-level abstractions Great User Experience - Optimized for readable compilation errors and great debugging experience- Efficient and composable way to specify a unit of choice- Value-based dimension, unit, and quantity equations Feature Rich - Systems of Quantities- Systems of Units- Scalar, vector, and tensor quantities- The affine space- Different models of the universe (e.g. natural units systems)- Strong dimensionless quantities- Strong angular system- Supports any unit's magnitude (huge, small, floating-point)- Faster-than-lightspeed constants- Highly adjustable text-output formatting Easy to Extend - Each entity can be defined with a single line of code- User can easily extend the systems with custom dimensions, quantities, and units Low Standardization Cost - Small number of predefined entities thanks to their composability- No external dependencies (assuming full C++20 support)- No macros in the user interface (besides portability and standard-compliance issues)- Possibility to be standardized as a freestanding part of the C++ Standard Library"},{"location":"getting_started/look_and_feel/","title":"Look and Feel","text":"
    Here is a small example of operations possible on scalar quantities:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n
     
    Try it on Compiler Explorer
     
    This library requires some C++20 features (concepts and constraints, classes as NTTP, ...). Thanks to them, a user gets a powerful but still easy-to-use interface where all unit conversions and dimensional analysis can be performed without sacrificing accuracy. Please see the below example for a quick preview of basic library features:
     C++ modulesHeader files 
    #include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n\n  constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n\n  std::cout << v1 << '\\n';                                        // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';  // ***70 mi/h\n  std::cout << std::format(\"{:*^10}\\n\", v3);                      // *110 km/h*\n  std::println(\"{:%N in %U of %D}\", v4);                          // 70 in mi/h of LT\u207b\u00b9\n  std::println(\"{::N[.2f]}\", v5);                                 // 30.56 m/s\n  std::println(\"{::N[.2f]U[dn]}\", v6);                            // 31.29 m\u22c5s\u207b\u00b9\n  std::println(\"{:%N}\", v7);                                      // 31\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n                                                QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n\n  constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n\n  std::cout << v1 << '\\n';                                        // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';  // ***70 mi/h\n  std::cout << std::format(\"{:*^10}\\n\", v3);                      // *110 km/h*\n  std::println(\"{:%N in %U of %D}\", v4);                          // 70 in mi/h of LT\u207b\u00b9\n  std::println(\"{::N[.2f]}\", v5);                                 // 30.56 m/s\n  std::println(\"{::N[.2f]U[dn]}\", v6);                            // 31.29 m\u22c5s\u207b\u00b9\n  std::println(\"{:%N}\", v7);                                      // 31\n}\n
     
    Try it on Compiler Explorer
     
    Note
     
    More code examples can be found in the Examples chapter.
    "},{"location":"getting_started/project_structure/","title":"Project structure","text":"
    This chapter provides a high level overview of the project to make it easier to navigate, build, and use.
    "},{"location":"getting_started/project_structure/#cmake-projects-and-dependencies","title":"CMake projects and dependencies","text":"
    The GitHub repository contains three independent CMake-based projects:
     
       
    •  
      ./src
       
         
      • header-only project containing whole mp-units library
        •  
      • ./src/CMakeLists.txt file is intended as an entry point for library users
        •  
      •  
        in case this library becomes part of the C++ standard, it will have no external dependencies   but until then, it depends on the following:
         
           
        • gsl-lite or ms-gsl   to verify runtime contracts (if contract checking is enabled),
          •  
        • {fmt} to provide text formatting of quantities   (if std::format is not supported yet on a specific compiler).
          •  
         
        •  
       
      •  
    •  
      .
       
         
      • project used as an entry point for library development and CI/CD
        •  
      • it wraps ./src project together with usage examples and tests
        •  
      •  
        additionally to the dependencies of ./src project, it uses:
         
           
        • Catch2 library as a unit tests framework,
          •  
        • linear algebra   library based on proposal P1385 used in some examples   and tests.
          •  
         
        •  
       
      •  
    •  
      ./test_package
       
         
      • CMake library installation and Conan package verification.
        •  
       
      •  
     
    Important: Library users should not use the top-level CMake file
     
    Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
     
    This is why our projects have two entry points:
     
       
    • ./CMakeLists.txt is to be used by projects developers to build ALL the project code   with really restrictive compilation flags,
      •  
    • ./src/CMakeLists.txt contains only a pure library definition and should be used by the   customers that prefer to use CMake's   add_subdirectory() to   handle the dependencies.
      •  
     
    To learn more about the rationale, please check our FAQ.
    "},{"location":"getting_started/project_structure/#modules","title":"Modules","text":"
    The mp-units library provides the following C++ modules:
     
    flowchart TD\n    mp_units --- mp_units.systems --- mp_units.core
     C++ Module CMake Target Contents mp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems 
    Note
     
    C++ modules are provided within the package only when:
     
       
    • cxx_modules Conan option is set to True,
      •  
    • MP_UNITS_BUILD_CXX_MODULES CMake option is set to ON.
      •  
    "},{"location":"getting_started/project_structure/#header-files","title":"Header files","text":"
    All of the project's header files can be found in the mp-units/... subdirectory.
    "},{"location":"getting_started/project_structure/#core-library","title":"Core library","text":"
       
    • mp-units/framework.h contains the entire library's framework definitions,
      •  
    • mp-units/concepts.h exposes only the library's concepts for generic code needs,
      •  
    • mp-units/format.h provides text formatting support,
      •  
    • mp-units/ostream.h enables streaming of the library's objects to the text output,
      •  
    • mp-units/math.h provides overloads of common math functions for quantities,
      •  
    • mp-units/random.h provides C++ pseudo-random number generators for quantities,
      •  
    • mp-units/compat_macros.h provides macros for wide compatibility.
      •  
     More details 
    More detailed header files can be found in subfolders which typically should not be included by the end users:
     
       
    • mp-units/framework/... provides all the public interfaces of the framework,
      •  
    • mp-units/bits/... provides private implementation details only (no public definitions),
      •  
    • mp-units/ext/... contains external dependencies that at some point in the future should   be replaced with C++ standard library facilities.
      •  
    "},{"location":"getting_started/project_structure/#systems-and-associated-utilities","title":"Systems and associated utilities","text":"
    The systems definitions can be found in the mp-units/systems/... subdirectory:
    "},{"location":"getting_started/project_structure/#systems-of-quantities","title":"Systems of quantities","text":"
       
    • mp-units/systems/isq.h provides   International System of Quantities (ISQ)   definitions,
      •  
    • mp-units/systems/isq_angle.h provides a modification of the ISQ based on   the proposals to make an angle a base quantity in the ISQ,
      •  
     Tip: Improving compile times 
    mp-units/systems/isq.h might be expensive to compile in every translation unit. There are some smaller, domain targeted files available for explicit inclusion in the mp-units/systems/isq/... subdirectory.
    "},{"location":"getting_started/project_structure/#systems-of-units","title":"Systems of units","text":"
       
    • mp-units/systems/si.h provides   International System of Units (SI)   definitions and associated math functions,
      •  
    • mp-units/systems/iec.h provides units and prefixes defined by IEC (e.g., in the series of   IEC 80000 standards),
      •  
    • mp-units/systems/angular.h provides strong angular units   and associated math functions,
      •  
    • mp-units/systems/international.h provides   international yard and pound units,
      •  
    • mp-units/systems/imperial.h includes international.h and extends it with   imperial units,
      •  
    • mp-units/systems/usc.h includes international.h and extends it with   United States customary system of units,
      •  
    • mp-units/systems/cgs.h provides   centimetre-gram-second system of units,
      •  
    • mp-units/systems/iau.h provides   astronomical system of units,
      •  
    • mp-units/systems/hep.h provides units used in   high-energy physics,
      •  
    • mp-units/systems/typographic.h provides units used in   typography or typesetting,
      •  
    • mp-units/systems/natural.h provides an example implementation of   natural units.
      •  
     Tip: Improving compile times 
    mp-units/systems/si.h might be expensive to compile in every translation unit. There are some smaller files available for explicit inclusion in the mp-units/systems/si/... subdirectory.
     
    mp-units/systems/si/unit_symbols.h is the most expensive to include.
    "},{"location":"getting_started/quick_start/","title":"Quick Start","text":"
    This chapter provides a quick introduction to get you started with mp-units. Much more details can be found in our User's Guide.
    "},{"location":"getting_started/quick_start/#quantities","title":"Quantities","text":"
    A quantity is a concrete amount of a unit representing a quantity type of a specified dimension with a specific representation. It is represented in the library with a quantity class template.
     
    The SI Brochure says:
     
    SI Brochure
     
    The value of the quantity is the product of the number and the unit. The space between the number and the unit is regarded as a multiplication sign (just as a space between units implies multiplication).
     
    Following the above, the value of a quantity in the mp-units library is created by multiplying a number with a predefined unit:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n
     
    Info
     
    In case someone doesn't like the multiply syntax or there is an ambiguity between operator* provided by this and other libraries, there are two other ways to create a quantity:
     
       
    1.  
      delta construction helper:
       C++ modulesHeader files 
      import mp_units;\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n
       
      #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n
       
      2.  
    2.  
      A two-parameter constructor:
       C++ modulesHeader files 
      import mp_units;\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n
       
      #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n
       
      3.  
     
    The above creates an instance of quantity<derived_unit<si::metre, per<si::second>>{}, int>. The same can be obtained using optional unit symbols:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n
     
    Important
     
    Unit symbols introduce a lot of short identifiers into the current scope, which may cause naming collisions with unrelated but already existing identifiers in the code base. This is why unit symbols are opt-in and typically should be imported only in the context where they are being used (e.g., function scope).
     
    A user has several options here to choose from depending on the required scenario and possible naming conflicts:
     using-directiveusing-declarationcustom short identifierunit names 
    Explicitly \"import\" all of the symbols of a specific system of units from a dedicated unit_symbols namespace with a using-directive:
     
    using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n  // imports all the SI symbols at once\n  using namespace si::unit_symbols;\n  quantity speed = speed_m_s * m / s;\n  // ...\n}\n
     
    Note
     
    This solution is perfect for small and isolated scopes but can cause surprising issues when used in larger scopes or when used for the entire program namespace.
     
    There are 29 named units in SI, and each of them has many prefixed variations (e.g., ng, kcd, ...). It is pretty easy to introduce a name collision with those.
     
    Selectively bring only the required and not-conflicting symbols with using-declarations:
     
    using namespace mp_units;\n\nvoid foo(double N)\n{\n  // 'N' function parameter would collide with the SI symbol for Newton, so we only bring what we need\n  using si::unit_symbols::m;\n  using si::unit_symbols::s;\n  quantity speed = N * m / s;\n  // ...\n}\n
     
    Specify a custom not conflicting unit identifier for a unit:
     
    using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n  // names of some local variables are conflicting with the symbols we want to use\n  auto m = ...;\n  auto s = ...;\n\n  constexpr Unit auto mps = si::metre / si::second;\n  quantity speed = speed_m_s * mps;\n}\n
     
    Full unit names are straightforward to use and often provide the most readable code:
     
    using namespace mp_units;\n\nvoid foo(double m, double s)\n{\n  quantity speed = m * si::metre / (s * si::second);\n  // ...\n}\n
     
    Quantities of the same kind can be added, subtracted, and compared to each other:
     C++ modulesHeader files 
    import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n
     
    #include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n
     
    Various quantities can be multiplied or divided by each other:
     
    static_assert(140 * km / (2 * h) == 70 * km / h);\n
     
    Note
     
    In case you wonder why this library does not use UDLs to create quantities, please check our FAQ.
    "},{"location":"getting_started/quick_start/#quantity-points","title":"Quantity points","text":"
    The quantity point specifies an absolute quantity with respect to an origin. If no origin is provided explicitly, an implicit one will be provided by the library.
     
    Together with quantities, they model The Affine Space.
     
    Quantity points should be used in all places where adding two values is meaningless (e.g., temperature points, timestamps, altitudes, readouts from the car's odometer, etc.).
     
    The set of operations that can be done on quantity points is limited compared to quantities. This introduces an additional type-safety.
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::usc::unit_symbols;\n\n  quantity_point temp = point<deg_C>(20.);\n  std::println(\"Temperature: {} ({})\",\n               temp.quantity_from_zero(),\n               temp.in(deg_F).quantity_from_zero());\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::usc::unit_symbols;\n\n  quantity_point temp = point<deg_C>(20.);\n  std::println(\"Temperature: {} ({})\",\n               temp.quantity_from_zero(),\n               temp.in(deg_F).quantity_from_zero());\n}\n
     
    The above outputs:
     
    Temperature: 20 \u2103 (68 \u2109)\n
     
    Info
     
    Check The Affine Space chapter to learn more about quantity points.
    "},{"location":"users_guide/terms_and_definitions/","title":"Terms and Definitions","text":"
    The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM. You can find essential project-related definitions in our documentation's \"Glossary\" chapter. Even more, terms are provided in the official metrology vocabulary of the ISO and BIPM.
     
    Tip
     
    Please familiarize yourself with terms from \"Glossary\" to better understand the documentation and improve domain-related communication and discussions.
    "},{"location":"users_guide/examples/avg_speed/","title":"avg_speed","text":"
    Try it on Compiler Explorer
     
    Let's continue the previous example. This time, our purpose will not be to showcase as many library features as possible, but we will scope on different interfaces one can provide with the mp-units. We will also describe some advantages and disadvantages of presented solutions.
     
    First, we either import a module or include all the necessary header files and import all the identifiers from the mp_units namespace:
     avg_speed.cpp
    #ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <exception>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/ostream.h>\n#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\nnamespace {\n\nusing namespace mp_units;\n
     
    Next, we define two functions calculating average speed based on quantities of fixed units and integral and floating-point representation types, respectively, and a third function that we introduced in the previous example:
     avg_speed.cpp
    constexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,\n                                                                       quantity<si::second, int> t)\n{\n  return d / t;\n}\n\nconstexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)\n{\n  return d / t;\n}\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    We also added a simple utility to print our results:
     avg_speed.cpp
    template<QuantityOf<isq::length> D, QuantityOf<isq::time> T, QuantityOf<isq::speed> V>\nvoid print_result(D distance, T duration, V speed)\n{\n  const auto result_in_kmph = speed.force_in(si::kilo<si::metre> / non_si::hour);\n  std::cout << \"Average speed of a car that makes \" << distance << \" in \" << duration << \" is \" << result_in_kmph\n            << \".\\n\";\n}\n
     
    Now, let's analyze how those three utility functions behave with different sets of arguments. First, we are going to use quantities of SI units and integral representation:
     avg_speed.cpp
    void example()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  // SI (int)\n  {\n    constexpr auto distance = 220 * km;\n    constexpr auto duration = 2 * h;\n\n    std::cout << \"SI units with 'int' as representation\\n\";\n\n    print_result(distance, duration, fixed_int_si_avg_speed(distance, duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    The above provides the following output:
     
    SI units with 'int' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\n
     
    Please note that in the first two cases, we must convert length from km to m and time from h to s. The converted values are used to calculate speed in m/s which is then again converted to the one in km/h. Those conversions not only impact the application's runtime performance but may also affect the precision of the final result. Such truncation can be easily observed in the first case where we deal with integral representation types (the resulting speed is 108 km/h).
     
    The second scenario is really similar to the previous one, but this time, function arguments have floating-point representation types:
     avg_speed.cpp
      // SI (double)\n  {\n    constexpr auto distance = 220. * km;\n    constexpr auto duration = 2. * h;\n\n    std::cout << \"\\nSI units with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<int>(distance), value_cast<int>(duration)));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    Conversion from floating-point to integral representation types is considered value-truncating and that is why now, in the first case, we need an explicit call to value_cast<int>.
     
    In the text output, we can observe that, again, the resulting value gets truncated during conversions in the first cast:
     
    SI units with 'double' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\n
     
    Next, let's do the same for integral and floating-point representations, but this time using international mile:
     avg_speed.cpp
      // International mile (int)\n  {\n    using namespace mp_units::international::unit_symbols;\n\n    constexpr auto distance = 140 * mi;\n    constexpr auto duration = 2 * h;\n\n    std::cout << \"\\nInternational mile with 'int' as representation\\n\";\n\n    // it is not possible to make a lossless conversion of miles to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n\n  // International mile (double)\n  {\n    using namespace mp_units::international::unit_symbols;\n\n    constexpr auto distance = 140. * mi;\n    constexpr auto duration = 2. * h;\n\n    std::cout << \"\\nInternational mile with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    // also it is not possible to make a lossless conversion of miles to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n
     
    One important difference here is the fact that as it is not possible to make a lossless conversion of miles to meters on a quantity using an integral representation type, so this time, we need a value_cast<m, int> to force it.
     
    If we check the text output of the above, we will see the following:
     
    International mile with 'int' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112 km/h.\n\nInternational mile with 'double' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\n
     
    Please note how the first and third results get truncated using integral representation types.
     
    In the end, we repeat the scenario for CGS units:
     avg_speed.cpp
      // CGS (int)\n  {\n    constexpr auto distance = 22'000'000 * cgs::centimetre;\n    constexpr auto duration = 7200 * cgs::second;\n\n    std::cout << \"\\nCGS units with 'int' as representation\\n\";\n\n    // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n\n  // CGS (double)\n  {\n    constexpr auto distance = 22'000'000. * cgs::centimetre;\n    constexpr auto duration = 7200. * cgs::second;\n\n    std::cout << \"\\nCGS units with 'double' as representation\\n\";\n\n    // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n    // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n    // (explicit cast needed)\n    print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n\n    print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n    print_result(distance, duration, avg_speed(distance, duration));\n  }\n}\n\n}  // namespace\n
     
    Again, we observe value_cast being used in the same places and consistent truncation errors in the text output:
     
    CGS units with 'int' as representation\nAverage speed of a car that makes 22000000 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 109 km/h.\n\nCGS units with 'double' as representation\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\n
     
    The example file ends with a simple main() function:
     avg_speed.cpp
    int main()\n{\n  try {\n    example();\n  } catch (const std::exception& ex) {\n    std::cerr << \"Unhandled std exception caught: \" << ex.what() << '\\n';\n  } catch (...) {\n    std::cerr << \"Unhandled unknown exception caught\\n\";\n  }\n}\n
    ","tags":["CGS System","International System"]},{"location":"users_guide/examples/hello_units/","title":"hello_units","text":"
    Try it on Compiler Explorer
     
    This is a really simple example showcasing the features of the mp-units library.
     
    First, we either import the mp_units module or include the headers for:
     
       
    • an International System of Quantities (ISQ),
      •  
    • an International System of units (SI),
      •  
    • units derived from the International Yard and Pound,
      •  
    • text formatting and stream output support.
      •  
     hello_units.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iomanip>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n
     
    Also, to shorten the definitions, we \"import\" all the symbols from the mp_units namespace.
     hello_units.cpp
    using namespace mp_units;\n
     
    Next, we define a simple function that calculates the average speed based on the provided arguments of length and time:
     hello_units.cpp
    constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n  return d / t;\n}\n
     
    The above function template takes any quantities implicitly convertible to isq::length and isq::time, respectively. Those quantities can use any compatible unit and a representation type. The function returns a result of a straightforward equation and ensures that its quantity type is implicitly convertible to isq::speed.
     
    Tip
     
    Besides verifying the type returned from the function, constraining a generic return type is beneficial for users of such a function as it provides more information of what to expect from a function than just using auto.
     hello_units.cpp
    int main()\n{\n  using namespace mp_units::si::unit_symbols;\n  using namespace mp_units::international::unit_symbols;\n
     
    The above lines explicitly opt into using unit symbols from two systems of units. As this introduces a lot of short identifiers into the current scope, it is not done implicitly while including a header file.
     hello_units.cpp
      constexpr quantity v1 = 110 * km / h;\n  constexpr quantity v2 = 70 * mph;\n  constexpr quantity v3 = avg_speed(220. * km, 2 * h);\n  constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * isq::duration[h]);\n  constexpr quantity v5 = v3.in(m / s);\n  constexpr quantity v6 = value_cast<m / s>(v4);\n  constexpr quantity v7 = value_cast<int>(v6);\n
     
       
    • Lines 27 & 28 create a quantity of kind isq::length / isq::time with the numbers   and units provided. Such quantities can be converted or assigned to any other quantity   with a matching kind.
      •  
    • Line 29 calls our function template with quantities of kind isq::length and   isq::time and number and units provided.
      •  
    • Line 30 explicitly provides quantity types of the quantities passed to a function template.   This time, those will not be quantity kinds anymore and will have   more restrictive conversion rules.
      •  
    • Line 31 changes the unit of a quantity v3 to m / s in a   value-preserving way   (floating-point representations are considered to be value-preserving).
      •  
    • Line 32 does a similar operation, but this time, it would also succeed for   value-truncating cases   (if that was the case).
      •  
    • Line 33 does a value-truncating conversion   of changing the underlying representation type from double to int.
      •  
     hello_units.cpp
      std::cout << v1 << '\\n';                                           // 110 km/h\n  std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n';     // ***70 mi/h\n  std::cout << MP_UNITS_STD_FMT::format(\"{:*^10}\\n\", v3);            // *110 km/h*\n  std::cout << MP_UNITS_STD_FMT::format(\"{:%N in %U of %D}\\n\", v4);  // 70 in mi/h of LT\u207b\u00b9\n  std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]}\\n\", v5);         // 30.56 m/s\n  std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]U[dn]}\\n\", v6);    // 31.29 m\u22c5s\u207b\u00b9\n  std::cout << MP_UNITS_STD_FMT::format(\"{:%N}\\n\", v7);              // 31\n}\n
     
    The above presents various ways to print a quantity. Both stream insertion operations and std::format facilities are supported.
     
    Tip
     
    MP_UNITS_STD_FMT is used for compatibility reasons. If a specific compiler does not support std::format or a user prefers to use the {fmt} library, this macro will resolve to fmt namespace. Otherwise, the std namespace will be used.
     
    More about it can be found in the Wide Compatibility chapter.
    ","tags":["International System","Text Formatting"]},{"location":"users_guide/examples/hw_voltage/","title":"hw_voltage","text":"
    Try it on Compiler Explorer
     
    As it was stated in The Affine Space chapter, every measurement can (and probably should) be modelled as a quantity_point. This is a perfect example of such a use case.
     
    This example implements a simplified scenario of measuring voltage read from hardware through a mapped 16-bits register. The actual voltage range of [-10 V, 10 V] is mapped to [-32767, 32767] on hardware. Translation of the value requires not only scaling of the value but also applying of an offset.
     
    First we include all the dependencies:
     hw_voltage.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iostream>\n#include <optional>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\nusing namespace mp_units;\n
     
    Next, we specify the real measurement voltage range to be in the range of [-10, 10]:
     hw_voltage.cpp
    // real voltage range\ninline constexpr int min_voltage = -10;\ninline constexpr int max_voltage = 10;\ninline constexpr int voltage_range = max_voltage - min_voltage;\n
     
    and provide a storage type and special values for the hardware representation:
     hw_voltage.cpp
    // hardware encoding of voltage\nusing voltage_hw_t = std::uint16_t;\ninline constexpr voltage_hw_t voltage_hw_error = std::numeric_limits<voltage_hw_t>::max();\ninline constexpr voltage_hw_t voltage_hw_min = 0;\ninline constexpr voltage_hw_t voltage_hw_max = voltage_hw_error - 1;\ninline constexpr voltage_hw_t voltage_hw_range = voltage_hw_max - voltage_hw_min;\ninline constexpr voltage_hw_t voltage_hw_zero = voltage_hw_range / 2;\n
     
    Finally, we define a quantity point origin, an offset unit that scales the value and uses this origin to offset the zero of the sale, and a dedicated quantity point alias using those:
     hw_voltage.cpp
    inline constexpr struct hw_voltage_origin final :\n  relative_point_origin<point<si::volt>(min_voltage)> {} hw_voltage_origin;\n\ninline constexpr struct hw_voltage_unit final :\n  named_unit<\"hwV\", mag_ratio<voltage_range, voltage_hw_range> * si::volt, hw_voltage_origin> {} hw_voltage_unit;\n\nusing hw_voltage_quantity_point = quantity_point<hw_voltage_unit, hw_voltage_origin, voltage_hw_t>;\n
     
    Now, when everything is ready, we can simulate mapping of our hardware register, and provide a helper function that will read the value and construct a quantity point from the obtained copy:
     hw_voltage.cpp
    // mapped HW register\nvolatile voltage_hw_t hw_voltage_value;\n\nstd::optional<hw_voltage_quantity_point> read_hw_voltage()\n{\n  voltage_hw_t local_copy = hw_voltage_value;\n  if (local_copy == voltage_hw_error) return std::nullopt;\n  return point<hw_voltage_unit>(local_copy);\n}\n
     
    We also provide a simple print helper for our quantity points:
     hw_voltage.cpp
    void print(QuantityPoint auto qp)\n{\n  std::cout << MP_UNITS_STD_FMT::format(\"{:10} ({:5})\", qp.quantity_from_zero(),\n                                        value_cast<double, si::volt>(qp).quantity_from_zero());\n}\n
     
    In the main function we simulate setting of 3 values by our hardware. Each of them is read and printed in the voltage unit used on the hardware as well as in the standard SI unit:
     hw_voltage.cpp
    int main()\n{\n  // simulate reading of 3 values from the hardware\n  hw_voltage_value = voltage_hw_min;\n  quantity_point qp1 = read_hw_voltage().value();\n  hw_voltage_value = voltage_hw_zero;\n  quantity_point qp2 = read_hw_voltage().value();\n  hw_voltage_value = voltage_hw_max;\n  quantity_point qp3 = read_hw_voltage().value();\n\n  print(qp1);\n  print(qp2);\n  print(qp3);\n}\n
     
    The above program results with the following text output:
     
         0 hwV (-10 V)\n 32767 hwV (  0 V)\n 65534 hwV ( 10 V)\n
    ","tags":["Affine Space","Embedded","Text Formatting"]},{"location":"users_guide/examples/si_constants/","title":"si_constants","text":"
    Try it on Compiler Explorer
     
    The next example presents all the seven defining constants of the SI system. We can observe how Faster-than-lightspeed Constants work in practice.
     si_constants.cpp
    #include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#endif\n
     
    As always, we start with the inclusion of all the needed header files. The main part of the example prints all of the SI-defining constants:
     si_constants.cpp
    int main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si;\n  using namespace mp_units::si::unit_symbols;\n\n  std::cout << \"The seven defining constants of the SI and the seven corresponding units they define:\\n\";\n  std::cout << MP_UNITS_STD_FMT::format(\"- hyperfine transition frequency of Cs: {} = {::N[.0]}\\n\",\n                                        1. * si2019::hyperfine_structure_transition_frequency_of_cs,\n                                        (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));\n  std::cout << MP_UNITS_STD_FMT::format(\"- speed of light in vacuum:             {} = {::N[.0]}\\n\",\n                                        1. * si2019::speed_of_light_in_vacuum,\n                                        (1. * si2019::speed_of_light_in_vacuum).in(m / s));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Planck constant:                      {} = {::N[.8e]}\\n\",\n                                        1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));\n  std::cout << MP_UNITS_STD_FMT::format(\"- elementary charge:                    {} = {::N[.9e]}\\n\",\n                                        1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Boltzmann constant:                   {} = {::N[.6e]}\\n\",\n                                        1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));\n  std::cout << MP_UNITS_STD_FMT::format(\"- Avogadro constant:                    {} = {::N[.8e]}\\n\",\n                                        1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));\n  std::cout << MP_UNITS_STD_FMT::format(\"- luminous efficacy:                    {} = {}\\n\",\n                                        1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));\n}\n
     
    While analyzing the output of this program (provided below), we can easily notice that a direct printing of the quantity provides just a value 1 with a proper constant symbol. This is the main power of the Faster-than-lightspeed Constants feature. Only after we explicitly convert the unit of a quantity to proper SI units we get an actual numeric value of the constant.
     
    The seven defining constants of the SI and the seven corresponding units they define:\n- hyperfine transition frequency of Cs: 1 \u0394\u03bd_Cs = 9192631770 Hz\n- speed of light in vacuum:             1 c = 299792458 m/s\n- Planck constant:                      1 h = 6.62607015e-34 J s\n- elementary charge:                    1 e = 1.602176634e-19 C\n- Boltzmann constant:                   1 k = 1.380649e-23 J/K\n- Avogadro constant:                    1 N_A = 6.02214076e+23 1/mol\n- luminous efficacy:                    1 K_cd = 683 lm/W\n
    ","tags":["Physical Constants","Text Formatting"]},{"location":"users_guide/examples/tags_index/","title":"Tags Index","text":"
    Note
     
    mp-units usage example applications are meant to be built on all of the supported compilers. This is why they benefit from the Wide Compatibility mode.
     
    Tip
     
    All usage examples in this chapter are categorized with appropriate tags to simplify navigation and search of relevant code. You can either read all the examples one-by-one in the order provided by the documentation authors or, thanks to the tagging system, jump straight to the example that is the most interesting for you.
    "},{"location":"users_guide/examples/tags_index/#tag:affine-space","title":"Affine Space","text":"
       
    •             hw_voltage          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:cgs-system","title":"CGS System","text":"
       
    •             avg_speed          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:embedded","title":"Embedded","text":"
       
    •             hw_voltage          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:international-system","title":"International System","text":"
       
    •             avg_speed          
      •  
    •             hello_units          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:physical-constants","title":"Physical Constants","text":"
       
    •             si_constants          
      •  
    "},{"location":"users_guide/examples/tags_index/#tag:text-formatting","title":"Text Formatting","text":"
       
    •             hello_units          
      •  
    •             hw_voltage          
      •  
    •             si_constants          
      •  
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/","title":"Character of a Quantity","text":"
    Warning
     
    This chapter's features are experimental and subject to change or removal. Please share your feedback if something seems wrong or could be improved.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#scalars-vectors-and-tensors","title":"Scalars, vectors, and tensors","text":"
    ISO 80000-2
     
    Scalars, vectors and tensors are mathematical objects that can be used to denote certain physical quantities and their values. They are as such independent of the particular choice of a coordinate system, whereas each scalar component of a vector or a tensor and each component vector and component tensor depend on that choice.
     
    Such distinction is important because each quantity character represents different properties and allows different operations to be done on its quantities.
     
    For example, imagine a physical units library that allows the creation of a \\(speed\\) quantity from both \\(length / time\\) and \\(length * time\\). It wouldn't be too safe to use such a product, right?
     
    Now we have to realize that both of the above operations (multiplication and division) are not even mathematically defined for linear algebra types such as vectors or tensors. On the other hand, two vectors can be passed as arguments to dot and cross-product operations. The result of the first one is a scalar. The second one results in a vector that is perpendicular to both vectors passed as arguments. Again, it wouldn't be safe to allow replacing those two operations with each other or expect the same results from both cases. This simply can't work.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#isq-defines-quantities-of-all-characters","title":"ISQ defines quantities of all characters","text":"
    While defining quantities ISO 80000 explicitly mentions when a specific quantity has a vector or tensor character. Here are some examples:
     Quantity Character Quantity Equation \\(duration\\) scalar {base quantity} \\(mass\\) scalar {base quantity} \\(length\\) scalar {base quantity} \\(path\\; length\\) scalar {base quantity} \\(radius\\) scalar {base quantity} \\(position\\; vector\\) vector {base quantity} \\(velocity\\) vector \\(position\\; vector / duration\\) \\(acceleration\\) vector \\(velocity / duration\\) \\(force\\) vector \\(mass * acceleration\\) \\(power\\) scalar \\(force \\cdot velocity\\) \\(moment\\; of\\; force\\) vector \\(position\\; vector \\times force\\) \\(torque\\) scalar \\(moment\\; of\\; force \\cdot \\{unit\\; vector\\}\\) \\(surface\\; tension\\) scalar \\(\\lvert force \\rvert / length\\) \\(angular\\; displacement\\) scalar \\(path\\; length / radius\\) \\(angular\\; velocity\\) vector \\(angular\\; displacement / duration * \\{unit\\; vector\\}\\) \\(momentum\\) vector \\(mass * velocity\\) \\(angular\\; momentum\\) vector \\(position\\; vector \\times momentum\\) \\(moment\\; of\\; inertia\\) tensor \\(angular\\; momentum \\otimes angular\\; velocity\\) 
    In the above equations:
     
       
    • \\(a * b\\) - regular multiplication where one of the arguments has to be scalar
      •  
    • \\(a / b\\) - regular division where the divisor has to be scalar
      •  
    • \\(a \\cdot b\\) - dot product of two vectors
      •  
    • \\(a \\times b\\) - cross product of two vectors
      •  
    • \\(\\lvert a \\rvert\\) - magnitude of a vector
      •  
    • \\(\\{unit\\; vector\\}\\) - a special vector with the magnitude of \\(1\\)
      •  
    • \\(a \\otimes b\\) - tensor product of two vectors or tensors
      •  
     
    Note
     
    As of now, all of the C++ physical units libraries on the market besides mp-units do not support the operations mentioned above. They expose only multiplication and division operators, which do not work for linear algebra-based representation types. If a user of those libraries would like to create the quantities provided in the above table properly, this would result in a compile-time error stating that multiplication and division of two linear algebra vectors is impossible.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#characters-dont-apply-to-dimensions-and-units","title":"Characters don't apply to dimensions and units","text":"
    ISO 80000 explicitly states that dimensions are orthogonal to quantity characters:
     
    ISO 80000-1:2009
     
    In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
     
    Also, it explicitly states that:
     
    ISO 80000-2
     
    All units are scalars.
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#defining-vector-and-tensor-quantities","title":"Defining vector and tensor quantities","text":"
    To specify that a specific quantity has a vector or tensor character a value of quantity_character enumeration can be appended to the quantity_spec describing such a quantity type:
     C++23C++20Portable 
    inline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<displacement> {} position_vector;\n
     
    inline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, displacement> {} position_vector;\n
     
    QUANTITY_SPEC(displacement, length, quantity_character::vector);\nQUANTITY_SPEC(position_vector, displacement);\n
     
    With the above, all the quantities derived from position_vector or displacement will have a correct character determined according to the kind of operations included in the quantity equation defining a derived quantity.
     
    For example, velocity in the below definition will be defined as a vector quantity (no explicit character override is needed):
     C++23C++20Portable 
    inline constexpr struct velocity final : quantity_spec<speed, displacement / duration> {} velocity;\n
     
    inline constexpr struct velocity final : quantity_spec<velocity, speed, displacement / duration> {} velocity;\n
     
    QUANTITY_SPEC(velocity, speed, displacement / duration);\n
    "},{"location":"users_guide/framework_basics/character_of_a_quantity/#representation-types-for-vector-and-tensor-quantities","title":"Representation types for vector and tensor quantities","text":"
    As we remember, the quantity class template is defined as follows:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    The second template parameter is constrained with a RepresentationOf concept that checks if the provided representation type satisfies the requirements for the character associated with this quantity type.
     
    Note
     
    The current version of the C++ Standard Library does not provide any types that could be used as a representation type for vector and tensor quantities. This is why users are on their own here .
     
    To provide examples and implement unit tests, our library uses the types proposed in the P1385 and available as a Conan package in the Conan Center. However, thanks to the provided customization points, any linear algebra library types can be used as a vector or tensor quantity representation type.
     
    For example, here is how it can be done for the P1385 types:
     
    #include <matrix>\n\nusing la_vector = STD_LA::fixed_size_column_vector<double, 3>;\n\nQuantity auto q = la_vector{1, 2, 3} * isq::velocity[m / s];\n
     
    In case there is an ambiguity of operator* between mp-units and a linear algebra library, we can either:
     
       
    •  
      use two-parameter constructor
       
      Quantity auto q = quantity{la_vector{1, 2, 3}, isq::velocity[m / s]};\n
       
      •  
    •  
      provide a dedicated overload of operator* that will resolve the ambiguity and wrap the above
       
      template<Reference R>\nQuantity auto operator*(la_vector rep, R)\n{\n  return quantity{rep, R{}};\n}\n
       
      •  
     
    Note
     
    The following does not work:
     
    Quantity auto q1 = la_vector{1, 2, 3} * m / s;\nQuantity auto q2 = isq::velocity(la_vector{1, 2, 3} * m / s);\nquantity<isq::velocity[m/s]> q3{la_vector{1, 2, 3} * m / s};\n
     
    In all the cases above, the SI unit m / s has an associated scalar quantity of isq::length / isq::time. la_vector is not a correct representation type for a scalar quantity so the construction fails.
    "},{"location":"users_guide/framework_basics/concepts/","title":"Concepts","text":"
    This chapter enumerates all the user-facing concepts in the mp-units library.
    "},{"location":"users_guide/framework_basics/concepts/#Dimension","title":"Dimension<T>","text":"
    Dimension concept matches a dimension of either a base or derived quantity:
     
       
    • Base dimensions are explicitly defined by the user   by inheriting from the instantiation of a base_dimension class template. It should be instantiated with   a unique symbol identifier describing this dimension in a specific   system of quantities.
      •  
    • Derived dimensions are implicitly created   by the library's framework based on the quantity equation   provided in the quantity specification.
      •  
     
    All of the above dimensions have to be marked as final.
    "},{"location":"users_guide/framework_basics/concepts/#DimensionOf","title":"DimensionOf<T, V>","text":"
    DimensionOf concept is satisfied when both arguments satisfy a Dimension concept and when they compare equal.
    "},{"location":"users_guide/framework_basics/concepts/#QuantitySpec","title":"QuantitySpec<T>","text":"
    QuantitySpec concept matches all the quantity specifications including:
     
       
    • Base quantities defined by a user by inheriting from   the quantity_spec class template instantiated with a base dimension   argument.
      •  
    • Derived named quantities defined by a user by   inheriting from the quantity_spec class template instantiated with a result of a   quantity equation passed as an argument.
      •  
    • Other named quantities forming a hierarchy of quantities   of the same kind defined by a user by inheriting from the   quantity_spec class template instantiated with another \"parent\" quantity specification passed as an   argument.
      •  
    • Quantity kinds describing a family of mutually comparable quantities.
      •  
    • Intermediate derived quantity specifications being   a result of a quantity equations on other specifications.
      •  
     
    All of the above quantity specifications have to be marked as final.
    "},{"location":"users_guide/framework_basics/concepts/#QuantitySpecOf","title":"QuantitySpecOf<T, V>","text":"
    QuantitySpecOf concept is satisfied when both arguments satisfy a QuantitySpec concept and when T is implicitly convertible to V.
    "},{"location":"users_guide/framework_basics/concepts/#UnitMagnitude","title":"UnitMagnitude<T>","text":"
    UnitMagnitude concept is satisfied by all types defining a unit magnitude.
     
    Info
     
    Unit magnitude implementation is a private implementation detail of the library.
    "},{"location":"users_guide/framework_basics/concepts/#Unit","title":"Unit<T>","text":"
    Unit concept matches all the units in the library including:
     
       
    • Base units defined by a user by inheriting from the named_unit   class template instantiated with a unique symbol identifier describing this unit in a specific   system of units.
      •  
    • Named scaled units defined by a user by inheriting from the named_unit class template instantiated   with a unique symbol identifier and a product of multiplying another unit with some magnitude.
      •  
    • Prefixed units defined by a user by inheriting from the prefixed_unit class template instantiated   with a prefix symbol, a magnitude, and a unit to be prefixed.
      •  
    • Derived named units defined by a user by inheriting from the   named_unit class template instantiated with a unique symbol identifier and a result of   unit equation passed as an argument.
      •  
    • Derived unnamed units being a result of a   unit equations on other units.
      •  
     
    All of the above units have to be marked as final.
     
    Note
     
    In the mp-units library, physical constants are also implemented as units.
    "},{"location":"users_guide/framework_basics/concepts/#AssociatedUnit","title":"AssociatedUnit<T>","text":"
    AssociatedUnit concept describes a unit with an associated quantity and is satisfied by:
     
       
    • All units derived from a named_unit class template instantiated with a unique symbol identifier   and a QuantitySpec of a quantity kind.
      •  
    • All units being a result of unit equations on other   associated units.
      •  
     Examples 
    All units in the SI have associated quantities. For example, si::second is specified to measure isq::time.
     
    Natural units typically do not have an associated quantity. For example, if we assume c = 1, a natural::second unit can be used to measure both time and length. In such case, speed would have a unit of one.
    "},{"location":"users_guide/framework_basics/concepts/#PrefixableUnit","title":"PrefixableUnit<T>","text":"
    PrefixableUnit concept is satisfied by all units derived from a named_unit class template. Such units can be passed as an argument to a prefixed_unit class template.
    "},{"location":"users_guide/framework_basics/concepts/#UnitOf","title":"UnitOf<T, V>","text":"
    UnitOf concept is satisfied for all units T for which an associated quantity spec is implicitly convertible to the provided QuantitySpec value.
    "},{"location":"users_guide/framework_basics/concepts/#Reference","title":"Reference<T>","text":"
    Reference concept is satisfied by all quantity reference types. Such types provide all the meta-information required to create a Quantity. A Reference can either be:
     
       
    • An AssociatedUnit.
      •  
    • The instantiation of a reference class template with a QuantitySpec passed as   the first template argument and a Unit passed as the second one.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#ReferenceOf","title":"ReferenceOf<T, V>","text":"
    ReferenceOf concept is satisfied by references T which have a quantity specification that satisfies QuantitySpecOf<V> concept.
    "},{"location":"users_guide/framework_basics/concepts/#RepresentationOf","title":"RepresentationOf<T, V>","text":"
    RepresentationOf concept constraints a type of a number that stores the value of a quantity and is satisfied:
     
       
    •  
      if the type of V satisfies QuantitySpec:
       
         
      • by all representation types when V describes   a quantity kind,
        •  
      • otherwise, by representation types that are of   a quantity character associated with a provided   quantity specification V.
        •  
       
      •  
    •  
      if V is of quantity_character type:
       
         
      • by representation types that are of a provided   quantity character.
        •  
       
      •  
    "},{"location":"users_guide/framework_basics/concepts/#Quantity","title":"Quantity<T>","text":"
    Quantity concept matches every quantity in the library and is satisfied by all types being or deriving from an instantiation of a quantity class template.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityOf","title":"QuantityOf<T, V>","text":"
    QuantityOf concept is satisfied by all the quantities for which a ReferenceOf<V> is true.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityLike","title":"QuantityLike<T>","text":"
    QuantityLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_like_traits type trait yields a valid type that provides:
     
       
    • reference static data member that matches the Reference concept,
      •  
    • rep type that matches RepresentationOf concept with the character provided   in reference,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     Examples 
    This is how support for std::chrono::seconds can be provided:
     
    template<>\nstruct mp_units::quantity_like_traits<std::chrono::seconds> {\n  static constexpr auto reference = si::second;\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = false;\n  using rep = std::chrono::seconds::rep;\n\n  [[nodiscard]] static constexpr rep to_numerical_value(const std::chrono::seconds& d)\n  {\n    return d.count();\n  }\n\n  [[nodiscard]] static constexpr std::chrono::seconds from_numerical_value(const rep& v)\n  {\n    return std::chrono::seconds(v);\n  }\n};\n\nquantity q = 42s;\nstd::chrono::seconds dur = 42 * s;\n
    "},{"location":"users_guide/framework_basics/concepts/#PointOrigin","title":"PointOrigin<T>","text":"
    PointOrigin concept matches all quantity point origins in the library. It is satisfied by either:
     
       
    • All types derived from an absolute_point_origin class template.
      •  
    • All types derived from a relative_point_origin class template.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#PointOriginFor","title":"PointOriginFor<T, V>","text":"
    PointOriginFor concept is satisfied by all PointOrigin types that have quantity type implicitly convertible from quantity specification V, which means that V must satisfy QuantitySpecOf<T::quantity_spec>.
     Examples 
    si::ice_point can serve as a point origin for points of isq::Celsius_temperature because this quantity type implicitly converts to isq::thermodynamic_temperature.
     
    However, if we define mean_sea_level in the following way:
     
    inline constexpr struct mean_sea_level final : absolute_point_origin<isq::altitude> {} mean_sea_level;\n
     
    then it can't be used as a point origin for points of isq::length or isq::width as none of them is implicitly convertible to isq::altitude:
     
       
    • not every length is an altitude,
      •  
    • width is not compatible with altitude.
      •  
    "},{"location":"users_guide/framework_basics/concepts/#QuantityPoint","title":"QuantityPoint<T>","text":"
    QuantityPoint concept is satisfied by all types being either a specialization or derived from quantity_point class template.
    "},{"location":"users_guide/framework_basics/concepts/#QuantityPointOf","title":"QuantityPointOf<T, V>","text":"
    QuantityPointOf concept is satisfied by all the quantity points T that match the following value V:
     V Condition QuantitySpec The quantity point quantity specification satisfies ReferenceOf<V> concept. PointOrigin The point and V have the same absolute point origin."},{"location":"users_guide/framework_basics/concepts/#QuantityPointLike","title":"QuantityPointLike<T>","text":"
    QuantityPointLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_point_like_traits type trait yields a valid type that provides:
     
       
    • reference static data member that matches the Reference concept.
      •  
    • point_origin static data member that matches the PointOrigin concept.
      •  
    • rep type that matches RepresentationOf concept with the character provided   in reference.
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity_point type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity_point type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity being the offset   of the point from the origin,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     Examples 
    This is how support for a std::chrono::time_point of std::chrono::seconds can be provided:
     
    template<typename C>\nstruct mp_units::quantity_point_like_traits<std::chrono::time_point<C, std::chrono::seconds>> {\n  static constexpr auto reference = si::second;\n  static constexpr struct point_origin_ final : absolute_point_origin<isq::time> {} point_origin{};\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = false;\n  using rep = std::chrono::seconds::rep;\n  using T = std::chrono::time_point<C, std::chrono::seconds>;\n\n  [[nodiscard]] static constexpr rep to_numerical_value(const T& tp)\n  {\n    return tp.time_since_epoch().count();\n  }\n\n  [[nodiscard]] static constexpr T from_numerical_value(const rep& v)\n  {\n    return T(std::chrono::seconds(v));\n  }\n};\n\nquantity_point qp = time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now());\nstd::chrono::sys_seconds q = qp + 42 * s;\n
    "},{"location":"users_guide/framework_basics/design_overview/","title":"Design Overview","text":"
    The most important entities in the mp-units library are:
     
       
    • quantity,
      •  
    • quantity point,
      •  
    • unit,
      •  
    • dimension,
      •  
    • quantity specification
      •  
    • quantity reference,
      •  
    • quantity representation.
      •  
     
    The graph provided below presents how those and a few other entities depend on each other:
     
    flowchart TD\n    Unit --- Reference\n    Dimension --- QuantitySpec[\"Quantity specification\"]\n    quantity_character[\"Quantity character\"] --- QuantitySpec\n    QuantitySpec --- Reference[\"Quantity reference\"]\n    Reference --- Quantity\n    quantity_character -.- Representation\n    Representation --- Quantity\n    Quantity --- QuantityPoint[\"Quantity point\"]\n    PointOrigin[\"Point origin\"] --- QuantityPoint\n\n    click Dimension \"#dimension\"\n    click quantity_character \"#quantity-character\"\n    click QuantitySpec \"#quantity-specification\"\n    click Unit \"#unit\"\n    click Reference \"#quantity-reference\"\n    click Representation \"#quantity-representation\"\n    click Quantity \"#quantity\"\n    click PointOrigin \"#point-origin\"\n    click QuantityPoint \"#quantity-point\"
    "},{"location":"users_guide/framework_basics/design_overview/#dimension","title":"Dimension","text":"
    Dimension specifies the dependence of a quantity on the base quantities of a particular system of quantities. It is represented as a product of powers of factors corresponding to the base quantities, omitting any numerical factor.
     
    In the mp-units library, we use the terms:
     
       
    • base dimension to refer to the dimension of a base quantity,
      •  
    • derived dimension to refer to the dimension of a derived quantity.
      •  
     
    For example:
     
       
    • length (\\(\\mathsf{L}\\)), mass (\\(\\mathsf{M}\\)), time (\\(\\mathsf{T}\\)), electric current (\\(\\mathsf{I}\\)),   thermodynamic temperature (\\(\\mathsf{\u0398}\\)), amount of substance (\\(\\mathsf{N}\\)), and   luminous intensity (\\(\\mathsf{J}\\)) are the base dimensions of the ISQ.
      •  
    • A derived dimension of force in the ISQ is denoted by   \\(\\textsf{dim }F = \\mathsf{LMT}^{\u20132}\\).
      •  
    • The implementation of IEC 80000 in this library provides iec::dim_traffic_intensity   base dimension to extend ISQ with strong information technology quantities.
      •  
     
    Base dimensions can be defined by the user in the following way:
     
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\n
     
    Derived dimensions are implicitly created by the library's framework based on the quantity equation provided in the quantity specification:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct time final : quantity_spec<dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct time final : quantity_spec<time, dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(time, dim_time);\nQUANTITY_SPEC(speed, length / time);\n\nstatic_assert(speed.dimension == dim_length / dim_time);\n
     
    Important
     
    Users should not explicitly define any derived dimensions. Those should always be implicitly created by the framework.
     
    The multiplication/division on quantity specifications also multiplies/divides their dimensions:
     
    static_assert((length / time).dimension == dim_length / dim_time);\n
     
    The dimension equation of isq::dim_length / isq::dim_time results in the derived_dimension<isq::dim_length, per<isq::dim_time>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-character","title":"Quantity character","text":"
    ISO 80000 explicitly states that quantities (even of the same kind) may have different characters:
     
       
    • real scalar (e.g., time, width, speed, apparent power),
      •  
    • complex scalar (e.g., voltage phasor, complex power, impedance),
      •  
    • vector (e.g., displacement, velocity, force),
      •  
    • tensor (e.g., moment of inertia, stress, strain).
      •  
     
    The quantity character in the mp-units library is implemented with the quantity_character enumeration:
     
    enum class quantity_character { real_scalar, complex_scalar, vector, tensor };\n
     
    Info
     
    You can read more on quantity characters in the \"Character of a Quantity\" chapter.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-specification","title":"Quantity specification","text":"
    Dimension is not enough to describe a quantity. This is why the ISO 80000 provides hundreds of named quantity types. It turns out that there are many more quantity types in the ISQ than the named units in the SI.
     
    This is why the mp-units library introduces a quantity specification entity that stores:
     
       
    • dimension,
      •  
    • quantity type/name,
      •  
    • quantity character,
      •  
    • the quantity equation being the recipe to create this quantity   (only for derived quantities that specify such a recipe).
      •  
     
    Note
     
    We know that it might be sometimes confusing to talk about quantities, quantity types/names, and quantity specifications. However, it might be important to notice here that even the ISO 80000 admits that:
     
    It is customary to use the same term, \"quantity\", to refer to both general quantities, such as length, mass, etc., and their instances, such as given lengths, given masses, etc. Accordingly, we are used to saying both that length is a quantity and that a given length is a quantity by maintaining the specification \u2013 \"general quantity, \\(Q\\)\" or \"individual quantity, \\(Q_\\textsf{a}\\)\" \u2013 implicit and exploiting the linguistic context to remove the ambiguity.
     
    In the mp-units library, we have a:
     
       
    • quantity - implemented as a quantity class template,
      •  
    • quantity specification - implemented with a quantity_spec class template that among others identifies   a specific quantity type/name.
      •  
     
    For example:
     
       
    • isq::length, isq::mass, isq::time, isq::electric_current, isq::thermodynamic_temperature,   isq::amount_of_substance, and isq::luminous_intensity are the specifications of base quantities   in the ISQ.
      •  
    • isq::width, isq::height, isq::radius, and isq::position_vector are only a few of many    quantities of a kind length specified in the ISQ.
      •  
    • isq::area, isq::speed, isq::moment_of_force are only a few of many derived quantities provided   in the ISQ.
      •  
     
    Quantity specification  can be defined by the user in one of the following ways:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(height, length);\nQUANTITY_SPEC(speed, length / time);\n
     
    The quantity equation of isq::length / isq::time results in the derived_quantity_spec<isq::length, per<isq::time>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#unit","title":"Unit","text":"
    A unit is a concrete amount of a quantity that allows us to measure the values of quantities of the same kind and represent the result as a number being the ratio of the two quantities.
     
    For example:
     
       
    • si::second, si::metre, si::kilogram, si::ampere, si::kelvin, si::mole, and si::candela   are the base units of the SI.
      •  
    • si::kilo<si::metre> is a prefixed unit of length.
      •  
    • si::radian, si::newton, and si::watt are examples of named derived units within the   SI.
      •  
    • non_si::minute is an example of a scaled unit of time.
      •  
    • si::si2019::speed_of_light_in_vacuum is a physical constant standardized by the SI in 2019.
      •  
     
    Note
     
    In the mp-units library, physical constants are also implemented as units.
     
    A unit can be defined by the user in one of the following ways:
     
    template<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr kilo_<decltype(U)> kilo;\n\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct minute final : named_unit<\"min\", mag<60> * second> {} minute;\ninline constexpr struct gram   final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\n\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n
     
    The unit equation of si::metre / si::second results in the derived_unit<si::metre, per<si::second>> type.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-reference","title":"Quantity reference","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    After that, it says:
     
    Quote
     
    A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
     
    In the mp-units library, a quantity reference provides all the domain-specific metadata for the quantity besides its numerical value:
     
       
    • all the data stored in the quantity specification,
      •  
    • unit.
      •  
     
    Together with the value of a representation type, it forms a quantity.
     
    In the library, we have two different ways to provide a reference:
     
       
    • every unit with the associated quantity kind   is a valid reference,
      •  
    • providing a unit to an indexing operator of a quantity specification explicitly instantiates   a reference class template with this quantity spec and a unit passed as arguments.
      •  
     
    Note
     
    All the units of the SI have associated quantity kinds and may serve as a reference.
     
    For example:
     
       
    • si::metre is defined in the SI as a unit of isq::length   and thus can be used as a reference to instantiate a quantity of length (e.g., 42 * m).
      •  
    • The expression isq::height[m] results with reference<isq::height, si::metre>, which can be used to   instantiate a quantity of isq::height with a unit of si::metre (e.g., 42 * isq::height[m]).
      •  
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-representation","title":"Quantity representation","text":"
    Quantity representation defines the type used to store the numerical value of a quantity. Such a type should be of a specific quantity character provided in the quantity specification.
     
    Note
     
    By default, all floating-point and integral (besides bool) types are treated as scalars.
    "},{"location":"users_guide/framework_basics/design_overview/#quantity","title":"Quantity","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    This is why a quantity class template is defined in the library as:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    Its value can be easily created by multiplying/dividing the numerical value and a reference.
     
    For example:
     
       
    • All of 42 * m, 42 * si::metre, 42 * isq::height[m], and isq::height(42 * m) create a quantity.
      •  
    • A quantity type can also be specified explicitly (e.g., quantity<si::metre, int>,   quantity<isq::height[m]>).
      •  
    "},{"location":"users_guide/framework_basics/design_overview/#point-origin","title":"Point origin","text":"
    In the affine space theory, the point origin specifies where the \"zero\" of our measurement's scale is.
     
    In the mp-units library, we have two types of point origins:
     
       
    • absolute - defines an absolute \"zero\" for our point,
      •  
    • relative - defines an origin that has some \"offset\" relative   to an absolute point.
      •  
     
    For example:
     
       
    • the absolute point origin can be defined in the following way:
      •  
     
    inline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\n
     
       
    • the relative point origin can be defined in the following way:
      •  
     
    inline constexpr struct ice_point final : relative_point_origin<absolute_zero + 273'150 * milli<kelvin>> {} ice_point;\n
    "},{"location":"users_guide/framework_basics/design_overview/#quantity-point","title":"Quantity point","text":"
    Quantity point implements a point in the affine space theory.
     
    In the mp-units library, the quantity point is implemented as:
     
    template<Reference auto R,\n         PointOriginFor<get_quantity_spec(R)> auto PO,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity_point;\n
     
    Its value can be easily created by adding/subtracting the quantity with a point origin.
     
    For example:
     
       
    • The following specifies a quantity point defined in terms of an ice_point provided in   the previous example:
      •  
     
    constexpr auto room_reference_temperature = ice_point + delta<isq::Celsius_temperature[deg_C]>(21);\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/","title":"Dimensionless Quantities","text":"
    The quantities we discussed so far always had some specific type and physical dimension. However, this is not always the case. While performing various computations, we sometimes end up with so-called \"dimensionless\" quantities, which ISO defines as quantities of dimension one:
     
    ISO/IEC Guide 99
     
       
    • Quantity for which all the exponents of the factors corresponding to the base quantities in   its quantity dimension are zero.
      •  
    • The measurement units and values of quantities of dimension one are numbers, but such quantities   convey more information than a number.
      •  
    • Some quantities of dimension one are defined as the ratios of two quantities of the same kind.
      •  
    • Numbers of entities are quantities of dimension one.
      •  
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-two-quantities-of-the-same-kind","title":"Dividing two quantities of the same kind","text":"
    Dividing two quantities of the same kind always results in a quantity of dimension one. However, depending on what type of quantities we divide or what their units are, we may end up with slightly different results.
     
    Note
     
    In mp-units, dividing two quantities of the same dimension always results in a quantity with the dimension being dimension_one. This is often different for other physical units libraries, which may return a raw representation type for such cases. A raw value is also always returned from the division of two std::chrono::duration objects.
     
    To read more about the reasoning for this design decision, please check our FAQ.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-the-same-type","title":"Dividing quantities of the same type","text":"
    First, let's analyze what happens if we divide two quantities of the same type:
     
    constexpr QuantityOf<dimensionless> auto q = isq::height(200 * m) / isq::height(50 * m);\n
     
    In such a case, we end up with a dimensionless quantity that has the following properties:
     
    static_assert(q.quantity_spec == dimensionless);\nstatic_assert(q.dimension == dimension_one);\nstatic_assert(q.unit == one);\n
     
    In case we would like to print its value, we would see a raw value of 4 in the output with no unit being printed.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-different-types","title":"Dividing quantities of different types","text":"
    Now let's see what happens if we divide quantities of the same dimension and unit but which have different quantity types:
     
    constexpr QuantityOf<dimensionless> auto q = isq::work(200 * J) / isq::heat(50 * J);\n
     
    Again we end up with dimension_one and one, but this time:
     
    static_assert(q.quantity_spec == isq::work / isq::heat);\n
     
    As shown above, the result is not of a dimensionless type anymore. Instead, we get a quantity type derived from the performed quantity equation. According to the ISQ, work divided by heat is the recipe for the thermodynamic efficiency quantity, thus:
     
    static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));\n
     
    Note
     
    The quantity of isq::efficiency_thermodynamics is of a kind dimensionless, so it is implicitly convertible to dimensionless and satisfies the QuantityOf<dimensionless> concept.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-different-units","title":"Dividing quantities of different units","text":"
    Now, let's see what happens when we divide two quantities of the same type but different units:
     
    constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);\n
     
    This time, we still get a quantity of the dimensionless type with a dimension_one as its dimension. However, the resulting unit is not one anymore:
     
    static_assert(q.unit == mag_power<10, 3> * one);\n
     
    In case we would print the text output of this quantity, we would not see a raw value of 2000, but 2 km/m.
     
    First, it may look surprising, but this is consistent with dividing quantities of different dimensions. For example, if we divide 4 * km / 2 * s, we do not expect km to be \"expanded\" to m before the division, right? We would expect the result of 2 km/s, which is exactly what we get when we divide quantities of the same kind.
     
    This is a compelling feature that allows us to express huge or tiny ratios without the need for big and expensive representation types. With this, we can easily define things like a Hubble's constant that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both units of length:
     
    inline constexpr struct hubble_constant final :\n    named_unit<{u8\"H\u2080\", \"H_0\"}, mag_ratio<701, 10> * si::kilo<si::metre> / si::second / si::mega<parsec>> {} hubble_constant;\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#counts-of-things","title":"Counts of things","text":"
    Another important use case for dimensionless quantities is to provide strong types for counts of things. For example:
     
       
    • ISO-80000-3 provides a rotation quantity defined as the number of revolutions,
      •  
    • IEC-80000-6 provides a number of turns in a winding quantity,
      •  
    • IEC-80000-13 provides a Hamming distance quantity defined as the number of digit positions   in which the corresponding digits of two words of the same length are different.
      •  
     
    Thanks to assigning strong names to such quantities, later on, they can be explicitly used as arguments in the quantity equations of other quantities deriving from them.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#predefined-units-of-the-dimensionless-quantity","title":"Predefined units of the dimensionless quantity","text":"
    As we observed above, the most common unit for dimensionless quantities is one. It has the ratio of 1 and does not output any textual symbol.
     
    Important: one is an identity
     
    A unit one is special in the entire type system of units as it is considered to be an identity operand in the unit symbolic expressions. This means that, for example:
     
    static_assert(one * one == one);\nstatic_assert(one * si::metre == si::metre);\nstatic_assert(si::metre / si::metre == one);\n
     
    The same is also true for dimension_one and dimensionless in the domains of dimensions and quantity specifications.
     
    Besides the unit one, there are a few other scaled units predefined in the library for usage with dimensionless quantities:
     
    inline constexpr struct percent final : named_unit<\"%\", mag_ratio<1, 100> * one> {} percent;\ninline constexpr struct per_mille final : named_unit<{u8\"\u2030\", \"%o\"}, mag_ratio<1, 1000> * one> {} per_mille;\ninline constexpr struct parts_per_million final : named_unit<\"ppm\", mag_ratio<1, 1'000'000> * one> {} parts_per_million;\ninline constexpr auto ppm = parts_per_million;\n
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#superpowers-of-the-unit-one","title":"Superpowers of the unit one","text":"
    Quantities implicitly convertible to dimensionless with the unit equivalent to one are the only ones that are:
     
       
    • implicitly constructible from the raw value,
      •  
    • explicitly convertible to a raw value,
      •  
    • comparable to a raw value.
      •  
     
    quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n  legacy(static_cast<int>(q));\n
     
    This property also expands to usual arithmetic operators.
     
    Note
     
    Those rules do not apply to all the dimensionless quantities. It would be unsafe and misleading to allow such operations on units with a magnitude different than 1 (e.g., percent) or for quantities that are not implicitly convertible to dimensionless (e.g., angular_measure).
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#angular-quantities","title":"Angular quantities","text":"
    Special, often controversial, examples of dimensionless quantities are an angular measure and solid angular measure quantities that are defined in the ISQ to be the result of a division of \\(arc\\; length / radius\\) and \\(area / radius^2\\) respectively. Moreover, ISQ also explicitly states that both can be expressed in the unit one. This means that both angular measure and solid angular measure should be of a kind dimensionless.
     
    On the other hand, ISQ also specifies that a unit radian can be used for angular measure, and a unit steradian can be used for solid angular measure. Those should not be mixed or used to express other types of dimensionless quantities. This means that both angular measure and solid angular measure should also be quantity kinds by themselves.
     
    Note
     
    Many people claim that angle being a dimensionless quantity is a bad idea. There are proposals submitted to make an angle a base quantity and rad to become a base unit. More on this topic can be found in the \"Strong Angular System\" chapter.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#radians-and-degrees-support","title":"Radians and degrees support","text":"
    Thanks to the usage of magnitudes the library provides efficient strong types for all angular types. This means that with the built-in support for magnitudes of \\(\\pi\\) we can provide accurate conversions between radians and degrees. The library also provides common trigonometric functions for angular quantities:
     
    using namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::rad;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::grad;\n\nquantity speed = 110 * km / h;\nquantity rate_of_climb = -0.63657 * m / s;\nquantity glide_ratio = speed / -rate_of_climb;\nquantity glide_angle = angular::asin(1 / glide_ratio);\n\nstd::println(\"Glide ratio: {::N[.1f]}\", glide_ratio.in(one));\nstd::println(\"Glide angle:\");\nstd::println(\" - {::N[.4f]}\", glide_angle.in(rad));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(deg));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(grad));\n
     
    The above program prints:
     
    Glide ratio: 48.0\nGlide angle:\n - 0.0208 rad\n - 1.19\u00b0\n - 1.33\u1d4d\n
     
    Note
     
    In the production code the above speed and rate_of_climb quantities should probably be modelled as separate typed quantities of the same kind.
    "},{"location":"users_guide/framework_basics/dimensionless_quantities/#nested-quantity-kinds","title":"Nested quantity kinds","text":"
    Angular quantities are not the only ones with such a \"strange\" behavior. Another but a similar case is a storage capacity quantity specified in IEC-80000-13 that again allows expressing it in both one and bit units.
     
    Those cases make dimensionless quantities an exceptional tree in the library. This quantity hierarchy contains more than one quantity kind and more than one unit in its tree:
     
    flowchart TD\n    dimensionless[\"<b>dimensionless</b><br>[one]\"]\n    dimensionless --- rotation[\"<b>rotation</b>\"]\n    dimensionless --- thermodynamic_efficiency[\"<b>thermodynamic_efficiency</b><br><i>(work / heat)</i>\"]\n    dimensionless --- angular_measure[\"<b>angular_measure</b><br><i>(arc_length / radius)</i><br>[rad]\"]\n    angular_measure --- rotational_displacement[\"<b>rotational_displacement</b><br><i>(path_length / radius)</i>\"]\n    angular_measure --- phase_angle[\"<b>phase_angle</b>\"]\n    dimensionless --- solid_angular_measure[\"<b>solid_angular_measure</b><br><i>(area / pow<2>(radius))</i><br>[sr]\"]\n    dimensionless --- drag_factor[\"<b>drag_factor</b><br><i>(drag_force / (mass_density * pow<2>(speed) * area))</i>\"]\n    dimensionless --- storage_capacity[\"<b>storage_capacity</b><br>[bit]\"] --- equivalent_binary_storage_capacity[\"<b>equivalent_binary_storage_capacity</b>\"]\n    dimensionless --- ...
     
    To provide such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
     C++23C++20Portable 
    inline constexpr struct angular_measure final : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<dimensionless, is_kind> {} storage_capacity;\n
     
    inline constexpr struct angular_measure final : quantity_spec<angular_measure, dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<storage_capacity, dimensionless, is_kind> {} storage_capacity;\n
     
    QUANTITY_SPEC(angular_measure, dimensionless, arc_length / radius, is_kind);\nQUANTITY_SPEC(solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind);\nQUANTITY_SPEC(storage_capacity, dimensionless, is_kind);\n
     
    With the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
     
    inline constexpr struct radian final : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\n
     
    but still allow the usage of one and its scaled versions for such quantities.
     
    Info
     
    It is worth mentioning here that converting up the hierarchy beyond a subkind requires an explicit conversion. For example:
     
    static_assert(implicitly_convertible(isq::rotation, dimensionless));\nstatic_assert(!implicitly_convertible(isq::angular_measure, dimensionless));\nstatic_assert(explicitly_convertible(isq::angular_measure, dimensionless));\n
     
    This increases type safety and prevents accidental quantities with invalid units. For example, a result of a conversion from isq::angular_measure[rad] to dimensionless would be a reference of dimensionless[rad], which contains an incorrect unit for a dimensionless quantity. Such a conversion must be explicit and be preceded by an explicit unit conversion:
     
    quantity q1 = isq::angular_measure(42. * rad);\nquantity<dimensionless[one]> q2 = dimensionless(q1.in(one));\n
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/","title":"Faster-than-lightspeed Constants","text":"
    In most libraries, physical constants are implemented as constant (possibly constexpr) quantity values. Such an approach has some disadvantages, often affecting the run time performance and causing a loss of precision.
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#simplifying-constants-in-an-equation","title":"Simplifying constants in an equation","text":"
    When dealing with equations involving physical constants, they often occur more than once in an expression. Such a constant may appear both in a numerator and denominator of a quantity equation. As we know from fundamental physics, we can simplify such an expression by striking a constant out of the equation. Supporting such behavior allows a faster runtime performance and often a better precision of the resulting value.
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#physical-constants-as-units","title":"Physical constants as units","text":"
    The mp-units library allows and encourages the implementation of physical constants as regular units. With that, the constant's value is handled at compile-time, and under favorable circumstances, it can be simplified in the same way as all other repeated units do. If it is not simplified, the value is stored in a type, and the expensive multiplication or division operations can be delayed in time until a user selects a specific unit to represent/print the data.
     
    Such a feature often also allows using simpler or faster representation types in the equation. For example, instead of always having to multiply a small integral value with a big floating-point constant number, we can just use the integral type all the way. Only in case a constant will not simplify in the equation, and the user will require a specific unit, such a multiplication will be lazily invoked, and the representation type will need to be expanded to facilitate that. With that, addition, subtractions, multiplications, and divisions will always be the fastest - compiled away or done in out-of-order execution.
     
    To benefit from all of the above, in the mp-units library, SI defining and other constants are implemented as units in the following way:
     
    namespace si {\n\nnamespace si2019 {\n\ninline constexpr struct speed_of_light_in_vacuum final :\n  named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n\n}  // namespace si2019\n\ninline constexpr struct magnetic_constant final :\n  named_unit<{u8\"\u03bc\u2080\", \"u_0\"}, mag<4> * mag<\u03c0> * mag_power<10, -7> * henry / metre> {} magnetic_constant;\n\n}  // namespace mp_units::si\n
    "},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#usage-examples","title":"Usage examples","text":"
    With the above definitions, we can calculate vacuum permittivity as:
     
    constexpr auto permeability_of_vacuum = 1. * si::magnetic_constant;\nconstexpr auto speed_of_light_in_vacuum = 1 * si::si2019::speed_of_light_in_vacuum;\n\nQuantityOf<isq::permittivity_of_vacuum> auto q = 1 / (permeability_of_vacuum * pow<2>(speed_of_light_in_vacuum));\n\nstd::println(\"permittivity of vacuum = {} = {::N[.3e]}\", q, q.in(F / m));\n
     
    The above first prints the following:
     
    permittivity of vacuum = 1  \u03bc\u2080\u207b\u00b9 c\u207b\u00b2 = 8.854e-12 F/m\n
     
    As we can clearly see, all the calculations above were just about multiplying and dividing the number 1 with the rest of the information provided as a compile-time type. Only when a user wants a specific SI unit as a result, the unit ratios are lazily resolved.
     
    Another similar example can be an equation for total energy:
     
    QuantityOf<isq::mechanical_energy> auto total_energy(QuantityOf<isq::momentum> auto p,\n                                                     QuantityOf<isq::mass> auto m,\n                                                     QuantityOf<isq::speed> auto c)\n{\n  return isq::mechanical_energy(sqrt(pow<2>(p * c) + pow<2>(m * pow<2>(c))));\n}\n
     
    constexpr auto GeV = si::giga<si::electronvolt>;\nconstexpr QuantityOf<isq::speed> auto c = 1. * si::si2019::speed_of_light_in_vacuum;\nconstexpr auto c2 = pow<2>(c);\n\nconst auto p1 = isq::momentum(4. * GeV / c);\nconst QuantityOf<isq::mass> auto m1 = 3. * GeV / c2;\nconst auto E = total_energy(p1, m1, c);\n\nstd::cout << \"in `GeV` and `c`:\\n\"\n          << \"p = \" << p1 << \"\\n\"\n          << \"m = \" << m1 << \"\\n\"\n          << \"E = \" << E << \"\\n\";\n\nconst auto p2 = p1.in(GeV / (m / s));\nconst auto m2 = m1.in(GeV / pow<2>(m / s));\nconst auto E2 = total_energy(p2, m2, c).in(GeV);\n\nstd::cout << \"\\nin `GeV`:\\n\"\n          << \"p = \" << p2 << \"\\n\"\n          << \"m = \" << m2 << \"\\n\"\n          << \"E = \" << E2 << \"\\n\";\n\nconst auto p3 = p1.in(kg * m / s);\nconst auto m3 = m1.in(kg);\nconst auto E3 = total_energy(p3, m3, c).in(J);\n\nstd::cout << \"\\nin SI base units:\\n\"\n          << \"p = \" << p3 << \"\\n\"\n          << \"m = \" << m3 << \"\\n\"\n          << \"E = \" << E3 << \"\\n\";\n
     
    The above prints the following:
     
    in `GeV` and `c`:\np = 4 GeV/c\nm = 3 GeV/c\u00b2\nE = 5 GeV\n\nin `GeV`:\np = 1.33426e-08 GeV s/m\nm = 3.33795e-17 GeV s\u00b2/m\u00b2\nE = 5 GeV\n\nin SI base units:\np = 2.13771e-18 kg m/s\nm = 5.34799e-27 kg\nE = 8.01088e-10 J\n
    "},{"location":"users_guide/framework_basics/generic_interfaces/","title":"Generic Interfaces","text":"
    Using a concrete unit in the interface often makes a lot of sense. It is especially useful if we store the data internally in the object. In such a case, we have to select a specific unit anyway.
     
    For example, let's consider a simple storage tank:
     
    class StorageTank {\n  quantity<horizontal_area[m2]> base_;\n  quantity<isq::height[m]> height_;\n  quantity<isq::mass_density[kg / m3]> density_ = air_density;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[m2]>& base, const quantity<isq::height[m]>& height) :\n      base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n
     
    As the quantities provided in the function's interface are then stored in the class, there is probably no sense in using generic interfaces here.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#the-issues-with-unit-specific-interfaces","title":"The issues with unit-specific interfaces","text":"
    However, in many cases, using a specific unit in the interface is counterproductive. Let's consider the following function:
     
    quantity<km / h> avg_speed(quantity<km> distance, quantity<h> duration)\n{\n  return distance / duration;\n}\n
     
    Everything seems fine for now. It also works great if we call it with:
     
    quantity<km / h> s1 = avg_speed(220 * km, 2 * h);\n
     
    However, if the user starts doing the following:
     
    quantity<mi / h> s2 = avg_speed(140 * mi, 2 * h);\nquantity<m / s> s3 = avg_speed(20 * m, 2 * s);\n
     
    some issues start to be clearly visible:
     
       
    1. The arguments must be converted to units mandated by the function's parameters at each call.    This involves potentially expensive multiplication/division operations at runtime.
      2.  
    2. After the function returns the speed in a unit of km/h, another potentially expensive    multiplication/division operations must be performed to convert the resulting quantity into    a unit being the derived unit of the initial function's arguments.
      3.  
    3. Besides the obvious runtime cost, some unit conversions may result in a value truncation, which    means that the result will not be exactly equal to a direct division of the function's arguments.
      4.  
    4.  
      We have to use a floating-point representation type (the quantity class template by default uses    double as a representation type) which is considered    value-preserving.    Trying to use an integral type in this scenario will work only for s1, while s2 and s3    will fail to compile. Failing to compile is a good thing here as the library tries to prevent    the user from doing a clearly wrong thing. To make the code compile, the user needs to use    dedicated value_cast or force_in like this:
       
      quantity<isq::speed[mi / h]> s2 = avg_speed(value_cast<km>(140 * mi), 2 * h);\nquantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));\n
       
      but the above will obviously provide an incorrect behavior (e.g., division by 0 in the evaluation of s3).
       
      5.  
    "},{"location":"users_guide/framework_basics/generic_interfaces/#a-naive-solution","title":"A naive solution","text":"
    A naive solution here would be to implement the function as an unconstrained function template:
     
    auto avg_speed(auto distance, auto duration)\n{\n  return distance / duration;\n}\n
     
    Beware, this is not a good solution. The above code is too generic. Such a function template accepts everything:
     
       
    • quantities of other types
         
      • the compiler will not prevent accidental reordering of the function's arguments,
        •  
      • quantities of different types can be passed as well,
        •  
       
      •  
    • plain double arguments,
      •  
    • std::vector and std::lock_guard will be accepted as well (of course, this will fail in the   instantiation of a function's body later in the compilation process).
      •  
     
    Note
     
    The usage of auto instead of a function parameter type is a C++20 feature. It makes such a code a function template where the type of such a parameter will be deduced during the template instantiation process from the argument type passed by the user.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-arguments-with-concepts","title":"Constraining function template arguments with concepts","text":"
    Much better generic code can be implemented using basic concepts provided with the library:
     Original template notationThe shorthand notationTerse notation 
    template<typename Distance, typename Duration>\n  requires QuantityOf<Distance, isq::length> && QuantityOf<Duration, isq::time>\nauto avg_speed(Distance distance, Duration duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    template<QuantityOf<isq::length> Distance, QuantityOf<isq::time> Duration>\nauto avg_speed(Distance distance, Duration duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    auto avg_speed(QuantityOf<isq::length> auto distance,\n               QuantityOf<isq::time> auto duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    This explicitly states that the arguments passed by the user must not only satisfy a Quantity concept, but also their quantity specification must be implicitly convertible to isq::length and isq::time accordingly. This no longer leaves room for error while still allowing the compiler to generate the most efficient code.
     
    Tip
     
    Please note that now it is safe just to use integral types all the way which again improves the runtime performance as the multiplication/division operations are often faster on the integral rather than floating-point types.
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-return-type","title":"Constraining function template return type","text":"
    The above function template resolves all of the issues described before. However, we can do even better here by additionally constraining the return type:
     
    QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto distance,\n                                      QuantityOf<isq::time> auto duration)\n{\n  return isq::speed(distance / duration);\n}\n
     
    Doing so has two important benefits:
     
       
    1. It informs the users of our interface about what to expect to be the result of a function    invocation. It is superior to just returning auto, which does not provide any hint about    the thing being returned there.
      2.  
    2. Such a concept constrains the type returned from the function. This means that it works as    a unit test to verify if our function actually performs what it is supposed to do. If there is    an error in quantity equations, we will learn    about it right away.
      3.  
    "},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-a-variable-on-the-stack","title":"Constraining a variable on the stack","text":"
    If we know precisely what the function does in its internals and if we know the exact argument types passed to such a function, we often know the exact type that will be returned from its invocation.
     
    However, if we care about performance, we should often use the generic interfaces described in this chapter. A side effect is that we sometimes are unsure about the return type. Even if we know it today, it might change a week from now due to some code refactoring.
     
    In such cases, we can again use auto to denote the type:
     
    auto s1 = avg_speed(220 * km, 2 * h);\nauto s2 = avg_speed(140 * mi, 2 * h);\nauto s3 = avg_speed(20 * m, 2 * s);\n
     
    or benefit from CTAD:
     
    quantity s1 = avg_speed(220 * km, 2 * h);\nquantity s2 = avg_speed(140 * mi, 2 * h);\nquantity s3 = avg_speed(20 * m, 2 * s);\n
     
    In both cases, it is probably OK to do so as the avg_speed function name explicitly provides the information on what to expect as a result.
     
    In other scenarios where the returned quantity type is not so obvious, it is again helpful to constrain the type with a concept like so:
     
    QuantityOf<isq::speed> auto s1 = avg_speed(220 * km, 2 * h);\nQuantityOf<isq::speed> auto s2 = avg_speed(140 * mi, 2 * h);\nQuantityOf<isq::speed> auto s3 = avg_speed(20 * m, 2 * s);\n
     
    The above explicitly provides additional information about the quantity we are dealing with in the code, and it serves as a unit test checking if the \"thing\" returned from a function is actually what we expected here.
     
    Note
     
    The QuantityOf and QuantityPointOf concepts are probably the most useful, but there are a few more to play with. A list of all the concepts can be found in the Basic Concepts chapter.
    "},{"location":"users_guide/framework_basics/interface_introduction/","title":"Interface Introduction","text":""},{"location":"users_guide/framework_basics/interface_introduction/#new-style-of-definitions","title":"New style of definitions","text":"
    The mp-units library decided to use a rather unusual pattern to define entities. Here is how we define metre and second SI base units:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\n
     
    Please note that the above reuses the same identifier for a type and its value. The rationale behind this is that:
     
       
    • Users always work with values and never have to spell such a type name.
      •  
    • The types appear in the compilation errors and during debugging.
      •  
     
    Important
     
    To improve compiler errors' readability and make it easier to correlate them with a user's written code, a new idiom in the library is to use the same identifier for a type and its instance.
     
    Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent symbolic expressions simplification of equivalent entities.
    "},{"location":"users_guide/framework_basics/interface_introduction/#strong-types-instead-of-aliases","title":"Strong types instead of aliases","text":"
    Let's look again at the above units definitions. Another important point to notice is that all the types describing entities in the library are short, nicely named identifiers that derive from longer, more verbose class template instantiations. This is really important to improve the user experience while debugging the program or analyzing the compilation error.
     
    Note
     
    Such a practice is rare in the industry. Some popular C++ physical units libraries generate enormously long error messages where even only the first line failed to fit on a slide with a tiny font.
    "},{"location":"users_guide/framework_basics/interface_introduction/#entities-composability","title":"Entities composability","text":"
    Many physical units libraries (in C++ or any other programming language) assign strong types to library entities (e.g., derived units). While metre_per_second as a type may not look too scary, consider, for example, units of angular momentum. If we followed this path, its coherent unit would look like kilogram_metre_sq_per_second. Now, consider how many scaled versions of this unit you would predefine in the library to ensure that all users are happy with your choice? How expensive would it be from the implementation point of view? What about potential future standardization efforts?
     
    This is why in mp-units, we put a strong requirement to make everything as composable as possible. For example, to create a quantity with a unit of speed, one may write:
     
    quantity<si::metre / si::second> q;\n
     
    In case we use such a unit often and would prefer to have a handy helper for it, we can always do something like this:
     
    constexpr auto metre_per_second = si::metre / si::second;\nquantity<metre_per_second> q;\n
     
    or choose any shorter identifier of our choice.
     
    Coming back to the angular momentum case, thanks to the composability of units, a user can create such a quantity in the following way:
     
    using namespace mp_units::si::unit_symbols;\nauto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];\n
     
    It is a much better solution. It is terse and easy to understand. Please also notice how easy it is to obtain any scaled version of such a unit (e.g., mg * square(mm) / min) without having to introduce hundreds of types to predefine them.
    "},{"location":"users_guide/framework_basics/interface_introduction/#value-based-equations","title":"Value-based equations","text":"
    The mp-units library is based on C++20, significantly improving user experience. One of such improvements is the usage of value-based equations.
     
    As we have learned above, the entities are being used as values in the code, and they compose. Moreover, derived entities can be defined in the library using such value-based equations. This is a huge improvement compared to what we can find in other physical units libraries or what we have to deal with when we want to write some equations for std::ratio.
     
    For example, below are a few definitions of the SI derived units showing the power of C++20 extensions to Non-Type Template Parameters, which allow us to directly pass a result of the value-based unit equation to a class template definition:
     
    inline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct pascal final : named_unit<\"Pa\", newton / square(metre)> {} pascal;\ninline constexpr struct joule  final : named_unit<\"J\", newton * metre> {} joule;\n
    "},{"location":"users_guide/framework_basics/interface_introduction/#symbolic-expressions","title":"Symbolic expressions","text":"
    The previous chapter provided a rationale for not having predefined types for derived entities. In many libraries, such an approach results in long and unreadable compilation errors, as framework-generated types are typically far from being easy to read and understand.
     
    The mp-units library greatly improves the user experience by extensively using symbolic expressions. Such expressions are used consistently throughout the entire library to describe the results of:
     
       
    • dimension equation - the result is put into   the derived_dimension<> class template
      •  
    • quantity equation - the result is put into   the derived_quantity_spec<> class template
      •  
    • unit equation - the result is put into the   derived_unit<> class template
      •  
     
    For example, if we take the above-defined base units and put the results of their division into the quantity class template like this:
     
    quantity<metre / second> q;\n
     
    we will observe the following type in the debugger
     
    (gdb) ptype q\ntype = class mp_units::quantity<mp_units::derived_unit<metre, mp_units::per<second>>(), double> [with Rep = double] {\n
     
    The same type identifier will be visible in the compilation error (in case it happens).
     
    Important
     
    Expressions templates are extensively used throughout the library to improve the readability of the resulting types.
    "},{"location":"users_guide/framework_basics/interface_introduction/#identities","title":"Identities","text":"
    As mentioned above, equations can be performed on dimensions, quantities, and units. Each such domain must introduce an identity object that can be used in the resulting expressions. Here is the list of identities used in the library:
     Domain Concept Identity Dimension dimension_one QuantitySpec dimensionless Unit one 
    In the equations, a user can explicitly refer to an identity object. For example:
     
    constexpr auto my_unit = one / second;\n
     
    Note
     
    Another way to achieve the same result is to call an inverse() function:
     
    constexpr auto my_unit = inverse(second);\n
     
    Both cases will result in the same symbolic expression being generated and put into the wrapper class template.
    "},{"location":"users_guide/framework_basics/interface_introduction/#supported-operations-and-their-results","title":"Supported operations and their results","text":"
    There are only a few operations that one can do on such entities, and the result of each of them has its unique representation in the library:
     Operation Resulting template expression arguments A * B A, B B * A A, B A * A power<A, 2> {identity} * A A A * {identity} A A / B A, per<B> A / A {identity} A / {identity} A {identity} / A {identity}, per<A> pow<2>(A) power<A, 2> pow<2>({identity}) {identity} sqrt(A) or pow<1, 2>(A) power<A, 1, 2> sqrt({identity}) or pow<1, 2>({identity}) {identity}"},{"location":"users_guide/framework_basics/interface_introduction/#simplifying-the-resulting-symbolic-expressions","title":"Simplifying the resulting symbolic expressions","text":"
    To limit the length and improve the readability of generated types, there are many rules to simplify the resulting symbolic expression.
     
       
    1.  
      Ordering
       
      The resulting comma-separated arguments of multiplication are always sorted according to a specific predicate. This is why:
       
      static_assert(A * B == B * A);\nstatic_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);\n
       
      This is probably the most important of all the steps, as it allows comparing types and enables the rest of the simplification rules.
       
      2.  
    2.  
      Aggregation
       
      In case two of the same identifiers are found next to each other on the argument list they will be aggregated in one entry:
       Before After A, A power<A, 2> A, power<A, 2> power<A, 3> power<A, 1, 2>, power<A, 2> power<A, 5, 2> power<A, 1, 2>, power<A, 1, 2> A 
      3.  
    3.  
      Simplification
       
      In case two of the same identifiers are found in the numerator and denominator argument lists; they are being simplified into one entry:
       Before After A, per<A> {identity} power<A, 2>, per<A> A power<A, 3>, per<A> power<A, 2> A, per<power<A, 2>> {identity}, per<A> 
      It is important to notice here that only the elements with exactly the same type are being simplified. This means that, for example, m/m results in one, but km/m will not be simplified. The resulting derived unit will preserve both symbols and their relative magnitude. This allows us to properly print symbols of some units or constants that require such behavior. For example, the Hubble constant is expressed in km\u22c5s\u207b\u00b9\u22c5Mpc\u207b\u00b9, where both km and Mpc are units of length.
       
      Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent symbolic expression simplification of equivalent entities.
       
      4.  
    4.  
      Repacking
       
      In case an expression uses two results of other operations, the components of its arguments are repacked into one resulting type and simplified there.
       
      For example, assuming:
       
      constexpr auto X = A / B;\n
       
      then:
       Operation Resulting template expression arguments X * B A X * A power<A, 2>, per<B> X * X power<A, 2>, per<power<B, 2>> X / X {identity} X / A {identity}, per<B> X / B A, per<power<B, 2>> 
      5.  
    "},{"location":"users_guide/framework_basics/interface_introduction/#example","title":"Example","text":"
    Thanks to all of the features described above, a user may write the code like this one:
     
    using namespace mp_units::si::unit_symbols;\nquantity speed = 60. * isq::speed[km / h];\nquantity duration = 8 * s;\nquantity acceleration = speed / duration;\nstd::cout << \"acceleration: \" << acceleration << \" (\" << acceleration.in(m / s2) << \")\\n\";\n
     
    The acceleration quantity, being the result of the above code, has the following type (after stripping the mp_units namespace for brevity):
     
    quantity<reference<derived_quantity_spec<isq::speed, per<isq::time>>{}, derived_unit<si::kilo_<si::metre{}>, per<non_si::hour, si::second>>{}>{}, int>\n
     
    and the text output presents:
     
    acceleration: 7.5 km h\u207b\u00b9 s\u207b\u00b9 (2.08333 m/s\u00b2)\n
    "},{"location":"users_guide/framework_basics/obtaining_metadata/","title":"Obtaining Metadata","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#quantity-spec","title":"quantity spec","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#unit","title":"unit","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#reference","title":"reference","text":""},{"location":"users_guide/framework_basics/obtaining_metadata/#quantity","title":"quantity","text":""},{"location":"users_guide/framework_basics/quantity_arithmetics/","title":"Quantity Arithmetics","text":""},{"location":"users_guide/framework_basics/quantity_arithmetics/#quantity-is-a-numeric-wrapper","title":"quantity is a numeric wrapper","text":"
    If we think about it, the quantity class template is just a \"smart\" numeric wrapper. It exposes properly constrained set of arithmetic operations on one or two operands.
     
    Important: quantity propagates the underlying interface
     
    Every single arithmetic operator is exposed by the quantity class template only if the underlying representation type provides it as well, and when its implementation has proper semantics (e.g., returns a reasonable type).
     
    For example, in the following code, -a will compile only if MyInt exposes such an operation as well:
     
    quantity a = MyInt{42} * m;\nquantity b = -a;\n
     
    Assuming that:
     
       
    • q is our quantity,
      •  
    • qi is a quantity implicitly convertible to q,
      •  
    • qk is a quantity of the same kind as q,
      •  
    • q1 is a quantity of dimension_one with the unit one,
      •  
    • qq is any other quantity,
      •  
    • number is a value of a type \"compatible\" with q's representation type,
      •  
     
    here is the list of all the supported operators:
     
       
    • unary:
         
      • +q
        •  
      • -q
        •  
      • ++q
        •  
      • q++
        •  
      • --q
        •  
      • q--
        •  
       
      •  
    • compound assignment:
         
      • q += qi
        •  
      • q -= qi
        •  
      • q %= qi
        •  
      • q *= number
        •  
      • q *= q1
        •  
      • q /= number
        •  
      • q /= q1
        •  
       
      •  
    • binary:
         
      • q + qk
        •  
      • q - qk
        •  
      • q % qk
        •  
      • q * qq
        •  
      • q * number
        •  
      • number * q
        •  
      • q / qq
        •  
      • q / number
        •  
      • number / q
        •  
       
      •  
    • ordering and comparison:
         
      • q == qk
        •  
      • q <=> qk
        •  
       
      •  
     
    As we can see, there are plenty of operations one can do on a value of a quantity type. As most of them are obvious, in the following chapters, we will discuss only the most important or non-trivial aspects of quantity arithmetics.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#addition-and-subtraction","title":"Addition and subtraction","text":"
    Quantities can easily be added or subtracted from each other:
     
    static_assert(1 * m + 1 * m == 2 * m);\nstatic_assert(2 * m - 1 * m == 1 * m);\nstatic_assert(isq::height(1 * m) + isq::height(1 * m) == isq::height(2 * m));\nstatic_assert(isq::height(2 * m) - isq::height(1 * m) == isq::height(1 * m));\n
     
    The above uses the same types for LHS, RHS, and the result, but in general, we can add, subtract, or compare the values of any quantity type as long as both quantities are of the same kind. The result of such an operation will be the common type of the arguments:
     
    static_assert(1 * km + 1.5 * m == 1001.5 * m);\nstatic_assert(isq::height(1 * m) + isq::width(1 * m) == isq::length(2 * m));\nstatic_assert(isq::height(2 * m) - isq::distance(0.5 * m) == 1.5 * m);\nstatic_assert(isq::radius(1 * m) - 0.5 * m == isq::radius(0.5 * m));\n
     
    Note
     
    Please note that for the compound assignment operators, we always need to end up with the left-hand-side argument type:
     
    static_assert((1 * m += 1 * km) == 1001 * m);\nstatic_assert((isq::length(1 * m) += isq::height(1 * m)) == isq::length(1 * m));\nstatic_assert((isq::height(1.5 * m) -= 1 * m) == isq::height(0.5 * m));\n
     
    If we will break typical library's convertibility rules, the following code will not compile:
     
    quantity q1 = 1 * m -= 0.5 * m;                         // Compile-time error(1)\nquantity q2 = 1 * km += 1 * m;                          // Compile-time error(2)\nquantity q3 = isq::height(1 * m) += isq::length(1 * m); // Compile-time error(3)\n
     
       
    1. Conversion of the floating-point to integral representation type is    considered narrowing.
      2.  
    2. Conversion of quantity with integral representation type from a unit of a higher resolution    to the one with a lower resolution is considered narrowing.
      3.  
    3. Conversion from a more generic quantity type to a more specific one is    considered unsafe.
      4.  
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#multiplication-and-division","title":"Multiplication and division","text":"
    Multiplying or dividing a quantity by a number does not change its quantity type or unit. However, its representation type may change. For example:
     
    static_assert(isq::height(3 * m) * 0.5 == isq::height(1.5 * m));\n
     
    Note
     
    Unless we use a compound assignment operator, in which case we always have to result with the type of the left-hand-side argument. This, together with the fact that this library tries to prevent truncation of a quantity value means, that the following does not compile:
     
    quantity q = isq::height(3 * m) *= 0.5; // Compile-time error\n
     
    However, suppose we multiply or divide quantities of the same or different types or we divide a raw number by a quantity. In that case, we most probably will end up in a quantity of yet another type:
     
    static_assert(120 * km / (2 * h) == 60 * km / h);\nstatic_assert(isq::width(2 * m) * isq::length(2 * m) == isq::area(4 * m2));\nstatic_assert(50 / isq::time(1 * s) == isq::frequency(50 * Hz));\n
     
    Note
     
    An exception from the above rule happens when one of the arguments is a dimensionless quantity. If we multiply or divide by such a quantity, the quantity type will not change. If such a quantity has a unit one, also the unit of a quantity will not change:
     
    static_assert(120 * m / (2 * one) == 60 * m);\n
     
    An interesting special case happens when we divide the same quantity kinds or multiply a quantity by its inverted type. In such a case, we end up with a dimensionless quantity.
     
    static_assert(isq::height(4 * m) / isq::width(2 * m) == 2 * one); // (1)!\nstatic_assert(5 * h / (120 * min) == 0 * one);  // (2)!\nstatic_assert(5. * h / (120 * min) == 2.5 * one);\n
     
       
    1. The resulting quantity type of the LHS is isq::height / isq::width, which is a quantity of the dimensionless kind.
      2.  
    2. The resulting quantity of the LHS is 0 * dimensionless[h / min]. To be consistent with the division of different quantity types, we do not convert quantity values to a common unit before the division.
      3.  
     
    Important: Beware of integral division
     
    The physical units library can't do any runtime branching logic for the division operator. All logic must be done at compile-time when the actual values are unknown, and the quantity types can't change at runtime.
     
    If we expect 120 * km / (2 * h) to return 60 km / h, we have to agree with the fact that 5 * km / (24 * h) returns 0 km/h. We can't do a range check at runtime to dynamically adjust scales and types based on the values of provided function arguments.
     
    This is why we often prefer floating-point representation types when dealing with units. Some popular physical units libraries even forbid integer division at all.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#modulo","title":"Modulo","text":"
    Now that we know how addition, subtraction, multiplication, and division work, it is time to discuss modulo. What would we expect to be returned from the following quantity equation?
     
    auto q = 5 * h % (120 * min);\n
     
    Most of us would probably expect to see 1 h or 60 min as a result. And this is where the problems start.
     
    C++ language defines its / and % operators with the quotient-remainder theorem:
     
    q = a / b;\nr = a % b;\nq * b + r == a;\n
     
    The important property of the modulo operation is that it only works for integral representation types (it is undefined what modulo for floating-point types means). However, as we saw in the previous chapter, integral types are tricky because they often truncate the value.
     
    From the quotient-remainder theorem, the result of modulo operation is r = a - q * b. Let's see what we get from such a quantity equation on integral representation types:
     
    const quantity a = 5 * h;\nconst quantity b = 120 * min;\nconst quantity q = a / b;\nconst quantity r = a - q * b;\n\nstd::cout << \"reminder: \" << r << \"\\n\";\n
     
    The above code outputs:
     
    reminder: 5 h\n
     
    And now, a tough question needs an answer. Do we really want modulo operation on physical units to be consistent with the quotient-remainder theorem and return 5 h for 5 * h % (120 * min)?
     
    This is exactly why we decided not to follow this hugely surprising path in the mp-units library. The selected approach was also consistent with the feedback from the C++ experts. For example, this is what Richard Smith said about this issue:
     
    Richard Smith
     
    I think the quotient-remainder property is a less important motivation here than other factors -- the constraints on % and / are quite different, so they lack the inherent connection they have for integers. In particular, I would expect that A / B works for all quantities A and B, whereas A % B is only meaningful when A and B have the same dimension. It seems like a nice-to-have for the property to apply in the case where both / and % are defined, but internal consistency of / across all cases seems much more important to me.
     
    I would expect 61 min % 1 h to be 1 min, and 1 h % 59 min to also be 1 min, so my intuition tells me that the result type of A % B, where A and B have the same dimension, should have the smaller unit of A and B (and if the smaller one doesn't divide the larger one, we should either use the gcd / std::common_type of the units of A and B or perhaps just produce an error). I think any other behavior for % is hard to defend.
     
    On the other hand, for division it seems to me that the choice of unit should probably not affect the result, and so if we want that 5 mm / 120 min = 0 mm/min, then 5 h / 120 min == 0 hc (where hc is a dimensionless \"hexaconta\", or 60x, unit). I don't like the idea of taking SI base units into account; that seems arbitrary and like it would do the wrong thing as often as it does the right thing, especially when the units have a multiplier that is very large or small. We could special-case the situation of a dimensionless quantity, but that could lead to problematic overflow pretty easily: a calculation such as 10 s * 5 GHz * 2 uW would overflow an int if it produces a dimensionless quantity for 10 s * 5 GHz, but it could equally produce 50 G * 2 uW = 100 kW without any overflow, and presumably would if the terms were merely reordered.
     
    If people want to use integer-valued quantities, I think it's fundamental that you need to know what the units of the result of an operation will be, and take that into account in how you express computations; the simplest rule for heterogeneous operators like * or / seems to be that the units of the result are determined by applying the operator to the units of the operands -- and for homogeneous operators like + or %, it seems like the only reasonable option is that you get the std::common_type of the units of the operands.
     
    To summarize, the modulo operation on physical units has more in common with addition and division operators than with the quotient-remainder theorem. To avoid surprising results, the operation uses a common unit to do the calculation and provide its result:
     
    static_assert(5 * h / (120 * min) == 0 * one);\nstatic_assert(5 * h % (120 * min) == 60 * min);\nstatic_assert(61 * min % (1 * h) == 1 * min);\nstatic_assert(1 * h % (59 * min) == 1 * min);\n
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#comparison-against-zero","title":"Comparison against zero","text":"
    In our code, we often want to compare the value of a quantity against zero. For example, we do it every time we want to ensure that we deal with a non-zero or positive value.
     
    We could implement such checks in the following way:
     
    if (q1 / q2 != 0 * m / s)\n  // ...\n
     
    The above would work (assuming we are dealing with the quantity of speed) but could be suboptimal if the result of q1 / q2 is not expressed in m / s. To eliminate the need for conversion, we need to write:
     
    if (auto q = q1 / q2; q != q.zero())\n  // ...\n
     
    but that is a bit inconvenient, and inexperienced users could be unaware of this technique and its reasons.
     
    For the above reasons, the library provides dedicated interfaces to compare against zero that follow the naming convention of named comparison functions in the C++ Standard Library. The mp-units/compare.h header file exposes the following functions:
     
       
    • is_eq_zero
      •  
    • is_neq_zero
      •  
    • is_lt_zero
      •  
    • is_gt_zero
      •  
    • is_lteq_zero
      •  
    • is_gteq_zero
      •  
     
    Thanks to them, to save typing and not pay for unneeded conversions, our check could be implemented as follows:
     
    if (is_neq_zero(q1 / q2))\n  // ...\n
     
    Tip
     
    Those functions will work with any type T that exposes zero() member function returning something comparable to T. Thanks to that, we can use them not only with quantities but also with std::chrono::duration or any other type that exposes such an interface.
    "},{"location":"users_guide/framework_basics/quantity_arithmetics/#other-maths","title":"Other maths","text":"
    This chapter scopes only on the quantity type's operators. However, there are many named math functions taking quantities as arguments. Those can be found in the mp-units/math.h header file. Among others, we can find there the following:
     
       
    • pow(), sqrt(), cbrt(),
      •  
    • exp(),
      •  
    • abs(),
      •  
    • epsilon(),
      •  
    • fma(), fmod(), remainder(),
      •  
    • isfinite(), isinf(), isnan(),
      •  
    • floor(), ceil(), round(),
      •  
    • inverse(),
      •  
    • hypot(),
      •  
    • sin(), cos(), tan(),
      •  
    • asin(), acos(), atan(), atan2().
      •  
     
    In the library, we can also find mp-units/random.h header file with all the pseudo-random number generators working on quantity types.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/","title":"Simple and Typed Quantities","text":"
    ISO defines a quantity as:
     
    Quote
     
    property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
     
    After that, it says:
     
    Quote
     
    A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-class-template","title":"quantity class template","text":"
    In the mp-units library, a quantity is represented with the following class template:
     
    template<Reference auto R,\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity;\n
     
    The concept Reference is satisfied by a type that provides all the domain-specific metadata describing a quantity (besides the representation type and its value). Such a type can be either:
     
       
    • a unit with an associated quantity type (e.g., si::metre, m / s),
      •  
    • a reference type explicitly specifying the quantity type and its unit.
      •  
     
    Important
     
    All units in the SI system have an associated quantity type.
     
    A reference type is implicitly created as a result of the following expression:
     
    constexpr auto ref = isq::length[m];\n
     
    The above example results in the following type reference<isq::length(), si::metre()> being instantiated.
     
    As we have two alternative options that satisfy the Reference concept in the mp-units library, we also have two modes of dealing with quantities.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#simple-quantities","title":"Simple quantities","text":"
    The simple mode might be preferred by many developers. It is all about units. Quantities using this mode have shorter type identifiers, resulting in easier-to-understand error messages and better debugging experience.
     
    Here is a simple example showing how to deal with such quantities:
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = 110 * km;\n  const quantity duration = 2 * h;\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = 110 * km;\n  const quantity duration = 2 * h;\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    The code above prints:
     
    A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\n
     
    Try it on Compiler Explorer
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#user-provided-unit-wrappers","title":"User-provided unit wrappers","text":"
    Sometimes it might be awkward to type some derived units:
     
    quantity speed = 60 * km / h;\n
     
    In case such a unit is used a lot in the project, a user can easily provide a nicely named wrapper for it with:
     
    constexpr auto kmph = km / h;\nquantity speed = 60 * kmph;\n
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#easy-to-understand-compilation-error-messages","title":"Easy-to-understand compilation error messages","text":"
    In case a user makes an error in a quantity equation and the result of the calculation will not match the function return type, the compiler will detect such an issue at compile-time.
     
    For example, in case we will make the following error:
     
    constexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n                                                     quantity<si::second> time)\n{\n  return dist * time;  // (1)!\n}\n
     
       
    1. Quantities multiplied (instead of divided) by accident.
      2.  
     
    the following compilation error message will be provided:
     
    error: no viable conversion from returned value of type\n       'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::si::second>{{{}}}, [...]>'\n       to function return type\n       'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::per<mp_units::si::second>>{{{}}}, [...]>'\n   10 |   return dist * time;\n      |          ^~~~~~~~~~~\n
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#typed-quantities","title":"Typed quantities","text":"
    Simple mode is all about and just about units. Typed quantities should be preferred if we also want to be quantity-safe. This, for example, allows us to specify if we deal with width, height, or radius and ensure we will not assign one to another by accident.
     
    The previous example can be re-typed using typed quantities in the following way:
     C++ modulesHeader files 
    #include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n                                                                 quantity<isq::time[si::second]> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = isq::distance(110 * km);\n  const quantity duration = isq::time(2 * h);\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    #include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n                                                                 quantity<isq::time[si::second]> time)\n{\n  return dist / time;\n}\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n\n  const quantity distance = isq::distance(110 * km);\n  const quantity duration = isq::time(2 * h);\n  const quantity speed = avg_speed(distance, duration);\n\n  std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n               distance, duration, speed, speed.in(km / h));\n}\n
     
    A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\n
     
    Try it on Compiler Explorer
     
    In case we will accidentally make the same calculation error as before, this time, we will get a bit longer error message, this time also containing information about the quantity type:
     
    error: no viable conversion from returned value of type\n       'quantity<reference<get_quantity_spec(metre{}) * struct time{{{}}}, metre{} * second{{}}>{}, [...]>'\n       to function return type\n       'quantity<reference<speed{}, derived_unit<metre, per<second>>{}>{}, [...]>'\n   12 |   return dist * time;\n      |          ^~~~~~~~~~~\n
     
    As we can see above, the compilation error is longer but still relatively easy to understand.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-safety-with-typed-quantities","title":"Quantity-safety with typed quantities","text":"
    Based on the previous example, it might seem that typed quantities are not that useful, more to type and provide harder-to-understand error messages. It might be true in some cases, but there are scenarios where they offer additional level of safety.
     
    Let's see another example:
     C++ modulesHeader files SimpleTyped 
    #include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\nclass StorageTank {\n  quantity<square(si::metre)> base_;\n  quantity<si::metre> height_;\npublic:\n  constexpr StorageTank(const quantity<square(si::metre)>& base,\n                        const quantity<si::metre>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n                                   const quantity<si::metre>& height) :\n    StorageTank(std::numbers::pi * pow<2>(radius), height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<si::metre>& length,\n                                   const quantity<si::metre>& width,\n                                   const quantity<si::metre>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n  // ...\n}\n
     
    #include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n    quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n    quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n  quantity<horizontal_area[square(si::metre)]> base_;\n  quantity<isq::height[si::metre]> height_;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n                        const quantity<isq::height[si::metre]>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n                                   const quantity<isq::width[si::metre]>& width,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                     isq::width(500 * mm),\n                                     isq::height(200 * mm));\n  // ...\n}\n
     SimpleTyped 
    #include <mp-units/math.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\nclass StorageTank {\n  quantity<square(si::metre)> base_;\n  quantity<si::metre> height_;\npublic:\n  constexpr StorageTank(const quantity<square(si::metre)>& base,\n                        const quantity<si::metre>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n                                   const quantity<si::metre>& height) :\n    StorageTank(std::numbers::pi * pow<2>(radius), height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<si::metre>& length,\n                                   const quantity<si::metre>& width,\n                                   const quantity<si::metre>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n  // ...\n}\n
     
    #include <mp-units/math.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n    quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n    quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n  quantity<horizontal_area[square(si::metre)]> base_;\n  quantity<isq::height[si::metre]> height_;\npublic:\n  constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n                        const quantity<isq::height[si::metre]>& height) :\n    base_(base), height_(height)\n  {\n  }\n\n  // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n                                   const quantity<isq::width[si::metre]>& width,\n                                   const quantity<isq::height[si::metre]>& height) :\n    StorageTank(length * width, height)\n  {\n  }\n};\n\nint main()\n{\n  using namespace mp_units::si::unit_symbols;\n  auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                     isq::width(500 * mm),\n                                     isq::height(200 * mm));\n  // ...\n}\n
     
    In the above example, the highlighted call doesn't look that safe anymore in the case of simple quantities, right? Suppose someone, either by mistake or due to some refactoring, will call the function with an invalid order of arguments. In that case, the program will compile fine but not work as expected.
     
    Let's see what will happen if we reorder the arguments in the case of typed quantities:
     
    auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n                                   isq::height(200 * mm),\n                                   isq::width(500 * mm));\n
     
    This time, a compiler provides the following compilation error:
     
    <source>:53:15: error: no matching constructor for initialization of 'RectangularStorageTank'\n   53 |   auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n      |               ^                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n   54 |                                      isq::height(200 * mm),\n      |                                      ~~~~~~~~~~~~~~~~~~~~~~\n   55 |                                      isq::width(500 * mm));\n      |                                      ~~~~~~~~~~~~~~~~~~~~\n<source>:43:13: note: candidate constructor not viable: no known conversion from\n                'quantity<mp_units::reference<mp_units::isq::height{{{{{}}}}},\n                                              mp_units::si::milli_<mp_units::si::metre{{}}>{{{{}}}}>{}, int>' to\n                'const quantity<reference<width{}, metre{}>{}, (default) double>' for 2nd argument\n   43 |   constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n      |             ^\n   44 |                                    const quantity<isq::width[m]>& width,\n      |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n
     
    What about derived quantities? In the above example, you probably noticed that we also defined a custom horizontal_area quantity of kind isq::area. This quantity has the unique property of being implicitly constructible only from the result of the multiplication of quantities of horizontal_area and isq::width or the ones that implicitly convert to them.
     
    Based on the above error message, we already know that a quantity of isq::height is not implicitly constructible to the quantity of isq::width. This property is transitively passed to derived quantities using them. If by accident, we will try to create a StorageTank base class in the following way:
     
    class RectangularStorageTank : public StorageTank {\npublic:\n  constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n                                   const quantity<isq::width[m]>& width,\n                                   const quantity<isq::height[m]>& height) :\n    StorageTank(length * height, height)\n  {\n  }\n};\n
     
    we will again get a compilation error message like this one:
     
    error: no matching constructor for initialization of 'StorageTank'\n   46 |     StorageTank(length * height, height)\n      |     ^           ~~~~~~~~~~~~~~~~~~~~~~~\n<source>:22:13: note: candidate constructor not viable: no known conversion from\n                'quantity<mp_units::reference<mp_units::derived_quantity_spec<horizontal_length, mp_units::isq::height>{{}, {{}}},\n                                              mp_units::derived_unit<mp_units::power<mp_units::si::metre, 2>>{{{}}}>{}, [...]>' to\n                'const quantity<reference<horizontal_area{}, derived_unit<power<metre, 2>>{}>{}, [...]>' for 1st argument\n   22 |   constexpr StorageTank(const quantity<horizontal_area[m2]>& base,\n      |             ^           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n
     
    Tip
     
    If you need to use various quantities of the same kind, consider using typed quantities to bring an additional level of safety to your project.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity_cast-to-force-unsafe-conversions","title":"quantity_cast() to force unsafe conversions","text":"
    Did you notice the quantity_cast() usage in the other child class?
     
    class CylindricalStorageTank : public StorageTank {\npublic:\n  constexpr CylindricalStorageTank(const quantity<isq::radius[m]>& radius,\n                                   const quantity<isq::height[m]>& height) :\n    StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n                height)\n  {\n  }\n};\n
     
    As isq::radius is not convertible to horizontal_length, the derived quantity of pow<2>(radius) can't be converted to horizontal_area as well. It would be unsafe to allow such a conversion as not all of the circles lie flat on the ground, right?
     
    In such a case, the user has to explicitly force such an unsafe conversion with the help of a quantity_cast(). This function name is easy to spot in code reviews or while searching the project for problems if something goes sideways. In case of unexpected quantities-related issues, this should be the first function to look for.
     
    Tip
     
    Do not overuse quantity_cast(). Use it only when necessary and ensure that the requested conversion is exactly what you need in this case.
    "},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#which-mode-should-i-use-in-my-project","title":"Which mode should I use in my project?","text":"
    We have good news for you if you wonder which mode you should choose for your project. Simple and typed quantity modes can be freely mixed with each other. When you use different quantities of the same kind (e.g., radius, wavelength, altitude, ...), you should probably reach for typed quantities to bring additional safety for those cases. Otherwise, just use simple mode for the remaining quantities. The mp-units library will do its best to protect your project based on the information provided.
     
    Tip
     
    You can easily mix simple and typed quantities in your project.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/","title":"Systems of Quantities","text":"
    The physical units libraries on the market typically only scope on modeling one or more systems of units. However, this is not the only system kind to model. Another, and maybe even more important, system kind is a system of quantities.
     
    Info
     
    Please note that the mp-units is probably the first library on the Open Source market (in any programming language) that models the ISQ with all its definitions provided in ISO 80000. Please provide feedback if something looks odd or could be improved.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"
    Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. For example, let's see the following implementation:
     
    class Box {\n  area base_;\n  length height_;\npublic:\n  Box(length l, length w, length h) : base_(l * w), height_(h) {}\n  // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\n
     
    How do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do 
     
    Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are different quantities.
     
    A similar issue is related to figuring out what should be the result of:
     
    auto res = 1 * Hz + 1 * Bq + 1 * Bd;\n
     
    where:
     
       
    • Hz (hertz) - unit of frequency
      •  
    • Bq (becquerel) - unit of activity
      •  
    • Bd (baud) - unit of modulation rate
      •  
     
    All of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
     
    If the above example seems too abstract, let's consider a fuel consumption (fuel volume divided by distance, e.g., 6.7 l/km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
     
    Important
     
    More than one quantity may be defined for the same dimension:
     
       
    • quantities of different kinds (e.g. frequency, modulation rate, activity, ...)
      •  
    • quantities of the same kind (e.g. length, width, altitude, distance, radius,   wavelength, position vector, ...)
      •  
     
    It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"
    ISO 80000-1
     
       
    • Quantities may be grouped together into categories of quantities that are   mutually comparable
      •  
    • Mutually comparable quantities are called quantities of the same kind
      •  
    • Two or more quantities cannot be added or subtracted unless they belong to the same category   of mutually comparable quantities
      •  
    • Quantities of the same kind within a given system of quantities have the same quantity   dimension
      •  
    • Quantities of the same dimension are not necessarily of the same kind
      •  
     
    The above quotes from ISO 80000 provide answers to all the issues above. Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are of different kinds, the expression provided above should not compile.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"
    ISO 80000 specify hundreds of different quantities. There are plenty of different kinds provided and often each kind contains more than one quantity. In fact, it turns out that such quantities form a hierarchy of quantities of the same kind.
     
    For example, here are all quantities of the kind length provided in the ISO 80000:
     
    flowchart TD\n    length[\"<b>length</b><br>[m]\"]\n    length --- width[\"<b>width</b> / <b>breadth</b>\"]\n    length --- height[\"<b>height</b> / <b>depth</b> / <b>altitude</b>\"]\n    width --- thickness[\"<b>thickness</b>\"]\n    width --- diameter[\"<b>diameter</b>\"]\n    width --- radius[\"<b>radius</b>\"]\n    length --- path_length[\"<b>path_length</b>\"]\n    path_length --- distance[\"<b>distance</b>\"]\n    distance --- radial_distance[\"<b>radial_distance</b>\"]\n    length --- wavelength[\"<b>wavelength</b>\"]\n    length --- displacement[\"<b>displacement</b><br>{vector}\"]\n    displacement --- position_vector[\"<b>position_vector</b>\"]\n    radius --- radius_of_curvature[\"<b>radius_of_curvature</b>\"]
     
    Each of the above quantities expresses some kind of length, and each can be measured with si::metre. However, each of them has different properties, usage, and sometimes even requires a different representation type (notice that position_vector and displacement are vector quantities).
     
    Forming such a hierarchy helps us in defining arithmetics and conversion rules for various quantities of the same kind.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#defining-quantities","title":"Defining quantities","text":"
    In the mp-units library all the information about the quantity is provided with the quantity_spec class template. In order to define a specific quantity a user should inherit a strong type from such an instantiation.
     
    Tip
     
    Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code. However, as C++23 is far from being mainstream today, a portability macro QUANTITY_SPEC() is provided and used consistently through the library to allow the code to compile with C++20 compilers, thanks to the CRTP usage under the hood.
     
    See more in the C++ compiler support chapter.
     
    For example, here is how the above quantity kind tree can be modeled in the library:
     C++23C++20Portable 
    inline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct width final : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<width> {} diameter;\ninline constexpr struct radius final : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<length> {} wavelength;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<displacement> {} position_vector;\n
     
    inline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct width final : quantity_spec<width, length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<thickness, width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<diameter, width> {} diameter;\ninline constexpr struct radius final : quantity_spec<radius, width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius_of_curvature, radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<path_length, length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<distance, path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<radial_distance, distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<wavelength, length> {} wavelength;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, displacement> {} position_vector;\n
     
    QUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(width, length);\ninline constexpr auto breadth = width;\nQUANTITY_SPEC(height, length);\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\nQUANTITY_SPEC(thickness, width);\nQUANTITY_SPEC(diameter, width);\nQUANTITY_SPEC(radius, width);\nQUANTITY_SPEC(radius_of_curvature, radius);\nQUANTITY_SPEC(path_length, length);\ninline constexpr auto arc_length = path_length;\nQUANTITY_SPEC(distance, path_length);\nQUANTITY_SPEC(radial_distance, distance);\nQUANTITY_SPEC(wavelength, length);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nQUANTITY_SPEC(position_vector, displacement);\n
     
    Note
     
    More information on how to define a system of quantities can be found in the \"International System of Quantities (ISQ)\" chapter.
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#comparing-adding-and-subtracting-quantities","title":"Comparing, adding, and subtracting quantities","text":"
    ISO 80000 explicitly states that width and height are quantities of the same kind, and as such they:
     
       
    • are mutually comparable,
      •  
    • can be added and subtracted.
      •  
     
    If we take the above for granted, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
     
    static_assert(get_common_quantity_spec(isq::width, isq::height) == isq::length);\nstatic_assert(get_common_quantity_spec(isq::thickness, isq::radius) == isq::width);\nstatic_assert(get_common_quantity_spec(isq::distance, isq::path_length) == isq::path_length);\n
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#converting-between-quantities","title":"Converting between quantities","text":"
    Based on the same hierarchy of quantities of kind length, we can define quantity conversion rules.
     
       
    1.  
      Implicit conversions
       
         
      • every width is a length
        •  
      • every radius is a width
        •  
       
      static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\n
       
      2.  
    2.  
      Explicit conversions
       
         
      • not every length is a width
        •  
      • not every width is a radius
        •  
       
      static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\n
       
      3.  
    3.  
      Explicit casts
       
         
      • height is not a width
        •  
      • both height and width are quantities of kind length
        •  
       
      static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\n
       
      4.  
    4.  
      No conversion
       
         
      • time has nothing in common with length
        •  
       
      static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\n
       
      5.  
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#hierarchies-of-derived-quantities","title":"Hierarchies of derived quantities","text":"
    Derived quantity equations often do not automatically form a hierarchy tree. This is why it is sometimes not obvious what such a tree should look like. Also, ISO explicitly states:
     
    ISO/IEC Guide 99
     
    The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
     
    The below presents some arbitrary hierarchy of derived quantities of kind energy:
     
    flowchart TD\n    energy[\"<b>energy</b><br><i>(mass * length<sup>2</sup> / time<sup>2</sup>)</i><br>[J]\"]\n    energy --- mechanical_energy[\"<b>mechanical_energy</b>\"]\n    mechanical_energy --- potential_energy[\"<b>potential_energy</b>\"]\n    potential_energy --- gravitational_potential_energy[\"<b>gravitational_potential_energy</b><br><i>(mass * acceleration_of_free_fall * height)</i>\"]\n    potential_energy --- elastic_potential_energy[\"<b>elastic_potential_energy</b><br><i>(spring_constant * amount_of_compression<sup>2</sup>)</i>\"]\n    mechanical_energy --- kinetic_energy[\"<b>kinetic_energy</b><br><i>(mass * speed<sup>2</sup>)</i>\"]\n    energy --- enthalpy[\"<b>enthalpy</b>\"]\n    enthalpy --- internal_energy[\"<b>internal_energy</b> / <b>thermodynamic_energy</b>\"]\n    internal_energy --- Helmholtz_energy[\"<b>Helmholtz_energy</b> / <b>Helmholtz_function</b>\"]\n    enthalpy --- Gibbs_energy[\"<b>Gibbs_energy</b> / <b>Gibbs_function</b>\"]\n    energy --- active_energy[\"<b>active_energy</b>\"]
     
    Notice, that even though all of those quantities have the same dimension and can be expressed in the same units, they have different quantity equations that can be used to create them implicitly:
     
       
    •  
      energy is the most generic one and thus can be created from base quantities of mass, length,   and time. As those are also the roots of quantities of their kinds and all other quantities from their   trees are implicitly convertible to them (we agreed on that \"every width is a length\" already),   it means that an energy can be implicitly constructed from any quantity of mass, length, and time:
       
      static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\n
       
      •  
    •  
      mechanical energy is a more \"specialized\" quantity than energy (not every energy is   a mechanical energy). It is why an explicit cast is needed to convert from either energy or   the results of its quantity equation:
       
      static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     isq::mechanical_energy));\n
       
      •  
    •  
      gravitational potential energy is not only even more specialized one but additionally,   it is special in a way that it provides its own \"constrained\"   quantity equation. Maybe not every   mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every   mass * acceleration_of_free_fall * height is.
       
      static_assert(!implicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                      gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n                                     gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n                                     gravitational_potential_energy));\n
       
      •  
    "},{"location":"users_guide/framework_basics/systems_of_quantities/#modeling-a-quantity-kind","title":"Modeling a quantity kind","text":"
    In the physical units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
     
    To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
     
    Important
     
    isq::length and kind_of<isq::length> are two different things.
     
    Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
     
    static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\n
     
    Additionally, the result of operations on quantity kinds is also a quantity kind:
     
    static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\n
     
    However, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
     
    static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\n
     
    Info
     
    Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
     
    static_assert(get_kind(isq::width) == kind_of<isq::length>);\n
    "},{"location":"users_guide/framework_basics/systems_of_units/","title":"Systems of Units","text":"
    Modeling a system of units is probably the most important feature and a selling point of every physical units library. Thanks to that, the library can protect users from performing invalid operations on quantities and provide automated conversion factors between various compatible units.
     
    Probably all the libraries in the wild model the SI and many of them provide support for additional units belonging to various other systems (e.g., imperial, cgs, etc).
    "},{"location":"users_guide/framework_basics/systems_of_units/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of Units are based on Systems of Quantities","text":"
    Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. To create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
     
    The SI is explicitly stated to be based on the ISQ. Among others, it defines 7 base units, one for each base quantity. In the mp-units this is expressed by associating a quantity kind (that we discussed in detail in the previous chapter) with a unit that is used to express it:
     
    inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\n
     
    Important
     
    The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
    "},{"location":"users_guide/framework_basics/systems_of_units/#units-compose","title":"Units compose","text":"
    One of the most vital points of the SI system is that its units compose. This allows providing thousands of different units for hundreds of various quantities with a tiny set of predefined units and prefixes.
     
    The same is modeled in the mp-units library, which also allows composing predefined units to create a nearly infinite number of different derived units. For example, one can write:
     
    quantity<si::metre / si::second> q;\n
     
    to express a quantity of speed. The resulting quantity type is implicitly inferred from the unit equation by repeating the same operations on the associated quantity kinds.
    "},{"location":"users_guide/framework_basics/systems_of_units/#many-shades-of-the-same-unit","title":"Many shades of the same unit","text":"
    The SI provides the names for 22 common coherent units of 22 derived quantities.
     
    Each such named derived unit is a result of a specific predefined unit equation. For example, a unit of power quantity is defined in the library as:
     
    inline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\n
     
    However, a power quantity can be expressed in other units as well. For example, the following:
     
    auto q1 = 42 * W;\nstd::cout << q1 << \"\\n\";\nstd::cout << q1.in(J / s) << \"\\n\";\nstd::cout << q1.in(N * m / s) << \"\\n\";\nstd::cout << q1.in(kg * m2 / s3) << \"\\n\";\n
     
    prints:
     
    42 W\n42 J/s\n42 N m/s\n42 kg m\u00b2/s\u00b3\n
     
    All of the above quantities are equivalent and mean exactly the same.
     
    Note
     
    The above code example may give the impression that the order of components in a derived unit is determined by the multiplication order. This is not the case. As stated in Simplifying the resulting symbolic expressions, to be able to reason about and simplify units, the library needs to order them in an appropriate order. This will affect the order of components in a resulting type and text output.
     
    Please refer to our FAQ for more information.
    "},{"location":"users_guide/framework_basics/systems_of_units/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"
    Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation 1 / s. However, it also explicitly states:
     
    SI Brochure
     
    The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
     
    The above means that the usage of becquerel as a unit of a frequency quantity is an error.
     
    The library allows constraining such units to work only with quantities of a specific kind in the following way:
     
    inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\n
     
    With the above, hertz can only be used with frequencies, while becquerel should only be used with quantities of activity. This means that the following equation will not compile:
     
    auto q = 1 * Hz + 1 * Bq;   // Fails to compile\n
     
    This is exactly what we wanted to achieve to improve the type-safety of the library.
    "},{"location":"users_guide/framework_basics/systems_of_units/#prefixed-units","title":"Prefixed units","text":"
    Besides named units, the SI specifies also 24 prefixes (all being a power of 10) that can be prepended to all named units to obtain various scaled versions of them.
     
    Implementation of std::ratio provided by all major compilers is able to express only 16 of them. This is why, in the mp-units, we had to find an alternative way to represent unit magnitude in a more flexible way.
     
    Each prefix is implemented similarly to the following:
     
    template<PrefixableUnit U> struct quecto_ : prefixed_unit<\"q\", mag_power<10, -30>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr quecto_<decltype(U)> quecto;\n
     
    and then a PrefixableUnit can be prefixed in the following way:
     
    inline constexpr auto qm = quecto<metre>;\n
     
    The usage of mag_power not only enables providing support for SI prefixes, but it can also efficiently represent any rational magnitude. For example, IEC 80000 prefixes used in the IT industry can be implemented as:
     
    template<PrefixableUnit U> struct yobi_ : prefixed_unit<\"Yi\", mag_power<2, 80>, U{}> {};\ntemplate<PrefixableUnit auto U> constexpr yobi_<decltype(U)> yobi;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#scaled-units","title":"Scaled units","text":"
    In the SI, all units are either base or derived units or prefixed versions of those. However, those are only some of the options possible.
     
    For example, there is a list of off-system units accepted for use with SI. Those are scaled versions of the SI units with ratios that can't be explicitly expressed with predefined SI prefixes. Those include units like minute, hour, or electronvolt:
     
    inline constexpr struct minute final : named_unit<\"min\", mag<60> * si::second> {} minute;\ninline constexpr struct hour final : named_unit<\"h\", mag<60> * minute> {} hour;\ninline constexpr struct electronvolt final : named_unit<\"eV\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * si::joule> {} electronvolt;\n
     
    Also, units of other systems of units are often defined in terms of scaled versions of the SI units. For example, the international yard is defined as:
     
    inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\n
     
    For some units, a magnitude might also be irrational. The best example here is a degree which is defined using a floating-point magnitude having a factor of the number \u03c0 (Pi):
     
    inline constexpr struct pi final : mag_constant<symbol_text{u8\"\u03c0\", \"pi\"}, std::numbers::pi_v<long double>> {} pi;\ninline constexpr auto \u03c0 = pi;\n
     
    inline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag<\u03c0> / mag<180> * si::radian> {} degree;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#unit-symbols","title":"Unit symbols","text":"
    Units are available via their full names or through their short symbols. To use a long version, it is enough to type:
     
    quantity q1 = 42 * si::metre / si::second;\nquantity q2 = 42 * si::kilo<si::metre> / si::hour;\n
     
    To simplify how we spell it a short, user-friendly symbols are provided in a dedicated subnamespace in systems definitions:
     
    namespace si::unit_symbols {\n\nconstexpr auto m = si::metre;\nconstexpr auto km = si::kilo<si::metre>;\nconstexpr auto s = si::second;\nconstexpr auto h = si::hour;\n\n}\n
     
    Unit symbols introduce a lot of short identifiers into the current namespace. This is why they are opt-in. A user has to explicitly \"import\" them from a dedicated unit_symbols namespace:
     using-declarationusing-directive 
    using namespace si::unit_symbols;\n\nquantity q1 = 42 * m / s;\nquantity q2 = 42 * km / h;\n
     
    using si::unit_symbols::m;\nusing si::unit_symbols::km;\nusing si::unit_symbols::s;\nusing si::unit_symbols::h;\n\nquantity q1 = 42 * m / s;\nquantity q2 = 42 * km / h;\n
     
    We also provide alternative object identifiers using UTF-8 characters in their names for most unit symbols. The code using UTF-8 looks nicer, but it is harder to type on the keyboard. This is why we provide both versions of identifiers for such units.
     PortableWith UTF-8 glyphs 
    quantity resistance = 60 * kohm;\nquantity capacitance = 100 * uF;\n
     
    quantity resistance = 60 * k\u03a9;\nquantity capacitance = 100 * \u00b5F;\n
    "},{"location":"users_guide/framework_basics/systems_of_units/#common-units","title":"Common units","text":"
    Adding, subtracting, or comparing two quantities of different units will force the library to find a common unit for those. This is to prevent data truncation. For the cases when one of the units is an integral multiple of the another, the resulting quantity will use a \"smaller\" one in its result. For example:
     
    static_assert((1 * kg + 1 * g).unit == g);\nstatic_assert((1 * km + 1 * mm).unit == mm);\nstatic_assert((1 * yd + 1 * mi).unit == yd);\n
     
    However, in many cases an arithmetic operation on quantities of different units will result in a yet another unit. This happens when none of the source units is an integral multiple of another. In such cases, the library returns a special type that denotes that we are dealing with a common unit of such an equation:
     
    quantity q1 = 1 * km + 1 * mi;     // quantity<common_unit<international::mile, si::kilo_<si::metre>>{}, int>\nquantity q2 = 1. * rad + 1. * deg; // quantity<common_unit<si::degree, si::radian>{}, double>\n
     
    Note
     
    A user should never explicitly instantiate a common_unit class template. The library's framework will do it based on the provided quantity equation.
    "},{"location":"users_guide/framework_basics/text_output/","title":"Text Output","text":"
    Besides providing dimensional analysis and unit conversions, the library also tries hard to print any quantity in the most user-friendly way. We can print the entire quantity or its selected parts (numerical value, unit, or dimension).
     
    Note
     
    The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
     
    In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
     
    For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
     
    Please let us know if you have a good idea of how to solve this issue.
    "},{"location":"users_guide/framework_basics/text_output/#predefined-symbols","title":"Predefined symbols","text":"
    The definitions of dimensions, units, prefixes, and constants require assigning text symbols for each entity. Those symbols will be composed by the library's framework to express dimensions and units of derived quantities.
     DimensionsUnitsPrefixesConstants 
    inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_mass final : base_dimension<\"M\"> {} dim_mass;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\ninline constexpr struct dim_electric_current final : base_dimension<\"I\"> {} dim_electric_current;\ninline constexpr struct dim_thermodynamic_temperature final : base_dimension<{u8\"\u0398\", \"O\"}> {} dim_thermodynamic_temperature;\ninline constexpr struct dim_amount_of_substance final : base_dimension<\"N\"> {} dim_amount_of_substance;\ninline constexpr struct dim_luminous_intensity final : base_dimension<\"J\"> {} dim_luminous_intensity;\n
     
    inline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\n\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\ninline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\ninline constexpr struct coulomb final : named_unit<\"C\", ampere * second> {} coulomb;\ninline constexpr struct volt final : named_unit<\"V\", watt / ampere> {} volt;\ninline constexpr struct farad final : named_unit<\"F\", coulomb / volt> {} farad;\ninline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
     
    template<PrefixableUnit U> struct micro_ : prefixed_unit<{u8\"\u00b5\", \"u\"}, mag_power<10, -6>, U{}> {};\ntemplate<PrefixableUnit U> struct milli_ : prefixed_unit<\"m\", mag_power<10, -3>, U{}> {};\ntemplate<PrefixableUnit U> struct centi_ : prefixed_unit<\"c\", mag_power<10, -2>, U{}> {};\ntemplate<PrefixableUnit U> struct deci_  : prefixed_unit<\"d\", mag_power<10, -1>, U{}> {};\ntemplate<PrefixableUnit U> struct deca_  : prefixed_unit<\"da\", mag_power<10, 1>, U{}> {};\ntemplate<PrefixableUnit U> struct hecto_ : prefixed_unit<\"h\", mag_power<10, 2>, U{}> {};\ntemplate<PrefixableUnit U> struct kilo_  : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit U> struct mega_  : prefixed_unit<\"M\", mag_power<10, 6>, U{}> {};\n
     
    inline constexpr struct hyperfine_structure_transition_frequency_of_cs final : named_unit<{u8\"\u0394\u03bd_Cs\", \"dv_Cs\"}, mag<9'192'631'770> * hertz> {} hyperfine_structure_transition_frequency_of_cs;\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\ninline constexpr struct planck_constant final : named_unit<\"h\", mag_ratio<662'607'015, 100'000'000> * mag_power<10, -34> * joule * second> {} planck_constant;\ninline constexpr struct elementary_charge final : named_unit<\"e\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * coulomb> {} elementary_charge;\ninline constexpr struct boltzmann_constant final : named_unit<\"k\", mag_ratio<1'380'649, 1'000'000> * mag_power<10, -23> * joule / kelvin> {} boltzmann_constant;\ninline constexpr struct avogadro_constant final : named_unit<\"N_A\", mag_ratio<602'214'076, 100'000'000> * mag_power<10, 23> / mole> {} avogadro_constant;\ninline constexpr struct luminous_efficacy final : named_unit<\"K_cd\", mag<683> * lumen / watt> {} luminous_efficacy;\n
     
    Important
     
    Two symbols always have to be provided if the primary symbol contains characters outside of the basic literal character set. The first must be provided as a UTF-8 literal and may contain any Unicode characters. The second one must provide an alternative spelling and only use characters from within of basic literal character set.
     
    Note
     
    Unicode provides only a minimal set of characters available as subscripts, which are often used to differentiate various constants and quantities of the same kind. To workaround this issue, mp-units uses the '_' character to specify that the following characters should be considered a subscript of the symbol.
     
    Tip
     
    For older compilers, it might be required to specify a symbol_text class explicitly template name to initialize it with two symbols:
     
    inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-for-derived-entities","title":"Symbols for derived entities","text":""},{"location":"users_guide/framework_basics/text_output/#text_encoding","title":"text_encoding","text":"
    ISQ and SI standards always specify symbols using UTF-8 encoding. This is why it is a default and primary target for text output. However, in some applications or environments, a standard portable text output using only the characters from the basic literal character set can be preferred by users.
     
    This is why the library provides an option to change the default encoding to the portable one with:
     
    enum class text_encoding : std::int8_t {\n  utf8,       // \u00b5s; m\u00b3;  L\u00b2MT\u207b\u00b3\n  portable,   // us; m^3; L^2MT^-3\n  default_encoding = utf8\n};\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-derived-dimensions","title":"Symbols of derived dimensions","text":""},{"location":"users_guide/framework_basics/text_output/#dimension_symbol_formatting","title":"dimension_symbol_formatting","text":"
    dimension_symbol_formatting is a data type describing the configuration of the symbol generation algorithm.
     
    struct dimension_symbol_formatting {\n  text_encoding encoding = text_encoding::default_encoding;\n};\n
    "},{"location":"users_guide/framework_basics/text_output/#dimension_symbol","title":"dimension_symbol()","text":"
    Returns a std::string_view with the symbol of a dimension for the provided configuration:
     
    template<dimension_symbol_formatting fmt = dimension_symbol_formatting{}, typename CharT = char, Dimension D>\n[[nodiscard]] consteval std::string_view dimension_symbol(D);\n
     
    For example:
     
    static_assert(dimension_symbol<{.encoding = text_encoding::portable}>(isq::power.dimension) == \"L^2MT^-3\");\n
     
    Note
     
    std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned.
    "},{"location":"users_guide/framework_basics/text_output/#dimension_symbol_to","title":"dimension_symbol_to()","text":"
    Inserts the generated dimension symbol into the output text iterator at runtime.
     
    template<typename CharT = char, std::output_iterator<CharT> Out, Dimension D>\nconstexpr Out dimension_symbol_to(Out out, D d, dimension_symbol_formatting fmt = dimension_symbol_formatting{});\n
     
    For example:
     
    std::string txt;\ndimension_symbol_to(std::back_inserter(txt), isq::power.dimension, {.encoding = text_encoding::portable});\nstd::cout << txt << \"\\n\";\n
     
    The above prints:
     
    L^2MT^-3\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-derived-units","title":"Symbols of derived units","text":""},{"location":"users_guide/framework_basics/text_output/#unit_symbol_formatting","title":"unit_symbol_formatting","text":"
    unit_symbol_formatting is a data type describing the configuration of the symbol generation algorithm. It contains three orthogonal fields, each with a default value.
     
    enum class unit_symbol_solidus : std::int8_t {\n  one_denominator,  // m/s;   kg m\u207b\u00b9 s\u207b\u00b9\n  always,           // m/s;   kg/(m s)\n  never,            // m s\u207b\u00b9; kg m\u207b\u00b9 s\u207b\u00b9\n  default_denominator = one_denominator\n};\n\nenum class unit_symbol_separator : std::int8_t {\n  space,          // kg m\u00b2/s\u00b2\n  half_high_dot,  // kg\u22c5m\u00b2/s\u00b2  (valid only for utf8 encoding)\n  default_separator = space\n};\n\nstruct unit_symbol_formatting {\n  text_encoding encoding = text_encoding::default_encoding;\n  unit_symbol_solidus solidus = unit_symbol_solidus::default_denominator;\n  unit_symbol_separator separator = unit_symbol_separator::default_separator;\n};\n
     
    unit_symbol_solidus impacts how the division of unit symbols is being presented in the text output. By default, the '/' will be printed if only one unit component is in the denominator. Otherwise, the exponent syntax will be used.
     
    unit_symbol_separator specifies how multiple multiplied units should be separated from each other. By default, the space (' ') will be used as a separator.
    "},{"location":"users_guide/framework_basics/text_output/#unit_symbol","title":"unit_symbol()","text":"
    Returns a std::string_view with the symbol of a unit for the provided configuration:
     
    template<unit_symbol_formatting fmt = unit_symbol_formatting{}, typename CharT = char, Unit U>\n[[nodiscard]] consteval std::string_view unit_symbol(U);\n
     
    For example:
     
    static_assert(unit_symbol<{.solidus = unit_symbol_solidus::never,\n                           .separator = unit_symbol_separator::half_high_dot}>(kg * m / s2) == \"kg\u22c5m\u22c5s\u207b\u00b2\");\n
    "},{"location":"users_guide/framework_basics/text_output/#unit_symbol_to","title":"unit_symbol_to()","text":"
    Inserts the generated unit symbol into the output text iterator at runtime.
     
    template<typename CharT = char, std::output_iterator<CharT> Out, Unit U>\nconstexpr Out unit_symbol_to(Out out, U u, unit_symbol_formatting fmt = unit_symbol_formatting{});\n
     
    For example:
     
    std::string txt;\nunit_symbol_to(std::back_inserter(txt), kg * m / s2,\n               {.solidus = unit_symbol_solidus::never, .separator = unit_symbol_separator::half_high_dot});\nstd::cout << txt << \"\\n\";\n
     
    The above prints:
     
    kg\u22c5m\u22c5s\u207b\u00b2\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-scaled-units","title":"Symbols of scaled units","text":"
    In most cases scaled units are hidden behind named units. However, there are a few real-life where a user directly faces a scaled unit. For example:
     
    constexpr Unit auto L_per_100km = L / (mag<100> * km);\n
     
    The above is a derived unit of litre divided by a scaled unit of 100 kilometers. As we can see a scaled unit has a magnitude and a reference unit. To denote the scope of such a unit, we enclose it in [...]. For example, the following:
     
    std::cout << 6.7 * L_per_100km << \"\\n\";\n
     
    prints:
     
    6.7 L/[100 km]\n
    "},{"location":"users_guide/framework_basics/text_output/#symbols-of-common-units","title":"Symbols of common units","text":"
    Some common units expressed with a specialization of the common_unit class template need special printing rules for their symbols. As they represent a minimum set of equivalent common units resulting from the addition or subtraction of multiple quantities, we print all of them as a scaled version of the source unit. For example, the following:
     
    std::cout << 1 * km + 1 * mi << \"\\n\";\nstd::cout << 1 * nmi + 1 * mi << \"\\n\";\nstd::cout << 1 * km / h + 1 * m / s << \"\\n\";\nstd::cout << 1 * rad + 1 * deg << \"\\n\";\n
     
    prints:
     
    40771 EQUIV{[1/25146 mi], [1/15625 km]}\n108167 EQUIV{[1/50292 mi], [1/57875 nmi]}\n23 EQUIV{[1/5 km/h], [1/18 m/s]}\n183.142 EQUIV{[1/\u03c0\u00b0], [1/180 rad]}\n
     
    Thanks to the above, it might be easier for the user to reason about the magnitude of the resulting unit and its impact on the value stored in the quantity.
     
    Note
     
    It is important to note that this output is provided only for intermediate results of the equations, as shown above. A user usually knows which unit should be used, and explicit conversion can be made to achieve that. For example:
     
    std::cout << (1 * km + 1 * mi).in<double>(km) << \"\\n\";\n
     
    prints:
     
    2.60934 km\n
    "},{"location":"users_guide/framework_basics/text_output/#space_before_unit_symbol-customization-point","title":"space_before_unit_symbol customization point","text":"
    The SI Brochure says:
     
    SI Brochure
     
    The numerical value always precedes the unit and a space is always used to separate the unit from the number. ... The only exceptions to this rule are for the unit symbols for degree, minute and second for plane angle, \u00b0, \u2032 and \u2033, respectively, for which no space is left between the numerical value and the unit symbol.
     
    There are more units with such properties. For example, percent (%) and per mille(\u2030).
     
    To support the above and other similar cases, the library exposes space_before_unit_symbol customization point. By default, its value is true for all the units, so the space between a number and a unit will be inserted in the output text. To change this behavior, we have to provide a partial specialization for a specific unit:
     
    template<>\nconstexpr bool space_before_unit_symbol<non_si::degree> = false;\n
     
    Note
     
    The above works only for the default formatting or for the format strings that use %? placement field (std::format(\"{}\", q) is equivalent to std::format(\"{:%N%?%U}\", q)).
     
    In case a user provides custom format specification (e.g., std::format(\"{:%N %U}\", q)), the library will always obey this specification for all the units (no matter what the actual value of the space_before_unit_symbol customization point is) and the separating space will always be used in this case.
    "},{"location":"users_guide/framework_basics/text_output/#output-streams","title":"Output streams","text":"
    Tip
     
    The output streaming support is opt-in and can be enabled by including the <mp-units/ostream.h> header file.
     
    The easiest way to print a dimension, unit, or quantity is to provide its object to the output stream:
     
    const QuantityOf<isq::speed> auto v1 = avg_speed(220. * km, 2 * h);\nconst QuantityOf<isq::speed> auto v2 = avg_speed(140. * mi, 2 * h);\nstd::cout << v1 << '\\n';            // 110 km/h\nstd::cout << v2 << '\\n';            // 70 mi/h\nstd::cout << v2.unit << '\\n';       // mi/h\nstd::cout << v2.dimension << '\\n';  // LT\u207b\u00b9\n
     
    The text output will always print the value using the default formatting for this entity.
     
    Important: Don't assume a unit
     
    Remember that when we deal with a quantity of an \"unknown\" (e.g., auto) type, it is a good practice to always convert the unit to the expected one before passing it to the text output:
     
    std::cout << v1.in(km / h) << '\\n';       // 110 km/h\nstd::cout << v1.force_in(m / s) << '\\n';  // 30.5556 m/s\n
    "},{"location":"users_guide/framework_basics/text_output/#output-stream-formatting","title":"Output stream formatting","text":"
    Only basic formatting can be applied to output streams. It includes control over width, fill, and alignment.
     
    The numerical value of the quantity will be printed according to the current stream state and standard manipulators may be used to customize that (assuming that the underlying representation type respects them).
     
    std::cout << \"|\" << std::setw(10) << 123 * m << \"|\\n\";                       // |     123 m|\nstd::cout << \"|\" << std::setw(10) << std::left << 123 * m << \"|\\n\";          // |123 m     |\nstd::cout << \"|\" << std::setw(10) << std::setfill('*') << 123 * m << \"|\\n\";  // |123 m*****|\n
     
    Note
     
    To have more control over the formatting of the quantity that is printed with the output stream just use std::cout << std::format(...).
    "},{"location":"users_guide/framework_basics/text_output/#text-formatting","title":"Text formatting","text":"
    The library provides custom formatters for std::format facility, which allows fine-grained control over what and how it is being printed in the text output.
     
    Tip
     
    The text formatting facility support is opt-in and can be enabled by including the <mp-units/format.h> header file.
    "},{"location":"users_guide/framework_basics/text_output/#controlling-width-fill-and-alignment","title":"Controlling width, fill, and alignment","text":"
    Formatting grammar for all the entities provides control over width, fill, and alignment. The C++ standard grammar tokens fill-and-align and width are being used. They treat the entity as a contiguous text to be aligned. For example, here are a few examples of the quantity numerical value and symbol formatting:
     
    std::println(\"|{:0}|\", 123 * m);     // |123 m|\nstd::println(\"|{:10}|\", 123 * m);    // |     123 m|\nstd::println(\"|{:<10}|\", 123 * m);   // |123 m     |\nstd::println(\"|{:>10}|\", 123 * m);   // |     123 m|\nstd::println(\"|{:^10}|\", 123 * m);   // |  123 m   |\nstd::println(\"|{:*<10}|\", 123 * m);  // |123 m*****|\nstd::println(\"|{:*>10}|\", 123 * m);  // |*****123 m|\nstd::println(\"|{:*^10}|\", 123 * m);  // |**123 m***|\n
     
    It is important to note that in the second line above, the quantity text is aligned to the right by default, which is consistent with the formatting of numeric types. Units and dimensions behave as text and, thus, are aligned to the left by default.
     
    Note
     
    std::println is a C++23 facility. In case we do not have access to C++23, we can obtain the same output with:
     
    std::cout << std::format(\"<format-string>\\n\", <format-args>);\n
    "},{"location":"users_guide/framework_basics/text_output/#dimension-formatting","title":"Dimension formatting","text":"
    dimension-format-spec = [fill-and-align], [width], [dimension-spec];\ndimension-spec        = [character-set];\ncharacter-set         = 'U' | 'P';\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • character-set token specifies the symbol text encoding:
         
      • U (default) uses the UTF-8 symbols defined by [@ISO80000] (e.g., LT\u207b\u00b2),
        •  
      • P forces non-standard portable output (e.g., LT^-2).
        •  
       
      •  
     
    Dimension symbols of some quantities are specified to use Unicode signs by the ISQ (e.g., \u0398 symbol for the thermodynamic temperature dimension). The library follows this by default. From the engineering point of view, sometimes Unicode text might not be the best solution, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the dimension symbol can be forced to be printed using such characters thanks to character-set token:
     
    std::println(\"{}\", isq::dim_thermodynamic_temperature);   // \u0398\nstd::println(\"{:P}\", isq::dim_thermodynamic_temperature); // O\nstd::println(\"{}\", isq::power.dimension);                 // L\u00b2MT\u207b\u00b3\nstd::println(\"{:P}\", isq::power.dimension);               // L^2MT^-3\n
    "},{"location":"users_guide/framework_basics/text_output/#unit-formatting","title":"Unit formatting","text":"
    unit-format-spec      = [fill-and-align], [width], [unit-spec];\nunit-spec             = [character-set], [unit-symbol-solidus], [unit-symbol-separator], [L]\n                      | [character-set], [unit-symbol-separator], [unit-symbol-solidus], [L]\n                      | [unit-symbol-solidus], [character-set], [unit-symbol-separator], [L]\n                      | [unit-symbol-solidus], [unit-symbol-separator], [character-set], [L]\n                      | [unit-symbol-separator], [character-set], [unit-symbol-solidus], [L]\n                      | [unit-symbol-separator], [unit-symbol-solidus], [character-set], [L];\nunit-symbol-solidus   = '1' | 'a' | 'n';\nunit-symbol-separator = 's' | 'd';\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • unit-symbol-solidus token specifies how the division of units should look like:
         
      • '1' (default) outputs / only when there is only one unit in the denominator, otherwise   negative exponents are printed (e.g., m/s, kg m\u207b\u00b9 s\u207b\u00b9)
        •  
      • 'a' always uses solidus (e.g., m/s, kg/(m s))
        •  
      • 'n' never prints solidus, which means that negative exponents are always used   (e.g., m s\u207b\u00b9, kg m\u207b\u00b9 s\u207b\u00b9)
        •  
       
      •  
    • unit-symbol-separator token specifies how multiplied unit symbols should be separated:
         
      • 's' (default) uses space as a separator (e.g., kg m\u00b2/s\u00b2)
        •  
      • 'd' uses half-high dot (\u22c5) as a separator (e.g., kg\u22c5m\u00b2/s\u00b2) (requires the UTF-8 encoding)
        •  
       
      •  
    • 'L' is reserved for possible future localization use in case the C++ standard library gets access to   the ICU-like database.
      •  
     
    Note
     
    The above grammar intended that the elements of unit-spec can appear in any order as they have unique characters. Users shouldn't have to remember the order of those tokens to control the formatting of a unit symbol.
     
    Unit symbols of some quantities are specified to use Unicode signs by the SI (e.g., \u03a9 symbol for the resistance quantity). The library follows this by default. From the engineering point of view, Unicode text might not be the best solution sometimes, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the unit symbol can be forced to be printed using such characters thanks to character-set token:
     
    std::println(\"{}\", si::ohm);      // \u03a9\nstd::println(\"{:P}\", si::ohm);    // ohm\nstd::println(\"{}\", us);           // \u00b5s\nstd::println(\"{:P}\", us);         // us\nstd::println(\"{}\", m / s2);       // m/s\u00b2\nstd::println(\"{:P}\", m / s2);     // m/s^2\n
     
    Additionally, both ISO 80000 and SI leave some freedom on how to print unit symbols. This is why two additional tokens were introduced.
     
    unit-symbol-solidus specifies how the division of units should look like. By default, / will be used only when the denominator contains only one unit. However, with the 'a' or 'n' options, we can force the facility to print the / character always (even when there are more units in the denominator), or never, in which case a parenthesis will be added to enclose all denominator units.
     
    std::println(\"{}\", m / s);          // m/s\nstd::println(\"{}\", kg / m / s2);    // kg m\u207b\u00b9 s\u207b\u00b2\nstd::println(\"{:a}\", m / s);        // m/s\nstd::println(\"{:a}\", kg / m / s2);  // kg/(m s\u00b2)\nstd::println(\"{:n}\", m / s);        // m s\u207b\u00b9\nstd::println(\"{:n}\", kg / m / s2);  // kg m\u207b\u00b9 s\u207b\u00b2\n
     
    The unit-symbol-separator token allows us to obtain the following outputs:
     
    std::println(\"{}\", kg * m2 / s2);    // kg m\u00b2/s\u00b2\nstd::println(\"{:d}\", kg * m2 / s2);  // kg\u22c5m\u00b2/s\u00b2\n
     
    Note
     
    'd' requires the UTF-8 encoding to be set.
    "},{"location":"users_guide/framework_basics/text_output/#quantity-formatting","title":"Quantity formatting","text":"
    quantity-format-spec        = [fill-and-align], [width], [quantity-specs], [defaults-specs];\nquantity-specs              = conversion-spec;\n                            | quantity-specs, conversion-spec;\n                            | quantity-specs, literal-char;\nliteral-char                = ? any character other than '{', '}', or '%' ?;\nconversion-spec             = '%', placement-type;\nplacement-type              = subentity-id | '?' | '%';\ndefaults-specs              = ':', default-spec-list;\ndefault-spec-list           = default-spec;\n                            | default-spec-list, default-spec;\ndefault-spec                = subentity-id, '[' format-spec ']';\nsubentity-id                = 'N' | 'U' | 'D';\nformat-spec                 = ? as specified by the formatter for the argument type ?;\n
     
    In the above grammar:
     
       
    • fill-and-align and width tokens are defined in the format.string.std   chapter of the C++ standard specification,
      •  
    • placement-type token specifies which entity should be put and where:
         
      • 'N' inserts a default-formatted numerical value of the quantity,
        •  
      • 'U' inserts a default-formatted unit of the quantity,
        •  
      • 'D' inserts a default-formatted dimension of the quantity,
        •  
      • '?' inserts an optional separator between the number and a unit based on the value of   space_before_unit_symbol for this unit,
        •  
      • '%' just inserts '%' character.
        •  
       
      •  
    • defaults-specs token allows overwriting defaults for the underlying formatters with the custom   format string. Each override starts with a subentity identifier ('N', 'U', or 'D') followed by   the format string enclosed in square brackets.
      •  
    "},{"location":"users_guide/framework_basics/text_output/#default-formatting","title":"Default formatting","text":"
    To format quantity values, the formatting facility uses quantity-format-spec. If left empty, the default formatting is applied. The same default formatting is also applied to the output streams. This is why the following code lines produce the same output:
     
    std::cout << \"Distance: \" << 123 * km << \"\\n\";\nstd::cout << std::format(\"Distance: {}\\n\", 123 * km);\nstd::cout << std::format(\"Distance: {:%N%?%U}\\n\", 123 * km);\n
     
    Note
     
    For some quantities, the {:%N %U} format may provide a different output than the default one, as some units have space_before_unit_symbol customization point explicitly set to false (e.g., % and \u00b0).
    "},{"location":"users_guide/framework_basics/text_output/#quantity-numerical-value-unit-symbol-or-both","title":"Quantity numerical value, unit symbol, or both?","text":"
    Thanks to the grammar provided above, the user can easily decide to either:
     
       
    •  
      print a whole quantity:
       
      std::println(\"Speed: {}\", 120 * km / h);\n
       
      Speed: 120 km/h\n
       
      •  
    •  
      provide custom quantity formatting:
       
      std::println(\"Speed: {:%N in %U}\", 120 * km / h);\n
       
      Speed: 120 in km/h\n
       
      •  
    •  
      provide custom formatting for components:
       
      std::println(\"Speed: {::N[.2f]U[n]}\", 100. * km / (3 * h));\n
       
      Speed: 33.33 km h\u207b\u00b9\n
       
      •  
    •  
      print only specific components (numerical value, unit, or dimension):
       
      std::println(\"Speed:\\n- number: {0:%N}\\n- unit: {0:%U}\\n- dimension: {0:%D}\", 120 * km / h);\n
       
      Speed:\n- number: 120\n- unit: km/h\n- dimension: LT\u207b\u00b9\n
       
      •  
    "},{"location":"users_guide/framework_basics/text_output/#formatting-of-the-quantity-numerical-value","title":"Formatting of the quantity numerical value","text":"
    The representation type used as a numerical value of a quantity must provide its own formatter specialization. It will be called by the quantity formatter with the format-spec provided by the user in the N defaults specification.
     
    In case we use C++ fundamental arithmetic types with our quantities the standard formatter specified in format.string.std will be used. The rest of this chapter assumes that it is the case and provides some usage examples.
     
    sign token allows us to specify how the value's sign is being printed:
     
    std::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", 1 * m);   // 1 m,+1 m,1 m, 1 m\nstd::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", -1 * m);  // -1 m,-1 m,-1 m,-1 m\n
     
    where:
     
       
    • + indicates that a sign should be used for both non-negative and negative numbers,
      •  
    • - indicates that a sign should be used for negative numbers and negative zero only   (this is the default behavior),
      •  
    • <space> indicates that a leading space should be used for non-negative numbers other   than negative zero, and a minus sign for negative numbers and negative zero.
      •  
     
    precision token is allowed only for floating-point representation types:
     
    std::println(\"{::N[.0]}\", 1.2345 * m);   // 1 m\nstd::println(\"{::N[.1]}\", 1.2345 * m);   // 1 m\nstd::println(\"{::N[.2]}\", 1.2345 * m);   // 1.2 m\nstd::println(\"{::N[.3]}\", 1.2345 * m);   // 1.23 m\nstd::println(\"{::N[.0f]}\", 1.2345 * m);  // 1 m\nstd::println(\"{::N[.1f]}\", 1.2345 * m);  // 1.2 m\nstd::println(\"{::N[.2f]}\", 1.2345 * m);  // 1.23 m\n
     
    type specifies how a value of the representation type is being printed. For integral types:
     
    std::println(\"{::N[b]}\", 42 * m);    // 101010 m\nstd::println(\"{::N[B]}\", 42 * m);    // 101010 m\nstd::println(\"{::N[d]}\", 42 * m);    // 42 m\nstd::println(\"{::N[o]}\", 42 * m);    // 52 m\nstd::println(\"{::N[x]}\", 42 * m);    // 2a m\nstd::println(\"{::N[X]}\", 42 * m);    // 2A m\n
     
    The above can be printed in an alternate version thanks to the # token:
     
    std::println(\"{::N[#b]}\", 42 * m);   // 0b101010 m\nstd::println(\"{::N[#B]}\", 42 * m);   // 0B101010 m\nstd::println(\"{::N[#o]}\", 42 * m);   // 052 m\nstd::println(\"{::N[#x]}\", 42 * m);   // 0x2a m\nstd::println(\"{::N[#X]}\", 42 * m);   // 0X2A m\n
     
    For floating-point values, the type token works as follows:
     
    std::println(\"{::N[a]}\",   1.2345678 * m);      // 1.3c0ca2a5b1d5dp+0 m\nstd::println(\"{::N[.3a]}\", 1.2345678 * m);      // 1.3c1p+0 m\nstd::println(\"{::N[A]}\",   1.2345678 * m);      // 1.3C0CA2A5B1D5DP+0 m\nstd::println(\"{::N[.3A]}\", 1.2345678 * m);      // 1.3C1P+0 m\nstd::println(\"{::N[e]}\",   1.2345678 * m);      // 1.234568e+00 m\nstd::println(\"{::N[.3e]}\", 1.2345678 * m);      // 1.235e+00 m\nstd::println(\"{::N[E]}\",   1.2345678 * m);      // 1.234568E+00 m\nstd::println(\"{::N[.3E]}\", 1.2345678 * m);      // 1.235E+00 m\nstd::println(\"{::N[g]}\",   1.2345678 * m);      // 1.23457 m\nstd::println(\"{::N[g]}\",   1.2345678e8 * m);    // 1.23457e+08 m\nstd::println(\"{::N[.3g]}\", 1.2345678 * m);      // 1.23 m\nstd::println(\"{::N[.3g]}\", 1.2345678e8 * m);    // 1.23e+08 m\nstd::println(\"{::N[G]}\",   1.2345678 * m);      // 1.23457 m\nstd::println(\"{::N[G]}\",   1.2345678e8 * m);    // 1.23457E+08 m\nstd::println(\"{::N[.3G]}\", 1.2345678 * m);      // 1.23 m\nstd::println(\"{::N[.3G]}\", 1.2345678e8 * m);    // 1.23E+08 m\n
    "},{"location":"users_guide/framework_basics/the_affine_space/","title":"The Affine Space","text":"
    The affine space has two types of entities:
     
       
    • Point - a position specified with coordinate values (e.g., location, address, etc.)
      •  
    • Displacement vector - the difference between two points (e.g., shift, offset,   displacement, duration, etc.)
      •  
     
    In the following subchapters, we will often refer to displacement vectors simply as vectors for brevity.
     
    Note
     
    The displacement vector described here is specific to the affine space theory and is not the same thing as the quantity of a vector character that we discussed in the \"Scalars, vectors, and tensors\" chapter (although, in some cases, those terms may overlap).
    "},{"location":"users_guide/framework_basics/the_affine_space/#operations-in-the-affine-space","title":"Operations in the affine space","text":"
    Here are the primary operations one can do in the affine space:
     
       
    • vector + vector -> vector
      •  
    • vector - vector -> vector
      •  
    • -vector -> vector
      •  
    • vector * scalar -> vector
      •  
    • scalar * vector -> vector
      •  
    • vector / scalar -> vector
      •  
    • point - point -> vector
      •  
    • point + vector -> point
      •  
    • vector + point -> point
      •  
    • point - vector -> point
      •  
     
    Important
     
    It is not possible to:
     
       
    • add two points,
      •  
    • subtract a point from a vector,
      •  
    • multiply nor divide points with anything else.
      •  
    "},{"location":"users_guide/framework_basics/the_affine_space/#points-are-more-common-than-most-of-us-imagine","title":"Points are more common than most of us imagine","text":"
    Point abstractions should be used more often in the C++ software. They are not only about temperature or time. Points are everywhere around us and should become more popular in the products we implement. They can be used to implement:
     
       
    • temperature points,
      •  
    • timestamps,
      •  
    • daily mass readouts from the scale,
      •  
    • altitudes of mountain peaks on a map,
      •  
    • current path length measured by the car's odometer,
      •  
    • today's price of instruments on the market,
      •  
    • and many more.
      •  
     
    Improving the affine space's Points intuition will allow us to write better and safer software.
    "},{"location":"users_guide/framework_basics/the_affine_space/#displacement-vector-is-modeled-by-quantity","title":"Displacement vector is modeled by quantity","text":"
    Up until now, each time we used a quantity in our code, we were modeling some kind of a difference between two things:
     
       
    • the distance between two points,
      •  
    • duration between two time points,
      •  
    • the difference in speed (even if relative to zero).
      •  
     
    As we already know, a quantity type provides all operations required for a displacement vector abstraction in the affine space. It can be constructed with:
     
       
    • the multiply syntax (works for most of the units),
      •  
    • delta<Reference> construction helper (e.g., delta<isq::height[m]>(42), delta<deg_C>(3)),
      •  
    • two-parameter constructor taking a number and a quantity reference/unit.
      •  
     
    Note
     
    The multiply syntax support is disabled for units that provide a point origin in their definition (i.e., units of temperature like K, deg_C, and deg_F).
    "},{"location":"users_guide/framework_basics/the_affine_space/#point-is-modeled-by-quantity_point-and-pointorigin","title":"Point is modeled by quantity_point and PointOrigin","text":"
    In the mp-units library, the Point abstraction is modelled by:
     
       
    • PointOrigin concept that specifies measurement origin, and
      •  
    • quantity_point class template that specifies a Point relative to a specific predefined origin.
      •  
    "},{"location":"users_guide/framework_basics/the_affine_space/#quantity_point","title":"quantity_point","text":"
    The quantity_point class template specifies an absolute quantity measured from a predefined origin:
     
    template<Reference auto R,\n         PointOriginFor<get_quantity_spec(R)> auto PO = default_point_origin(R),\n         RepresentationOf<get_quantity_spec(R)> Rep = double>\nclass quantity_point;\n
     
    As we can see above, the quantity_point class template exposes one additional parameter compared to quantity. The PO parameter satisfies a PointOriginFor concept and specifies the origin of our measurement scale.
     
    Each quantity_point internally stores a quantity object, which represents a displacement vector from the predefined origin. Thanks to this, an instantiation of a quantity_point can be considered as a model of a vector space from such an origin.
     
    Forcing the user to manually predefine an origin for every domain may be cumbersome and discourage users from using such abstractions at all. This is why, by default, the PO template parameter is initialized with the default_point_origin(R) that provides the quantity points' scale zeroth point using the following rules:
     
       
    • if the measurement unit of a quantity specifies its point origin in its definition   (e.g., degree Celsius), then this origin is being used,
      •  
    • otherwise, an instantiation of zeroth_point_origin<QuantitySpec> is being used which   provides a well-established zeroth point for a specific quantity type.
      •  
     
    Quantity points with default point origins may be constructed with the point construction helper or forcing an explicit conversion from the quantity:
     
    // quantity_point qp1 = 42 * m;           // Compile-time error\n// quantity_point qp2 = 42 * K;           // Compile-time error\n// quantity_point qp3 = delta<deg_C>(42); // Compile-time error\nquantity_point qp4(42 * m);\nquantity_point qp5(42 * K);\nquantity_point qp6(delta<deg_C>(42));\nquantity_point qp7 = point<m>(42);\nquantity_point qp8 = point<K>(42);\nquantity_point qp9 = point<deg_C>(42);\n
     
    Tip
     
    The quantity_point definition can be found in the mp-units/quantity_point.h header file.
    "},{"location":"users_guide/framework_basics/the_affine_space/#zeroth_point_originquantityspec","title":"zeroth_point_origin<QuantitySpec>","text":"
    zeroth_point_origin<QuantitySpec> is meant to be used in cases where the specific domain has a well-established, non-controversial, and unique zeroth point on the measurement scale. This saves the user from the need to write a boilerplate code that would predefine such a type for this domain.
     
     
    quantity_point<isq::distance[si::metre]> qp1(100 * m);\nquantity_point<isq::distance[si::metre]> qp2 = point<m>(120);\n\nassert(qp1.quantity_from_zero() == 100 * m);\nassert(qp2.quantity_from_zero() == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\n// auto res = qp1 + qp2;   // Compile-time error\n
     
    In the above code 100 * m and 120 * m still create two quantities that serve as displacement vectors here. Quantity point objects can be explicitly constructed from such quantities only when their origin is an instantiation of the zeroth_point_origin<QuantitySpec>.
     
    It is really important to understand that even though we can use .quantity_from_zero() to obtain the displacement vector of a point from the origin, the point by itself does not represent or have any associated physical value. It is just a point in some space. The same point can be expressed with different displacement vectors from different origins.
     
    It is also worth mentioning that simplicity comes with a safety cost here. For some users, it might be surprising that the usage of zeroth_point_origin<QuantitySpec> makes various quantity point objects compatible as long as quantity types used in the origin and reference are compatible:
     
    quantity_point<si::metre> qp1{isq::distance(100 * m)};\nquantity_point<si::metre> qp2 = point<isq::height[m]>(120);\n\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#absolute-point-origin","title":"Absolute point origin","text":"
    In cases where we want to implement an isolated independent space in which points are not compatible with other spaces, even of the same quantity type, we should manually predefine an absolute point origin.
     
     
    inline constexpr struct origin final : absolute_point_origin<isq::distance> {} origin;\n\n// quantity_point<si::metre, origin> qp1{100 * m};        // Compile-time error\n// quantity_point<si::metre, origin> qp2{delta<m>(120)};  // Compile-time error\nquantity_point<si::metre, origin> qp1 = origin + 100 * m;\nquantity_point<si::metre, origin> qp2 = 120 * m + origin;\n\n// assert(qp1.quantity_from_zero() == 100 * m);   // Compile-time error\n// assert(qp2.quantity_from_zero() == 120 * m);   // Compile-time error\nassert(qp1.quantity_from(origin) == 100 * m);\nassert(qp2.quantity_from(origin) == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp1 - origin == 100 * m);\nassert(qp2 - origin == 120 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\nassert(origin - qp1 == -100 * m);\nassert(origin - qp2 == -120 * m);\n\n// assert(origin - origin == 0 * m);   // Compile-time error\n
     
    We can't construct a quantity point directly from the quantity anymore when a custom, named origin is used. To prevent potential safety and maintenance issues, we always need to explicitly provide both a compatible origin and a quantity measured from it to construct a quantity point.
     
    Said otherwise, a quantity point defined in terms of a specific origin is the result of adding the origin and the displacement vector measured from it to the point we create.
     
    Info
     
    A rationale for this longer construction syntax can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
     
    Similarly to creation of a quantity, if someone does not like the operator-based syntax to create a quantity_point, the same results can be achieved with a two-parameter constructor:
     
    quantity_point qp1{100 * m, origin};\n
     
    Again, CTAD always helps to use precisely the type we need in a current case.
     
    Additionally, if a quantity point is defined in terms of a custom, named origin, then we can't use a quantity_from_zero() member function anymore. This is to prevent surprises, as our origin may not necessarily be perceived as an absolute zero in the domain we model. Also, as we will learn soon, we can define several related origins in one space, and then it gets harder to understand which one is the \"zero\" one. This is why, to be specific and always correct about the points we use, a quantity_from(QP) member function can be used (where QP can either be an origin or another quantity point).
     
    Finally, please note that it is not allowed to subtract two point origins defined in terms of absolute_point_origin (e.g., origin - origin) as those do not contain information about the unit, so we cannot determine a resulting quantity type.
    "},{"location":"users_guide/framework_basics/the_affine_space/#modeling-independent-spaces-in-one-domain","title":"Modeling independent spaces in one domain","text":"
    Absolute point origins are also perfect for establishing independent spaces even if the same quantity type and unit is being used:
     
     
    inline constexpr struct origin1 final : absolute_point_origin<isq::distance> {} origin1;\ninline constexpr struct origin2 final : absolute_point_origin<isq::distance> {} origin2;\n\nquantity_point qp1 = origin1 + 100 * m;\nquantity_point qp2 = origin2 + 120 * m;\n\nassert(qp1.quantity_from(origin1) == 100 * m);\nassert(qp2.quantity_from(origin2) == 120 * m);\n\nassert(qp1 - origin1 == 100 * m);\nassert(qp2 - origin2 == 120 * m);\nassert(origin1 - qp1 == -100 * m);\nassert(origin2 - qp2 == -120 * m);\n\n// assert(qp2 - qp1 == 20 * m);                    // Compile-time error\n// assert(qp1 - origin2 == 100 * m);               // Compile-time error\n// assert(qp2 - origin1 == 120 * m);               // Compile-time error\n// assert(qp2.quantity_from(qp1) == 20 * m);       // Compile-time error\n// assert(qp1.quantity_from(origin2) == 100 * m);  // Compile-time error\n// assert(qp2.quantity_from(origin1) == 120 * m);  // Compile-time error\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#relative-point-origin","title":"Relative Point origin","text":"
    We often do not have only one ultimate \"zero\" point when we measure things. Often, we have one common scale, but we measure various quantities relative to different points and expect those points to be compatible. There are many examples here, but probably the most common are temperatures, timestamps, and altitudes.
     
    For such cases, relative point origins should be used:
     
     
    inline constexpr struct A final : absolute_point_origin<isq::distance> {} A;\ninline constexpr struct B final : relative_point_origin<A + 10 * m> {} B;\ninline constexpr struct C final : relative_point_origin<B + 10 * m> {} C;\ninline constexpr struct D final : relative_point_origin<A + 30 * m> {} D;\n\nquantity_point qp1 = C + 100 * m;\nquantity_point qp2 = D + 120 * m;\n\nassert(qp1.quantity_ref_from(qp1.point_origin) == 100 * m);\nassert(qp2.quantity_ref_from(qp2.point_origin) == 120 * m);\n\nassert(qp2.quantity_from(qp1) == 30 * m);\nassert(qp1.quantity_from(qp2) == -30 * m);\nassert(qp2 - qp1 == 30 * m);\nassert(qp1 - qp2 == -30 * m);\n\nassert(qp1.quantity_from(A) == 120 * m);\nassert(qp1.quantity_from(B) == 110 * m);\nassert(qp1.quantity_from(C) == 100 * m);\nassert(qp1.quantity_from(D) == 90 * m);\nassert(qp1 - A == 120 * m);\nassert(qp1 - B == 110 * m);\nassert(qp1 - C == 100 * m);\nassert(qp1 - D == 90 * m);\n\nassert(qp2.quantity_from(A) == 150 * m);\nassert(qp2.quantity_from(B) == 140 * m);\nassert(qp2.quantity_from(C) == 130 * m);\nassert(qp2.quantity_from(D) == 120 * m);\nassert(qp2 - A == 150 * m);\nassert(qp2 - B == 140 * m);\nassert(qp2 - C == 130 * m);\nassert(qp2 - D == 120 * m);\n\nassert(B - A == 10 * m);\nassert(C - A == 20 * m);\nassert(D - A == 30 * m);\nassert(D - C == 10 * m);\n\nassert(B - B == 0 * m);\n// assert(A - A == 0 * m);  // Compile-time error\n
     
    Note
     
    Even though we can't subtract two absolute point origins from each other, it is possible to subtract relative ones or relative and absolute ones.
    "},{"location":"users_guide/framework_basics/the_affine_space/#converting-between-different-representations-of-the-same-point","title":"Converting between different representations of the same point","text":"
    As we might represent the same point with displacement vectors from various origins, the library provides facilities to convert the same point to the quantity_point class templates expressed in terms of different origins.
     
     
    For this purpose, we can use either:
     
       
    •  
      A converting constructor:
       
      quantity_point<si::metre, C> qp2C = qp2;\nassert(qp2C.quantity_ref_from(qp2C.point_origin) == 130 * m);\n
       
      •  
    •  
      A dedicated conversion interface:
       
      quantity_point qp2B = qp2.point_for(B);\nquantity_point qp2A = qp2.point_for(A);\n\nassert(qp2B.quantity_ref_from(qp2B.point_origin) == 140 * m);\nassert(qp2A.quantity_ref_from(qp2A.point_origin) == 150 * m);\n
       
      •  
     
    It is important to understand that all such translations still describe exactly the same point (e.g., all of them compare equal):
     
    assert(qp2 == qp2C);\nassert(qp2 == qp2B);\nassert(qp2 == qp2A);\n
     
    Important
     
    It is only allowed to convert between various origins defined in terms of the same absolute_point_origin. Even if it is possible to express the same point as a displacement vector from another absolute_point_origin, the library will not provide such a conversion. A custom user-defined conversion function will be needed to add such a functionality.
     
    Said another way, in the library, there is no way to spell how two distinct absolute_point_origin types relate to each other.
    "},{"location":"users_guide/framework_basics/the_affine_space/#temperature-support","title":"Temperature support","text":"
    Support for temperature quantity points is probably one of the most common examples of relative point origins in action that we use in daily life.
     
    The SI definition in the library provides a few predefined point origins for this purpose:
     
    namespace si {\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\n\ninline constexpr struct ice_point final : relative_point_origin<point<milli<kelvin>>(273'150)}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\n\n}\n\nnamespace usc {\n\ninline constexpr struct zeroth_degree_Fahrenheit final :\n  relative_point_origin<point<mag_ratio<5, 9> * si::degree_Celsius>(-32)> {} zeroth_degree_Fahrenheit;\n\n}\n
     
    The above is a great example of how point origins can be stacked on top of each other:
     
       
    • usc::zeroth_degree_Fahrenheit is defined relative to si::zeroth_degree_Celsius
      •  
    • si::zeroth_degree_Celsius is defined relative to si::zeroth_kelvin.
      •  
     
    Note
     
    Notice that while stacking point origins, we can use different representation types and units for origins and a point. In the above example, the relative point origin for degree Celsius is defined in terms of si::kelvin, while the quantity point for it will use si::degree_Celsius as a unit.
     
    The temperature point origins defined above are provided explicitly in the respective units' definitions:
     
    namespace si {\n\ninline constexpr struct kelvin final :\n    named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\ninline constexpr struct degree_Celsius final :\n    named_unit<{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n\n}\n\nnamespace usc {\n\ninline constexpr struct degree_Fahrenheit final :\n    named_unit<{u8\"\u2109\", \"`F\"}, mag_ratio<5, 9> * si::degree_Celsius,\n               zeroth_degree_Fahrenheit> {} degree_Fahrenheit;\n\n}\n
     
    As it was described above, default_point_origin(R) returns a zeroth_point_origin<QuantitySpec> when a unit does not provide any origin in its definition. As of today, the units of temperature are the only ones in the entire mp-units library that provide such origins.
     
    Now, let's see how we can benefit from the above definitions. We have quite a few alternatives to choose from here. Depending on our needs or tastes, we can:
     
       
    •  
      be explicit about the unit and origin:
       
      quantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q1 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q2{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q3{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q4 = point<deg_C>(20.5);\n
       
      •  
    •  
      specify a unit and use its zeroth point origin implicitly:
       
      quantity_point<si::degree_Celsius> q5 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius> q6{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius> q7{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius> q8 = point<deg_C>(20.5);\n
       
      •  
    •  
      benefit from CTAD:
       
      quantity_point q9 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point q10{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point q11{delta<deg_C>(20.5)};\nquantity_point q12 = point<deg_C>(20.5);\n
       
      •  
     
    In all of the above cases, we end up with the quantity_point of the same type and value.
     
    To play a bit more with temperatures, we can implement a simple room AC temperature controller in the following way:
     
     
    constexpr struct room_reference_temp final : relative_point_origin<point<deg_C>(21)> {} room_reference_temp;\nusing room_temp = quantity_point<isq::Celsius_temperature[deg_C], room_reference_temp>;\n\nconstexpr auto step_delta = delta<isq::Celsius_temperature<deg_C>>(0.5);\nconstexpr int number_of_steps = 6;\n\nroom_temp room_ref{};\nroom_temp room_low = room_ref - number_of_steps * step_delta;\nroom_temp room_high = room_ref + number_of_steps * step_delta;\n\nstd::println(\"Room reference temperature: {} ({}, {::N[.2f]})\\n\",\n             room_ref.quantity_from_zero(),\n             room_ref.in(usc::degree_Fahrenheit).quantity_from_zero(),\n             room_ref.in(si::kelvin).quantity_from_zero());\n\nstd::println(\"| {:<18} | {:^18} | {:^18} | {:^18} |\",\n             \"Temperature delta\", \"Room reference\", \"Ice point\", \"Absolute zero\");\nstd::println(\"|{0:=^20}|{0:=^20}|{0:=^20}|{0:=^20}|\", \"\");\n\nauto print_temp = [&](std::string_view label, auto v) {\n  std::println(\"| {:<14} | {:^18} | {:^18} | {:^18:N[.2f]} |\", label,\n               v - room_reference_temp, (v - si::ice_point).in(deg_C), (v - si::absolute_zero).in(deg_C));\n};\n\nprint_temp(\"Lowest\", room_low);\nprint_temp(\"Default\", room_ref);\nprint_temp(\"Highest\", room_high);\n
     
    The above prints:
     
    Room reference temperature: 21 \u2103 (69.8 \u2109, 294.15 K)\n\n| Temperature delta  |   Room reference   |     Ice point      |   Absolute zero    |\n|====================|====================|====================|====================|\n| Lowest             |       -3 \u2103        |       18 \u2103        |     291.15 \u2103      |\n| Default            |        0 \u2103        |       21 \u2103        |     294.15 \u2103      |\n| Highest            |        3 \u2103        |       24 \u2103        |     297.15 \u2103      |\n
    "},{"location":"users_guide/framework_basics/the_affine_space/#no-text-output-for-points","title":"No text output for Points","text":"
    The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
     
    In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
     
    For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
    "},{"location":"users_guide/framework_basics/the_affine_space/#the-affine-space-is-about-type-safety","title":"The affine space is about type-safety","text":"
    The following operations are not allowed in the affine space:
     
       
    • adding two quantity_point objects
         
      • It is physically impossible to add positions of home and Denver airports.
        •  
       
      •  
    • subtracting a quantity_point from a quantity
         
      • What would it mean to subtract the DEN airport location from the distance to it?
        •  
       
      •  
    • multiplying/dividing a quantity_point with a scalar
         
      • What is the position of 2 * DEN airport location?
        •  
       
      •  
    • multiplying/dividing a quantity_point with a quantity
         
      • What would multiplying the distance with the DEN airport location mean?
        •  
       
      •  
    • multiplying/dividing two quantity_point objects
         
      • What would multiplying home and DEN airport location mean?
        •  
       
      •  
    • mixing quantity_points of different quantity kinds
         
      • It is physically impossible to subtract time from length.
        •  
       
      •  
    • mixing quantity_points of inconvertible quantities
         
      • What does subtracting a distance point to DEN airport from the Mount Everest base camp   altitude mean?
        •  
       
      •  
    • mixing quantity_points of convertible quantities but with unrelated origins
         
      • How do we subtract a point on our trip to CppCon measured relatively to our home location from   a point measured relative to the center of the Solar System?
        •  
       
      •  
     
    Important: The affine space improves safety
     
    The usage of quantity_point and affine space types, in general, improves expressiveness and type-safety of the code we write.
    "},{"location":"users_guide/framework_basics/value_conversions/","title":"Value Conversions","text":"
    One of the most important features of every unit library is to provide support for compile-time-enabled conversions of a numerical value of a quantity.
     
    A numerical value of a quantity depends on two elements:
     
       
    • quantity representation type (e.g., int, double) that stores the number expressing the amount   of quantity,
      •  
    • unit in which the quantity is being measured.
      •  
     
    Changing any of the above may require changing the value stored in a quantity.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-preserving-conversions","title":"Value-preserving conversions","text":"
    auto q1 = 5 * km;\nstd::cout << q1.in(m) << '\\n';\nquantity<si::metre, int> q2 = q1;\n
     
    The second line above converts the current quantity to the one expressed in meters and prints its contents. The third line converts the quantity expressed in kilometers into the one measured in meters.
     
    In case a user would like to perform an opposite transformation:
     
    auto q1 = 5 * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1;\n
     
    Both conversions will fail to compile.
     
    There are two ways to make the above work. The first solution is to use a floating-point representation type:
     
    auto q1 = 5. * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;\n
     
    or
     
    auto q1 = 5 * m;\nstd::cout << value_cast<double>(q1).in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;  // double by default\n
     
    Important
     
    The mp-units library follows std::chrono::duration logic and treats floating-point types as value-preserving.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-truncating-conversions","title":"Value-truncating conversions","text":"
    The second solution is to force a truncating conversion:
     
    auto q1 = 5 * m;\nstd::cout << value_cast<km>(q1) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1.force_in(km);\n
     
    This explicit cast makes it clear that something unsafe is going on. It is easy to spot in code reviews or while chasing a bug in the source code.
     
    Note
     
    q.force_in(U) is just a shortcut to run value_cast<U>(q). There is no difference in behavior between those two interfaces. q.force_in(U) was added for consistency with q.in(U) and q.force_numerical_value_in(U).
     
    Another place where this cast is useful is when a user wants to convert a quantity with a floating-point representation to the one using an integral one. Again, this is a truncating conversion, so an explicit cast is needed:
     
    quantity<si::metre, int> q3 = value_cast<int>(3.14 * m);\n
     
    Info
     
    It is often OK to use an integral as a representation type, but in general, floating-point types provide better precision and are privileged in the library as they are considered to be value-preserving.
     
    In some cases, a unit and a representation type should be changed simultaneously. Moreover, sometimes, the order of doing those operations matters. In such cases, the library provides the value_cast<U, Rep>(q) which always returns the most precise result:
     C++23C++20Portable 
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<currency, dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\nQUANTITY_SPEC(currency, dim_currency);\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n}  // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\n
     
    using namespace unit_symbols;\nPrice price{12.95 * USD};\nScaled spx = value_cast<USD_s, std::int64_t>(price);\n
     
    As a shortcut, instead of providing a unit and a representation type to value_cast, you may also provide a Quantity type directly, from which unit and representation type are taken. However, value_cast<Quantity>, still only allows for changes in unit and representation type, but not changing the type of the quantity. For that, you will have to use a quantity_cast instead.
     
    Overloads are also provided for instances of quantity_point. All variants of value_cast<...>(q) that apply to instances of quantity have a corresponding version applicable to quantity_point, where the point_origin remains untouched, and the cast changes how the \"offset\" from the origin is represented. Specifically, for any quantity_point instance qp, all of the following equivalences hold:
     
    static_assert(value_cast<Rep>(qp) == quantity_point{value_cast<Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U>(qp) == quantity_point{value_cast<U>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U, Rep>(qp) == quantity_point{value_cast<U, Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<Q>(qp) == quantity_point{value_cast<Q>(qp.quantity_from(qp.point_origin)), qp.point_origin});\n
     
    Furthermore, there is one additional overload value_cast<ToQP>(qp). This overload permits to additionally replace the point_origin with another compatible one, while still representing the same point in the affine space. Thus, it is roughly equivalent to value_cast<ToQP::unit, ToQP::rep>(qp).point_for(ToQP::point_origin). In contrast to a separate value_cast followed by point_for (or vice-versa), the combined value_cast tries to choose the order of the individual conversion steps in a way to avoid both overflow and unnecessary loss of precision. Overflow is a risk because the change of origin point may require an addition of a potentially large offset (the difference between the origin points), which may well be outside the range of one or both quantity types.
    "},{"location":"users_guide/framework_basics/value_conversions/#scaling-overflow-prevention","title":"Scaling overflow prevention","text":"
    In the case of small integral types, it is easy to overflow the representation type for every value besides 0 while performing simple and popular unit conversions. This is why the library prevents such invalid conversions at compile-time both for explicit and implicit conversions:
     
    quantity q1 = std::int8_t(1) * km;\nquantity q2 = q1.force_in(m);   // Compile-time error (1)\nif(q1 != 1 * m) { /* ... */ }   // Compile-time error (2)\n
     
       
    1. Forced conversion would overflow on scaling.
      2.  
    2. Implicit conversion that brings arguments to a common unit before comparison would overflow on    scaling.
      3.  
     
    In the above example, the conversion factor between km and m is 1'000, which is larger than the maximum value that can be stored in std::int8_t. Even if we want to convert the smallest possible integral amount (e.g., 1 km), we will overflow the quantity representation type. We decided not to allow such conversions for safety reasons despite the value of 0 km would work.
    "},{"location":"users_guide/framework_basics/value_conversions/#value-conversions-summary","title":"Value conversions summary","text":"
    The table below provides all the value conversion functions that may be run on x being the instance of either quantity or quantity_point:
     Forcing Representation Unit Member function Non-member function No Same u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x) or value_cast<T, u>(x)"},{"location":"users_guide/systems/strong_angular_system/","title":"Strong Angular System","text":""},{"location":"users_guide/systems/strong_angular_system/#some-background-information","title":"Some background information","text":"
    As per today's SI, both radian and steradian are dimensionless. This forces the convention to set the angle 1 radian equal to the number 1 within equations (similar to what natural units system does for c constant).
     
    Following Wikipedia:
     
    Wikipedia: Radian - Dimensional analysis
     
    Giacomo Prando says \"the current state of affairs leads inevitably to ghostly appearances and disappearances of the radian in the dimensional analysis of physical equations.\" For example, a mass hanging by a string from a pulley will rise or drop by \\(y=r\u03b8\\) centimeters, where \\(r\\) is the radius of the pulley in centimeters and \\(\u03b8\\) is the angle the pulley turns in radians. When multiplying \\(r\\) by \\(\u03b8\\) the unit of radians disappears from the result. Similarly in the formula for the angular velocity of a rolling wheel, \\(\u03c9=v/r\\), radians appear in the units of \\(\u03c9\\) but not on the right hand side. Anthony French calls this phenomenon \"a perennial problem in the teaching of mechanics\". Oberhofer says that the typical advice of ignoring radians during dimensional analysis and adding or removing radians in units according to convention and contextual knowledge is \"pedagogically unsatisfying\".
     
    At least a dozen scientists have made proposals to treat the radian as a base unit of measure defining its own dimension of \"angle\", as early as 1936 and as recently as 2022. This would bring the advantages of a physics-based, consistent, and logically-robust unit system, with unambiguous units for all physical quantities. At the same time the only notable changes for typical end-users would be: improved units for the quantities torque, angular momentum, and moment of inertia.
     
    Paul Quincey in his proposal \"Angles in the SI: a detailed proposal for solving the problem\" states:
     
    Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
     
    The familiar units assigned to some angular quantities are based on equations that have adopted the radian convention, and so are missing rads that would be present if the complete equation is used. The physically-correct units are those with the rads reinstated. Numerical values would not change, and the physical meanings of all quantities would also be unaffected.
     
    He proposes the following changes:
     
       
    • The radian would become either a new base unit or a 'complementary' unit
      •  
    • The steradian would become a derived unit equal to \\(1\\:rad^2\\)
      •  
    •  
      The SI units for
       
         
      • Torque would change from \\(N\\:m\\) (\\(=J\\)) to \\(J\\:rad^{-1}\\)
        •  
      • Angular momentum would change from \\(J\\:s\\) to \\(J\\:s\\:rad^{-1}\\) (i.e. \\(J/(rad/s)\\))
        •  
      • Moment of inertia would change from \\(kg\\:m^2\\) to \\(kg\\:m^2\\:rad^{-2}\\) (i.e. \\(J/(rad/s)^2\\))
        •  
       
      •  
    •  
      The option to omit the radian from the SI units for angle, angular velocity, angular frequency,   angular acceleration, and angular wavenumber would be removed, the only correct SI units being   \\(rad\\), \\(rad/s\\), \\(rad/s\\), \\(rad/s^2\\) and \\(rad/m\\) respectively.
       
      •  
     
    Paul Quincey summarizes that with the above in action:
     
    Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
     
    However, the physical clarity this would build into the SI should be recognised very quickly. The units would tell us that \\(torque \\times angle = energy\\), and \\(angular\\:momentum \\times angle = action\\), for example, in the same way that they do for \\(force \\times distance = energy\\), \\(linear\\:momentum \\times distance = action\\), and \\(radiant\\:intensity \\times solid\\:angle = radiant\\:flux\\). Dimensional analysis could be used to its full extent. Software involving angular quantities would be rationalised. Arguments about the correct units for frequency and angular frequency, and the meaning of the unit \\(Hz\\), could be left behind. The explanation of these changes would be considerably easier and more rewarding than explaining how a kilogram-sized mass can be measured in terms of the Planck constant.
    "},{"location":"users_guide/systems/strong_angular_system/#angular-quantities-in-the-si","title":"Angular quantities in the SI","text":"
    Even though the SI somehow ignores the dimensionality of angle:
     
    SI Brochure
     
    Plane and solid angles, when expressed in radians and steradians respectively, are in effect also treated within the SI as quantities with the unit one. The symbols \\(rad\\) and \\(sr\\) are written explicitly where appropriate, in order to emphasize that, for radians or steradians, the quantity being considered is, or involves the plane angle or solid angle respectively. For steradians it emphasizes the distinction between units of flux and intensity in radiometry and photometry for example. However, it is a long-established practice in mathematics and across all areas of science to make use of \\(rad = 1\\) and \\(sr = 1\\). For historical reasons the radian and steradian are treated as derived units.
     
    It also explicitly states:
     
    SI Brochure
     
    The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second, and the SI unit of activity is becquerel, implying counts per second. Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor of \\(2\\pi\\). Ignoring this fact may cause an error of \\(2\\pi\\). Note that in some countries, frequency values are conventionally expressed using \u201ccycle/s\u201d or \u201ccps\u201d instead of the SI unit \\(Hz\\), although \u201ccycle\u201d and \u201ccps\u201d are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in \\(rad/s\\). Because of this, it is recommended that quantities called \u201cfrequency\u201d, \u201cangular frequency\u201d, and \u201cangular velocity\u201d always be given explicit units of \\(Hz\\) or \\(rad/s\\) and not \\(s^{-1}\\).
    "},{"location":"users_guide/systems/strong_angular_system/#strong-angular-extensions-in-the-library","title":"Strong Angular extensions in the library","text":"
    The mp-units library strives to define physically-correct quantities and their units to provide maximum help to its users. As treating angle as a dimensional quantity can lead to many \"trivial\" mistakes in dimensional analysis and calculation, it was decided to provide additional experimental systems of quantities and units that follow the above approach and treat angle as a base quantity with a base unit of radian and solid angle as its derived quantity.
     
    As those (at least for now) are not a part of SI, the plain angle and solid angle definitions can be found in a dedicated angular system. Those definitions are also used in the isq_angle system of quantities to make the recipes for angle-based quantities like torque or angular velocity physically correct:
     
    using namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::rad;\n\nconst quantity lever = isq_angle::position_vector(20 * cm);\nconst quantity force = isq_angle::force(500 * N);\nconst quantity angle = isq_angle::angular_measure(90. * deg);\nconst quantity torque = isq_angle::torque(lever * force * angular::sin(angle) / (1 * isq_angle::cotes_angle));\n\nstd::cout << \"Applying a perpendicular force of \" << force << \" to a \" << lever << \" long lever results in \"\n          << torque.in(N * m / rad) << \" of torque.\\n\";\n
     
    The above program prints:
     
    Applying a perpendicular force of 500 N to a 20 cm long lever results in 100 N m/rad of torque.\n
     
    Note
     
    cotes_angle is a constant which represents an angle with the value of exactly 1 radian. You can find more information about this constant in Quincey.
     
    Try it on Compiler Explorer
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/","title":"Interoperability with Other Libraries","text":"
    mp-units makes it easy to cooperate with similar entities of other libraries. No matter if we want to provide interoperability with a simple home-grown strongly typed wrapper type (e.g., Meter, Timestamp, ...) or with a feature-rich quantities and units library, we have to provide specializations of:
     
       
    • a quantity_like_traits for external quantity-like type,
      •  
    • a quantity_point_like_traits for external quantity_point-like type.
      •  
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#specifying-a-conversion-kind","title":"Specifying a conversion kind","text":"
    Before we delve into the template specialization details, let's first decide if we want the conversions to happen implicitly or if explicit ones would be a better choice. Or maybe the conversion should be implicit in one direction only (e.g., into mp-units abstractions) while the explicit conversions in the other direction should be preferred?
     
    There is no one unified answer to the above questions. Everything depends on the use case.
     
    Typically, the implicit conversions are allowed in cases where:
     
       
    • both abstractions mean exactly the same, and interchanging them in the code should not change   its logic,
      •  
    • there is no significant runtime overhead introduced by such a conversion (e.g., no need for dynamic   allocation or copying of huge internal buffers),
      •  
    • the target type of the conversion provides the same or better safety to the users,
      •  
    • we prefer the simplicity of implicit conversions over safety during the (hopefully short)   transition period of refactoring our code base from the usage of one library to the other.
      •  
     
    In all other scenarios, we should probably enforce explicit conversions.
     
    The kinds of inter-library conversions can be easily configured in partial specializations of conversion traits in the mp-units library. Conversion traits should provide a static data member convertible to bool. If the value is true, then the conversion is explicit. Otherwise, if the value is false, implicit conversions will be allowed. The names of the flags are as follows:
     
       
    • explicit_import to describe conversion from the external entity to the one in this   library (import case),
      •  
    • explicit_export to describe conversion from the entity in this library to the external one   (export case).
      •  
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#quantities-conversions","title":"Quantities conversions","text":"
    For example, let's assume that some company has its own Meter strong-type wrapper:
     
    struct Meter {\n  int value;\n};\n
     
    As every usage of Meter is at least as good and safe as the usage of quantity<si::metre, int>, and as there is no significant runtime performance penalty, we would like to allow the conversion to mp_units::quantity to happen implicitly.
     
    On the other hand, the quantity type is much safer than the Meter, and that is why we would prefer to see the opposite conversions stated explicitly in our code.
     
    To enable such interoperability, we must define a partial specialization of the quantity_like_traits<T> type trait. Such specialization should provide:
     
       
    • reference static data member that provides the quantity reference (e.g., unit),
      •  
    • rep type that specifies the underlying storage type,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a quantity's raw value of rep type,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     
    For example, for our Meter type, we could provide the following:
     
    template<>\nstruct mp_units::quantity_like_traits<Meter> {\n  static constexpr auto reference = si::metre;\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Meter::value);\n  static constexpr rep to_numerical_value(Meter m) { return m.value; }\n  static constexpr Meter from_numerical_value(rep v) { return Meter{v}; }\n};\n
     
    After that, we can check that the QuantityLike concept is satisfied:
     
    static_assert(mp_units::QuantityLike<Meter>);\n
     
    and we can write the following:
     
    void print(Meter m) { std::cout << m.value << \" m\\n\"; }\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n\n  Meter height{42};\n\n  // implicit conversions\n  quantity h1 = height;\n  quantity<isq::height[m], int> h2 = height;\n\n  std::cout << h1 << \"\\n\";\n  std::cout << h2 << \"\\n\";\n\n  // explicit conversions\n  print(Meter(h1));\n  print(Meter(h2));\n}\n
     
    Note
     
    No matter if we decide to use implicit or explicit conversions, the mp-units will not allow unsafe operations to happen.
     
    If we extend the above example with unsafe conversions, the code will not compile, and we will have to fix the issues first before the conversion may be performed:
     UnsafeFixed 
    quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = height;  // Compile-time error (1)\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(h3));                            // Compile-time error (2)\nprint(Meter(h4));                            // Compile-time error (3)\nprint(Meter(h5));\n
     
       
    1. Truncation of value while converting from meters to kilometers.
      2.  
    2. Conversion of double to int is not value-preserving.
      3.  
    3. Truncation of value while converting from millimeters to meters.
      4.  
     
    quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = quantity{height}.force_in(km);\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(value_cast<int>(h3)));\nprint(Meter(h4.force_in(m)));\nprint(Meter(h5));\n
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#quantity-points-conversions","title":"Quantity points conversions","text":"
    To play with quantity point conversions, let's assume that we have a Timestamp strong type in our codebase, and we would like to start using mp-units to work with this abstraction.
     
    struct Timestamp {\n  int seconds;\n};\n
     
    As we described in The Affine Space chapter, timestamps should be modeled as quantity points rather than regular quantities.
     
    To allow the conversion between our custom Timestamp type and the quantity_point class template we need to provide the following in the partial specialization of the quantity_point_like_traits<T> type trait:
     
       
    • reference static data member that provides the quantity point reference (e.g., unit),
      •  
    • point_origin static data member that specifies the absolute point, which is the beginning of   our measurement scale for our points,
      •  
    • rep type that specifies the underlying storage type,
      •  
    • explicit_import static data member convertible to bool that specifies that the conversion   from T to a quantity type should happen explicitly (if true),
      •  
    • explicit_export static data member convertible to bool that specifies that the conversion   from a quantity type to T should happen explicitly (if true),
      •  
    • to_numerical_value(T) static member function returning a raw value of the quantity being   the offset of the point from the origin,
      •  
    • from_numerical_value(rep) static member function returning T.
      •  
     
    For example, for our Timestamp type, we could provide the following:
     
    template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n  static constexpr auto reference = si::second;\n  static constexpr auto point_origin = default_point_origin(reference);\n  static constexpr bool explicit_import = false;\n  static constexpr bool explicit_export = true;\n  using rep = decltype(Timestamp::seconds);\n  static constexpr rep to_numerical_value(Timestamp ts) { return ts.seconds; }\n  static constexpr Timestamp from_numerical_value(rep v) { return Timestamp(v); }\n};\n
     
    After that, we can check that the QuantityPointLike concept is satisfied:
     
    static_assert(mp_units::QuantityPointLike<Timestamp>);\n
     
    and we can write the following:
     
    void print(Timestamp ts) { std::cout << ts.seconds << \" s\\n\"; }\n\nint main()\n{\n  using namespace mp_units;\n  using namespace mp_units::si::unit_symbols;\n\n  Timestamp ts{42};\n\n  // implicit conversion\n  quantity_point qp = ts;\n\n  std::cout << qp.quantity_from_zero() << \"\\n\";\n\n  // explicit conversion\n  print(Timestamp(qp));\n}\n
    "},{"location":"users_guide/use_cases/interoperability_with_other_libraries/#interoperability-with-the-c-standard-library","title":"Interoperability with the C++ Standard Library","text":"
    In the C++ standard library, we have two types that handle quantities and model the affine space. Those are:
     
       
    • std::chrono::duration - specifies   quantities of time,
      •  
    • std::chrono::time_point - specifies   quantity points of time.
      •  
     
    The mp-units library comes with built-in interoperability with those types. It is enough to include the mp-units/systems/si/chrono.h file to benefit from it. This file provides:
     
       
    • partial specializations of quantity_like_traits and quantity_point_like_traits that provide   support for implicit conversions between std and mp_units types in both directions,
      •  
    • chrono_point_origin<Clock> point origin for std clocks,
      •  
    • to_chrono_duration and to_chrono_time_point dedicated conversion functions that result   in types exactly representing mp-units abstractions.
      •  
     
    Important
     
    Only a quantity_point that uses chrono_point_origin<Clock> as its origin can be converted to the std::chrono abstractions:
     
    inline constexpr struct ts_origin final : relative_point_origin<chrono_point_origin<system_clock> + 1 * h> {} ts_origin;\ninline constexpr struct my_origin final : absolute_point_origin<isq::time> {} my_origin;\n\nquantity_point qp1 = sys_seconds{1s};\nauto tp1 = to_chrono_time_point(qp1);  // OK\n\nquantity_point qp2 = chrono_point_origin<system_clock> + 1 * s;\nauto tp2 = to_chrono_time_point(qp2);  // OK\n\nquantity_point qp3 = ts_origin + 1 * s;\nauto tp3 = to_chrono_time_point(qp3);  // OK\n\nquantity_point qp4 = my_origin + 1 * s;\nauto tp4 = to_chrono_time_point(qp4);  // Compile-time Error (1)\n\nquantity_point qp5{1 * s};\nauto tp5 = to_chrono_time_point(qp5);  // Compile-time Error (2)\n
     
       
    1. my_origin is not defined in terms of chrono_point_origin<Clock>.
      2.  
    2. zeroth_point_origin is not defined in terms of chrono_point_origin<Clock>.
      3.  
     
    Here is an example of how interoperability described in this chapter can be used in practice:
     
    using namespace std::chrono;\n\nsys_seconds ts_now = floor<seconds>(system_clock::now());\n\nquantity_point start_time = ts_now;\nquantity speed = 925. * km / h;\nquantity distance = 8111. * km;\nquantity flight_time = distance / speed;\nquantity_point exp_end_time = start_time + flight_time;\n\nsys_seconds ts_end = value_cast<int>(exp_end_time.in(s));\n\nauto curr_time = zoned_time(current_zone(), ts_now);\nauto mst_time = zoned_time(\"America/Denver\", ts_end);\n\nstd::cout << \"Takeoff: \" << curr_time << \"\\n\";\nstd::cout << \"Landing: \" << mst_time << \"\\n\";\n
     
    The above may print the following output:
     
    Takeoff: 2023-11-18 13:20:54 UTC\nLanding: 2023-11-18 15:07:01 MST\n
    "},{"location":"users_guide/use_cases/wide_compatibility/","title":"Wide Compatibility","text":"
    The mp-units allows us to implement nice and terse code targeting a specific C++ version and configuration. Such code is easy to write and understand but might not be portable to some older environments.
     
    However, sometimes, we want to develop code that can be compiled on a wide range of various compilers and configurations. This is why the library also exposes and uses special preprocessor macros that can be used to ensure the wide compatibility of our code.
     
    Note
     
    Those macros are used in our short example applications as those are meant to be built on all of the supported compilers. Some still do not support std::format, C++ modules, or C++ versions newer than C++20.
    "},{"location":"users_guide/use_cases/wide_compatibility/#various-compatibility-options","title":"Various compatibility options","text":"
    Depending on your compiler's conformance, you can choose to use any of the below styles to write your code using mp-units:
     C++23C++20C++20 with header filesC++20 with header files + libfmtWide Compatibility 
    #include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n
     
    #include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <fmt/format.h>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << fmt::format(...) << \"\\n\";\n
     
    #include <iostream>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_MODULES\n#include <mp-units/compat_macros.h>\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\n// ...\n\nQUANTITY_SPEC(horizontal_length, isq::length);\n\n// ...\n\nstd::cout << MP_UNITS_STD_FMT::format(...) << \"\\n\";\n
     
    Tip
     
    Depending on your preferences, you can either write:
     
       
    • terse code directly targeting your specific compiler's abilities,
      •  
    • verbose code using preprocessor branches and macros that provide the widest compatibility   across various compilers.
      •  
    "},{"location":"users_guide/use_cases/wide_compatibility/#compatibility-macros","title":"Compatibility macros","text":"
    This chapter describes only the most essential tools the mp-units users need. All the compatibility macros can be found in the mp-units/compat_macros.h header file.
     
    Tip
     
    The mp-units/compat_macros.h header file is implicitly included when we use \"legacy\" headers in our translation units. However, it has to be explicitly included when we use C++20 modules, as those do not propagate preprocessor macros.
    "},{"location":"users_guide/use_cases/wide_compatibility/#QUANTITY_SPEC","title":"QUANTITY_SPEC(name, ...)","text":"
    Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code.
     
    This macro benefits from the new C++23 feature if available. Otherwise, it uses the CRTP idiom under the hood.
    "},{"location":"users_guide/use_cases/wide_compatibility/#mp_units_std_fmt","title":"MP_UNITS_STD_FMT","text":"
    Some of the supported compilers do not support std::format and related tools. Also, despite using a conformant compiler, some projects still choose to use fmtlib as their primary formatting facility (e.g., to benefit from additional features provided with the library).
     
    This macro resolves to either the std or fmt namespace, depending on the value of MP_UNITS_API_STD_FORMAT CMake option.
     
    To include the header files of the underlying text formatting framework, the following include should be used:
     
    #include <mp-units/ext/format.h>\n
    "},{"location":"users_guide/use_cases/wide_compatibility/#contracts","title":"Contracts","text":"
    The mp-units library internally does contract checking by default. It can be disabled with a Conan or CMake option. However, when enabled, it can use either gsl-lite or ms-gsl. To write a code that is independent from the underlying framework, the following preprocessor macros are exposed:
     
       
    • MP_UNITS_EXPECTS(expr)
      •  
    • MP_UNITS_EXPECTS_DEBUG(expr)
      •  
    • MP_UNITS_ASSERT(expr)
      •  
    • MP_UNITS_ASSERT_DEBUG(expr)
      •  
     
    Their meaning is consistent with respective gsl-lite.
     
    Also, to include the header files of the underlying framework, the following include should be used:
     
    #include <mp-units/ext/contracts.h>\n
    "},{"location":"users_guide/use_cases/working_with_legacy_interfaces/","title":"Working with Legacy interfaces","text":"
    In case we are working with a legacy/unsafe interface, we may need to extract the numerical value of a quantity and pass it to some third-party legacy unsafe interfaces.
     
    In such situations we can use .numerical_value_in(Unit) member function:
     
    void legacy_check_speed_limit(int speed_in_km_per_h);\n
     
    legacy_check_speed_limit((180 * km / (2 * h)).numerical_value_in(km / h));\n
     
    Such a getter will explicitly enforce the usage of a correct unit required by the underlying interface, which reduces a significant number of safety-related issues.
     
    The above code will not compile in case value truncation may happen. To solve the issue, we need to either use a value-preserving representation type or force the truncating conversion with .force_numerical_value_in(Unit):
     
    legacy_check_speed_limit((140 * mi / (2 * h)).force_numerical_value_in(km / h));\n
     
    The getters mentioned above always return by value as a quantity value conversion may be required to adjust it to the target unit. In case a user needs a reference to the underlying storage .numerical_value_ref_in(Unit) should be used:
     
    void legacy_set_speed_limit(int* speed_in_km_per_h) { *speed_in_km_per_h = 100; }\n
     
    quantity<km / h, int> speed_limit;\nlegacy_set_speed_limit(&speed_limit.numerical_value_ref_in(km / h));\n
     
    This member function again requires a target unit to enforce safety. This overload does not participate in overload resolution if the provided unit has a different scaling factor than the current one.
    "},{"location":"blog/archive/2025/","title":"2025","text":""},{"location":"blog/archive/2024/","title":"2024","text":""},{"location":"blog/archive/2023/","title":"2023","text":""},{"location":"blog/category/metrology/","title":"Metrology","text":""},{"location":"blog/category/wg21-updates/","title":"WG21 Updates","text":""},{"location":"blog/category/releases/","title":"Releases","text":""},{"location":"blog/page/2/","title":"Blog","text":""},{"location":"blog/archive/2024/page/2/","title":"2024","text":""}]}
\ No newline at end of file