From: Patrick Kowalzick (Patrick.Kowalzick_at_[hidden])
Date: 2004-10-22 11:00:24
I just read your post in boost.devel list, and took a brief look on your
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?
"Andy Little" <andy_at_[hidden]> wrote in message
> I have been continuing with my physical-quantities library over the
> and I am now seeking feedback as to whether it is worth putting this
> as a boost library proposal....
> The physical-quantity type-family provides methods for modeling
> physical-quantities in C++ programs. The advantages and extra
> over inbuilt types used in the role include, compile time
> dimensional-analysis checking, automatic conversion between units and
> increase in source code comprehensibility. The type family includes
> types, firstly a type where the units are fixed at compile-time
> in the text as a ct-quantity and secondly a type where the units can
> 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
> - aims for speed and code size performance close to that of in-built
> - requires no special framework to use.
> *Application areas*
> The application areas are very wide, including scientific-engineering,
> 3D games programming among many others.
> *Future directions*
> 2D and 3D vector quantities, scene-graphs and scene-modelling,
> interface (eg OpenGL), splines and curve analysis, successive
> , piecewise differentiation and integration algorithms. finite element
> analysis, etc etc.
> Issues from the previous thread on the library and physical quantities
> issue: Angles.
> current status: Angles are implemented.There are two types, irrational
> radians) and
> rational fractions of revolution ie degrees minutes etc). radians are
> you might call a 'weak type'. (Though this behaviour can be modified
> macro switch). They will implicitly decay to (say) double and can be
> implicitly cast to double. However they also allow implicit
> and from degrees etc. hence an implicit conversion from degrees to
> can occur if a function has a radians argument, but not a double
> 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
> issue: You should be using mpl.
> current status: Hopefully I will be able to get hold of the
> book soon, at
> which point I can decide whether there are advantages.
> Andy Little
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk