Re: pqs - physical quantities library
Hi,
I have been continuing with my physical-quantities library over the last year, http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html and I am now seeking feedback as to whether it is worth putting this forward as a boost library proposal....
*Overview*
The physical-quantity type-family provides methods for modeling physical-quantities in C++ programs. The advantages and extra functionality over inbuilt types used in the role include, compile time dimensional-analysis checking, automatic conversion between units and an increase in source code comprehensibility. The type family includes two types, firstly a type where the units are fixed at compile-time referred to in the text as a ct-quantity and secondly a type where the units can be run-time modified, referred to in the text as an rt-quantity.
The ct-quantity has many similar features to an inbuilt-type:
- concrete type with simple,consistent semantics close to those of inbuilt-types. - aims for speed and code size performance close to that of in-built types. - requires no special framework to use.
*Application areas*
The application areas are very wide, including scientific-engineering, CAD, 3D games programming among many others.
*Future directions*
2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics interface (eg OpenGL), splines and curve analysis, successive approaximation , piecewise differentiation and integration algorithms. finite element analysis, etc etc.
Issues from the previous thread on the library and physical quantities in general
http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782
issue: Angles.
current status: Angles are implemented.There are two types, irrational (ie radians) and rational fractions of revolution ie degrees minutes etc). radians are what you might call a 'weak type'. (Though this behaviour can be modified by a macro switch). They will implicitly decay to (say) double and can be implicitly cast to double. However they also allow implicit conversions to and from degrees etc. hence an implicit conversion from degrees to radians can occur if a function has a radians argument, but not a double argument. They are also useful for output of units. --------------------- issue: Differentiating different but dimensionally equivalent types.
current status: This is implemented. --------------------- issue: Implicit conversions between units.
current status: Implicit conversions are intrinsic. They are practical instinctive and useful. --------------------- issue: You should be using mpl.
current status: Hopefully I will be able to get hold of the
Hi Andy, I just read your post in boost.devel list, and took a brief look on your angle page: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/angles.html I searched for the question: "Should angles be modulo? (IOW should 361 degrees ---> 1 degree etc.)" and was not really surprised to find it. I wanted to know how you treat this problem :). Here just my opinion: -we encountered here a problem with weights in calculations, meaning an angle was weighted via its a-priori error, which is an angle as well. Setting this angle to 360 degree was fatal. The programm crashed setting the error back to 0, what is not recommend in a division 1/error (hihi). It was fatal, but 361 degree would have been even worse, producing a result what is definitly not expected. -So we discussed if an angle bigger than 360 degree exists, and IMO - yes. Imagine you turn yourself 2 times, than you have a rotation of 720 degree and not 360 degree. I like more your idea with the modulo function, but keep in mind, that some applications use -180 to 180 degree and other 0 to 360 degree. And last, what is your opinion here: you might use clockwise-angles or counter-clockwise-angles. Is it necessary to distinguish these types? Thanks, regards, Patrick "Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:<clapov$vpe$1@sea.gmane.org>... metaprogramming
book soon, at which point I can decide whether there are advantages. ---------------------
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Patrick Kowalzick" <Patrick.Kowalzick@cern.ch> wrote in message news:F70999F630D00E4D982AC636C12D519E9C5588@cernxchg20.cern.ch...
Hi Andy,
I just read your post in boost.devel list, and took a brief look on your angle page: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/angles.html
I searched for the question: "Should angles be modulo? (IOW should 361 degrees ---> 1 degree etc.)" and was not really surprised to find it. I wanted to know how you treat this problem :).
Here just my opinion: -we encountered here a problem with weights in calculations, meaning an angle was weighted via its a-priori error, which is an angle as well. Setting this angle to 360 degree was fatal. The programm crashed setting the error back to 0, what is not recommend in a division 1/error (hihi).
I wonder if never allowing the angle to be 0 could solve this in this case( ie using 360 instead) , or would that cause more confusion?
It was fatal, but 361 degree would have been even worse, producing a result what is definitly not expected. -So we discussed if an angle bigger than 360 degree exists, and IMO - yes. Imagine you turn yourself 2 times, than you have a rotation of 720 degree and not 360 degree.
Absolutely. I think that there are various entirely separate uses of angles. One is in trigonometry using sines, cosines and so on. Another is in dividing a circle into a discrete series of steps. The classic example here is an analogue clock where the second hand particularly often moves in a discrete series of steps. A third is in measuring angular velocity eg in radians per second. A fourth is in measuring distance say using a quadrature decoder. In the last examples the number of revolutions travelled is important. In some cases an angle is being used as a number, usually when using radians, in others it is certainly not, though in these cases it may be required to convert to radians at the latest possible stage, say for conversion from polar to cartesian coordinates. I have attempted to address this by creating two classes of angles, one irrational (ie radians, ( though not grads ;-0 ),, and one as discrete fractions of revolution( ie degrees, minutes etc), which can legitimately have an integer as a value_type. Overall I arrived pretty early at the conclusion that automatically making a calculation result modulo was a bad idea.
I like more your idea with the modulo function, but keep in mind, that some applications use -180 to 180 degree and other 0 to 360 degree.
Thanks for bringing that up. I hadnt really considered that, so I will look into this aspect. I havent implemented modulo functions yet. There are a lot of things of this type to consider.
And last, what is your opinion here: you might use clockwise-angles or counter-clockwise-angles. Is it necessary to distinguish these types?
Where the angle is being used to count revolutions obviously the sign of the numeric value is the obvious choice. This does imply that the angle follows a convention, which is an obvious cause of mistakes in coordinating between different systems. Similar problems occur in graphics systems. I guess I will have to look into ways and means of enforcing conventions. However that is notoriously difficult to do at this building block level as it implies human/physical verification in most cases. eg try_move( +1)... have I actually rotated anti-clockwise ? etc. Thanks for the feedback. ---------- On a more general note, the other purpose of the OP was to try to gauge enthusiasm for making this a proposal for a boost library. Any feedback on that would be personally appreciated. OTOH ... hmmm ... perhaps the impact would be too big... the bike shed is certainly nice and warm ;-) regards Andy Little
Hi Andy,
Setting this angle to 360 degree was fatal. The programm crashed setting the error back to 0, what is not recommend in a division 1/error (hihi).
I wonder if never allowing the angle to be 0 could solve this in this case( ie using 360 instead) , or would that cause more confusion?
I think this would be more confusion. The 0 case must be caught anyway :). [snip]
Overall I arrived pretty early at the conclusion that automatically making a calculation result modulo was a bad idea.
I like more your idea with the modulo function, but keep in mind, that some applications use -180 to 180 degree and other 0 to 360 degree.
Thanks for bringing that up. I hadnt really considered that, so I will look into this aspect. I havent implemented modulo functions yet. There are a lot of things of this type to consider.
And last, what is your opinion here: you might use clockwise-angles or counter-clockwise-angles. Is it necessary to distinguish these types?
Where the angle is being used to count revolutions obviously the sign of
numeric value is the obvious choice. This does imply that the angle follows a convention, which is an obvious cause of mistakes in coordinating between different systems. Similar problems occur in graphics systems. I guess I will have to look into ways and means of enforcing conventions. However
IMO as well. the that
is notoriously difficult to do at this building block level as it implies human/physical verification in most cases. eg try_move( +1)... have I actually rotated anti-clockwise ? etc.
Oh, hmm I thought about it. Clockwise or Anticlockwise not belongs in a pqs-library. Like definitions of coordinate systems (left-handed, right-handed) it is not a question of the units/quantities, more a question of system definition. Patrick
participants (3)
-
Andy Little -
Patrick Kowalzick -
Patrick Kowalzick