Affine transforms - matrix algebra: equals
pavel.safrata at oracle.com
Tue Aug 21 13:36:01 PDT 2012
On 21.8.2012 20:05, 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)?
Not a nice name, is it? I propose
public boolean Transform.similarTo(Transform t, double maximumDelta)
The "To" makes the meaning more clear without using a verb, I've chosen
"similar" because "identical" might be confused with "identity".
> 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);
>> On 8/21/2012 10:34 AM, Pavel Safrata wrote:
>>> Hello again,
>>> there are some requests for implementing Transform.equals().
>>> 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..
More information about the openjfx-dev