Affine transforms - matrix algebra: equals

[Jim Graham]

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