Mail Archives: geda-user/2015/09/13/18:47:21
On Sep 13, 2015, at 3:48 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>> 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.
If you have a Pythagorean triple (x, y, h), x^2+y^2==h^2, it represents an angle arctan(y/x). Those are not generally nice angles in degrees, but you can get as close as you want to any particular angle. The advantage of this, though, is that the set of rational translations and Pythagorean rotations of a point about the origin is closed. This means that repeated rotations and translations never produce any “round off” error within this system. You might see errors from a point of view outside, like translations on a grid or angles in degrees, but as long as you do all of the calculations inside the system the results are exact, and can be related to the external grid or angles to any precision you might desire.
>
>> 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.
In the Pythagorean/rational system, if you make the rotation matrix for -X the transpose of the rotation matrix for X, you get the original back. That’s mathematically the natural way to do it. You would want to compose rotations by matrix multiplication rather than angle addition. Not hard in a decent high level language.
>
> 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.
Nope. If the basis is Pythagorean triples, the normalization is always an integer, by definition. In this system, translations may be any rational number, but only a restricted subset of integer pairs y/x are allowed for rotations.
> Which means undoing a rotation might not be
> exact.
If you do it right, keeping your math inside this closed system, it’s all exact. It becomes inexact when you export for rendering on a grid, but that’s always a problem.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -