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 The original type has now been augmented by another. The original type has now been renamed as a 'ct-quantity' representing a physical quantity whose units cannot be modified at run-time. The other type is the 'rt-quantity', whose units can be modified at run-time. The two types are of course compatible and the rt-quantity in particular is useful for further derivation, for instance into a physical quantity whose units can be set and interrogated via strings ie "mm, kgf" etc of which there is an example in the examples directory. The first question many will ask about such a library is : "How does the run-time speed/memory performance compare with using inbuilt types?." That is an important question, but to me not the most important one. (The answer is that this is implementation dependent and the current implementation is not optimal) Having used the library for some time its power seems to lie in the fact that it models a concept quite accurately from a programmers point of view. IOW what you can do with the type is restricted (by the compiler) to (some subset of) the entity that it models. The reason that this is powerful is difficult to define, but can be summed up in the saying: " a picture is worth a thousand words" I now see more clearly what those who wanted to see currency conversion and number of apples per kumquat or whatever where driving at. However these are not physical-quantities. C++ does have the ability to express those concepts, but they lie outside the remit of the concept that this library models. Nontheless such concepts would be useful. So in a network model a byte, packet etc would be a concept which would be modelled by a C++ type. Strongly enforcing the rules by which entities interact is satisfying , I guess, because it clarifies the mental picture of a program. Modelling everything by a double or an int (should number_of_bytes_received be convertible to double ... probably not etc) means everything is mush. So on a personal note designing the library has been very rewarding. As I spend much time GUI programming, it strikes me that the next useful concepts are those of model-space, view-space, paper-space etc. Here a point in space would be represented by different types which could only exist in the relevent space, but have the intelligence to perform transforms from one space to another. Similarly where one is modelling (say) magnetic flux density at a point x, y, z , the role of the view-space would be to convert form the entity in model-space to 'some representation ' in the view-space or the paper-space. The obvious candidates for the types in model-space being the ct-quantity of course. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:caesnt$nmc$1@sea.gmane.org...
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. But what about angle, solid angle and concerned quantities? Of course, I understand what exits very many other phisical quantities and it is impossible to include all them... but nevertheless? Regards, Alexey.
"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
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Eric Ford" <un5o6n902@sneakemail.com> wrote in message news:10855-92248@sneakemail.com...
The next version of my physical quantities library pqs-1-01-04 is available on my site at:
http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html ...
Andy, Thank you for your work on this very important area of development.
Thanks!
From just quickly looking at the examples, it appears that you choose to use different types for quantities that have the same dimensions but different units. I don't think that is a good idea. You can search the archives for the discussions several of us had about similar issues, mostly a few years ago. If you still disagree, I'd like to hear why.
Firstly, the units are part of the Type of a concrete quantity. If you cant declare the whole type at compile time you cant use in templates or whatever. Secondly the value is internally at the scale of the unit, because,you will always be working at some particular scale and will get the best resolution and range for that unit, which is surely where you want to be. The unit prefix is embedded in the template parameter representing the exponent to base10 of the unit, ie mm --> -3 ,km --> 3 etc.( km or um is just as valid as m for represnting length in SI) multiplication and division resolves to adding and subtracting exponents (at compile-time). At run-time only the values themselves need to be mux/divided. In case of addition/subtraction of differing units run-time conversion to one or other will occur, however usually addition and subtraction is only between dimensionaly exuivalent quantities at similar scale. In multiplication and division OTOH, a different quantity will often result, which might be at a much different scale, but due to the compile time tracking of exponents no resolution is lost...only the internal values are muxed/divided. In fact it works much like manual calculation, cancelling powers and so on. Finally (for example) energy and torque are dimensionally-equivalent, but not the same quantity, so they must have different units.
Perhaps, you could summarize the main similarities and difference between your library and other similar libraries.
As for similarities, yes I have drawn a lot from all those libraries. I originally came on boost because I had heard that there were some physical quantities libraries there. I have looked at most (all )of them including yours, however as is my usual practise I couldnt avoid starting to reinvent the wheel. Most of those libraries were built before the latest generation of compilers and I freely admit that things get much easier once (1) you have the tools. (Thanks to All those compiler vendors who only ever sem to get complaints from us coders) and (2) someone has done it before you. One other important fact is documentation. I dont say mine is good (yet), but however good the library is, if its not documented, its going nowhere. (Personal note: Get on with the documentation! ) In many of the libraries on the boost file section the units are applied at initialisation, but initialisation happens at run-time, not compile-time. Therefore you cant throw around types representing concrete-quantities at compile time. In the current version of the library I have some examples that use the ct-quantity (compile-time quantity... units fixed at compile-time ) as a building block for other things. One is the rt-quantity (run-time modifiable units ). Another derived from rt-quantity is the mapped-rt-quantity which has units which can be set via strings. At this point the combination is pretty versatile and you can start to use it right from the application user level ie drop-down lists etc to something at a lower level which has a good run-time speed performance.All unit conversions are checked at compile time, because all these types are ultimately based on the compile time type. For example the strings represent ing units input by the user, are compared against a map generated from the stream output of the ct-quantity units. Units are added in the mapped quantity like so: mapped_length length; length.add_unit<q_length::m>(); length.add_unit<q_length::mi>(); etc. User can set units and/or value etc like so: if( length.set_quantity(100, "m") ){...} The run-time quantities are entirely compatible with the ct-quantity and so you can cast betwen them
For example, there's Walter Brown's SIUnits, as well as a couple of drafts that have been uploaded to the boost vault. I know I posted ebf_units a while back to give people something to work from. And I believe there were one or two others there as well.
SIUnits is a ground-breaker, but all the innovation happens underneath the surface. Many libraries are based on its user interface, but I dont think that is so good. In my library I have tried to look more closely at the user interface, to give the types an instinctive 'look and feel' etc, for simple coding. It aims to be useful rather than to have an arguably pretty syntax. regards Andy Little
participants (2)
-
Alexey Nikitin -
Andy Little