[boost] Re: pqs - physical quantities library

From: Patrick Kowalzick (Patrick.Kowalzick_at_[hidden])
Date: 2004-10-22 11:00:24

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_at_[hidden]> wrote in message
news:<clapov$vpe$1_at_[hidden]>...
> 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
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
>