matrix: rotate 90-180-270-optimize

[lytico]

Handling 90-Degree Rotations more effizient, as they have a 1-matrix

Particularly useful are the matrices for 90° and 180° rotations:

R(90^\circ) = \begin{bmatrix} 0 & -1 \\[3pt] 1 & 0 \\ \end{bmatrix} (90° counterclockwise rotation)
R(180^\circ) = \begin{bmatrix} -1 & 0 \\[3pt] 0 & -1 \\ \end{bmatrix} (180° rotation in either direction – a half-turn)
R(270^\circ) = \begin{bmatrix} 0 & 1 \\[3pt] -1 & 0 \\ \end{bmatrix} (270° counterclockwise rotation, the same as a 90° clockwise rotation)

See: http://en.wikipedia.org/wiki/Rotation_matrix
see: http://docs.oracle.com/javase/6/docs/api/java/awt/geom/AffineTransform.html
Handling 90-Degree Rotations

In some variations of the rotate methods in the AffineTransform class, a double-precision argument specifies the angle of rotation in radians. These methods have special handling for rotations of approximately 90 degrees (including multiples such as 180, 270, and 360 degrees), so that the common case of quadrant rotation is handled more efficiently. This special handling can cause angles very close to multiples of 90 degrees to be treated as if they were exact multiples of 90 degrees. For small multiples of 90 degrees the range of angles treated as a quadrant rotation is approximately 0.00000121 degrees wide. This section explains why such special care is needed and how it is implemented.

Since 90 degrees is represented as PI/2 in radians, and since PI is a transcendental (and therefore irrational) number, it is not possible to exactly represent a multiple of 90 degrees as an exact double precision value measured in radians. As a result it is theoretically impossible to describe quadrant rotations (90, 180, 270 or 360 degrees) using these values. Double precision floating point values can get very close to non-zero multiples of PI/2 but never close enough for the sine or cosine to be exactly 0.0, 1.0 or -1.0. The implementations of Math.sin() and Math.cos() correspondingly never return 0.0 for any case other than Math.sin(0.0). These same implementations do, however, return exactly 1.0 and -1.0 for some range of numbers around each multiple of 90 degrees since the correct answer is so close to 1.0 or -1.0 that the double precision significand cannot represent the difference as accurately as it can for numbers that are near 0.0.

The net result of these issues is that if the Math.sin() and Math.cos() methods are used to directly generate the values for the matrix modifications during these radian-based rotation operations then the resulting transform is never strictly classifiable as a quadrant rotation even for a simple case like rotate(Math.PI/2.0), due to minor variations in the matrix caused by the non-0.0 values obtained for the sine and cosine. If these transforms are not classified as quadrant rotations then subsequent code which attempts to optimize further operations based upon the type of the transform will be relegated to its most general implementation.

Because quadrant rotations are fairly common, this class should handle these cases reasonably quickly, both in applying the rotations to the transform and in applying the resulting transform to the coordinates. To facilitate this optimal handling, the methods which take an angle of rotation measured in radians attempt to detect angles that are intended to be quadrant rotations and treat them as such. These methods therefore treat an angle theta as a quadrant rotation if either Math.sin(theta) or Math.cos(theta) returns exactly 1.0 or -1.0. As a rule of thumb, this property holds true for a range of approximately 0.0000000211 radians (or 0.00000121 degrees) around small multiples of Math.PI/2.0.