[boost] Re: pqs - physical quantities library

From: Patrick Kowalzick (patrick.kowalzick_at_[hidden])
Date: 2004-10-27 15:51:55

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.

IMO as well.

> > 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.

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