Discrepancies between 2geom's rotate and Inkscape's (libnr's) rotate
While converting some of Inkscape's libnr tests I found the following discrepancies between the two rotate classes: - Rotate(.234).inverse() != Rotate(-.234) in 2geom but not in libnr - Rotate(.234)*Rotate(0) != Rotate(.234) (idem.) - Rotate(0)*Rotate(.234) != Rotate(.234) (idem.) - b * Geom::Rotate::from_degrees(90.) != Geom::rot90(b) (idem.)
My guess is that at least the first three have to do with how the rotation vectors are normalized. To me the most logical thing to do would be to eliminate the (in principle unnecessary) normalizations when computing the inverse of a rotation or when composing two rotations.
On Fri, Jul 04, 2008 at 06:23:53PM +0200, Jasper van de Gronde wrote:
While converting some of Inkscape's libnr tests I found the following discrepancies between the two rotate classes:
- Rotate(.234).inverse() != Rotate(-.234) in 2geom but not in libnr
- Rotate(.234)*Rotate(0) != Rotate(.234) (idem.)
- Rotate(0)*Rotate(.234) != Rotate(.234) (idem.)
- b * Geom::Rotate::from_degrees(90.) != Geom::rot90(b) (idem.)
About a month ago, it was noted that one of the 2geom rotate routines had a bug in it; so I'd suggest checking whether or not approximate equality holds.
Re normalizations, the comment in libnr's rotate::inverse is relevant:
/** \todo * In the usual case that vec is a unit vector (within rounding error), * dividing by len_sq is either a noop or numerically harmful. * Make a unit_rotate class (or the like) that knows its length is 1. */
I.e. currently libnr's rotate class can represent rotation and uniform scaling at the same time. However, it's fairly rare that we use this facility, so probably the numerical cost of dividing by len_sq (i.e. inverting the length) outweighs that utility.
Changing requires looking at all users of the rotate(x,y) and rotate(p) constructors.
pjrm.
participants (2)
-
Jasper van de Gronde -
Peter Moulder