Affine transforms - matrix algebra: equals

[Pavel Safrata]

Hi Jim,
thanks for the elaboration. The idea of comparing the original and 
translated points came to my mind as well but I was stuck on how to 
define the region of interest. So what if we introduced this:

Transform.similarTo(Transform t, Bounds range, double maximumDelta)

Thanks,
Pavel

On 21.8.2012 23:31, Jim Graham wrote:
> I think a single value might not be best for reasons that I think you 
> pointed out in a later email.
>
> If I was going to compare transforms, I would want to know "are all 
> coordinates in this range transformed into values in the output space 
> that are within this error bound of each other".  In other words:
>
>     forall x,y[,z] in region of interest
>         if (t1(x,y[,z]) not within E of t2(x,y[,z]))
>             return false
>     return true
>
> Obviously, you'd just calculate the potential differences of t1 and t2 
> rather than do an exhaustive search, but that would define the 
> potential operation of interest.  This can't be done by simply 
> comparing the elements of t1 and t2 to be "within E" because a 
> translate factor has a simpler impact on the differences than a scale 
> factor.  If we embrace perspective transforms then having a 
> perspective factor change by a very tiny number would cause huge 
> differences in the output due to the implicit divide that will come 
> when the coordinate is normalized.
>
> I guess I'd vote to leave it out for now and let developers write 
> their own?
>
>             ...jim
>
> On 8/21/2012 11:05 AM, 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)?
>>
>> 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
>>
>>