Affine transforms - matrix algebra: equals

[Pavel Safrata]

On 21.8.2012 20:05, Pavel Safrata wrote:
> 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)?

Not a nice name, is it? I propose

public boolean Transform.similarTo(Transform t, double maximumDelta)

The "To" makes the meaning more clear without using a verb, I've chosen 
"similar" because "identical" might be confused with "identity".

Thanks,
Pavel


>
> 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
>
>