Mail Archives: geda-user/2015/09/13/17:49:13
> Yes. But that's more of a problem with floating point.
"60" isn't floating point, though. Angles are convenient numbers to
use, it's the result of using those angles that gets messy. Using a
vector for angles means that pretty much *every* angle becomes a
floating point problem, because the actual angle will always be some
epsilon away from what the user intended.
> What you really want in the Cartesian representation is sines and
> cosines, but sin( 60 degrees ) is irrational, not representable in
> floating point.
That's what I said. Most rational angles cannot be represented as a
rational vector.
Also, most rational vectors do not have a rational magnitude.
> Perfect undo is easy. Angles are represented by pairs of integers,
> with no roundoff error within that closed system. You only
> accumulate error with respect to your external expectations going
> forward. But how many layers of rotation do you typically have in a
> practical design? Maybe three, four? Within the system, all
> calculations are exact.
I bring it up only because it's been an issue before, before the
nanometers switch. Rotating by X then -X did not result in the
original.
I'm also now thinking "select all elements rotated by 60 degrees" is
going to be an imprecise operation (not that we had it *at all*
before now).
We also have to be careful that "rotate left 60" is the same as
"rotate right -60". Hmmm... the vector needs to be normalized (a unit
vector), so an angle like "123/456" would have to include a scale,
which would either be itself irrational (square roots) or introduce
yet another epsilon. Which means undoing a rotation might not be
exact.
Perhaps the only way to avoid problems with sin/cos is to avoid using
them at all - you always store the relationships between parts and
subparts as a translation and a rotation, so the rotation (in degrees
or whatever) can be retained as-is, rather than the result of using
that rotation.
- Raw text -