"Alexey Nikitin" <reductor@newmail.ru> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
The next version of my physical quantities libary pqs-1-01-04 is available on my site at:
http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html
It is good library in my opinion.
Thanks .
But what about angle, solid angle and concerned quantities?
I have been thinking about this and I hope I am starting to deal with it. The first point to note is that the physical quantities library can only perform math on what I would call "anonymous" physical quantities, that is quantities whose only real attribute(apart from units) is the signature created by the dimensions of their base units. An immediate problem with this is that some quantities are dimensionally-equivalent but are referring to different quantities. Examples are torque and energy. In SI terms both are represented in base units as: kg.m+2.s-2 so in a calculation of force * distance , there is no way for the library to know which quantity the programmer requires. As things stand currently I have opted to make one named quantity the "default", which in this case would be energy so the output would be in joules. If the programmer requires output in N.m then a cast to a type representing torque is required: q_force::N F(1); q_length::m L(1); os << F * L << '\n'; q_torque::N_m torque = F * L; // ok implicit conversion to named // dimensionally equivalent type os << torque << '\n'; produces : 1 J 1 N.m However I have recently been thinking in terms of making any (ambiguous) result of a calculation an anonymous quantity, so that the above result would produce 1 kg.m+2.s-2 // wish s/he would say Which quantity s/he wants 1 N.m // Ok its a torque. In other words the programmer must explicitly state the required type by means of a cast, so where J was required: os << q_energy::J( F * L ) << '\n'; // ok conversion to named but // dimensionally equivalent type This is quite appealing because the idea of a "default quantity" has no logical base. An anonymous quantity can be expressed easily (as above) and this expresses more honestly what is actually going on underneath the surface. The relevance of this to angles and solid angles is that the same approach can be used. In any calculation whose result is dimensionless, the resulting type would be an anonymous dimensionless quantity (ie a numeric type) , which is and will be represented in pqs by a numeric (ie (say) double). It would seem appropriate that angles would be explicitly constructible from a numeric type and implicitly convertible back again. This is based on the fact that a radian is just a number with extra attributes to distinguish it for output purposes and extra constraints. Despite the fact that angles are part of the S.I. base units I am not intending to make angles part of the physical quantities classes in pqs, but rather I hope to add a new type-family representing angles. The angle type would have various purposes. First to help legibility, second to provide scaling to/from numeric and other angle types and third to provide units for ouput, finally to provide type safety in other operations ,which accept angles but not numerics (due to implicit conversion) in their arguments. This seems appropriate. You can use angles in operations requiring numeric types (ie they lose their extra attributes ... "any number is ok here"), but not the other way around ..."Sorry only angles allowed in here". The angle type could also be used separately from the physical quantities classes themselves. If that works I hope it can be applied similarly to solid angle. I hope to get this up and running in the next version to see how well it performs in practise. I too need angles!
Of course, I understand what exits very many other phisical quantities and it is impossible to include all them... but nevertheless?
Its a valid point and a big void in the library as it stands. regards Andy Little