Affine transforms - matrix algebra: equals

[Jim Graham]

One problem is that transforms can often produce indistinguishable 
results, but not compare equal.  They are based on floating point and == 
is not a good operator to use in floating point code.  Nearly all cases 
where one might expect to find that in the rendering code we tend to 
have "closeTo(a, b, err)" methods instead which compare the values with 
an error bound.

As a result, I think it might be better to leave hashCode and the 
Object.equals() methods alone, avoid setting the expectation that they 
are useful operations on transforms, and instead implement an alternate 
method that does not override or overload those methods and points out 
the potential caveats of Transform comparison:

	Transform.?identical/similar?(tx, errbound);

		...jim

On 8/21/2012 10:34 AM, Pavel Safrata wrote:
> Hello again,
> there are some requests for implementing Transform.equals(). Determining
> whether or not two transforms equal may indeed be useful. The question
> is: do we want to implement equals() and hashCode() and thereby break
> usage of (mutable) Transforms in hash-based collections? Or would some
> transformEquals(Transform) method do? I like neither of those options. I
> would probably do as much as possible to avoid implementing hashCode()
> for mutable objects but let me first hear some opinions on this..
>
> Thanks,
> Pavel