Affine transforms - matrix algebra: equals

[Pavel Safrata]

Sounds good.

The errbound is a double wich says that particular elements can differ 
by its value to be considered "equal", right? Or should it rather be 
some multiplicative coefficient?

Seems like we again face the problem of forbidden isSimilar/isIdentical. 
Can we find some verb to improve code readability? What about 
Transform.resembles(Transform t, double range)?

Thanks,
Pavel

On 21.8.2012 19:52, Jim Graham wrote:
> 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