Affine transforms - matrix algebra: equals

[Pavel Safrata]

Hi Jim,
I think I've already seen three requests for equals(), so I would like 
to provide something. This is the best we can do so I'll go for it. It 
may look a bit odd on the first sight, but after closer examination it 
makes perfect sense.

I'm almost sure that at least some of the requests were made for the 
sake of testing, but specifying a large region and small delta should 
provide something very close to the actual equality (similar to junit's 
assertEquals taking the delta). For a real-life apps you would really be 
more interested if "any pixel of a node would be visible in the same 
place on the screen", which would be pretty easy to recognize by this 
method.

Thanks,
Pavel

On 23.8.2012 0:02, Jim Graham wrote:
> Hi Pavel,
>
> That was what I was thinking of.  Is that too odd-looking for the 
> casual developer?  (On the other hand, do we want casual developers 
> doing operations like this?)
>
> And, as always, the alternative is to punt for this release until we 
> get a more well-defined demand for how this would be used.
>
> I've provided my input, but I don't have strong opinions about the 
> conclusion either way...
>
>             ...jim
>
> On 8/22/2012 12:28 AM, Pavel Safrata wrote:
>> 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
>>>>
>>>>
>>
>>