Affine transforms - matrix algebra: equals

[Jim Graham]

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