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.