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