# Affine transforms - matrix algebra: equals

Pavel Safrata pavel.safrata at oracle.com
Wed Aug 22 00:28:15 PDT 2012

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

```