Custom comparator for floating point types collections

[Vladimir Sapronov]

Currently trove collections rely on usual == comparison of types. This might be a problem for floating point types because of precision problem. For example, TDoubleSet.contains(double v) method is not very useful because in current implementations it will be compare for exact equality and will return false most of the time(no place where I can provide my epsilon). Same issue with sorting. So, I thought it might be good to introduce custom comparator into implementations of floating type collections.

[Rob Eden]

We should arguably be using Double.doubleToLongBits as Double does for its equals() method.

What other method are you thinking of? Something that uses a delta such as JUnit's assert method? The problem I see with that approach would be fulfilling the equals/hashCode contract so that you come up with the matching (and good) hashcode for values that would be within the delta.

[Vladimir Sapronov]

I was thinking of providing this flexibility to the library user. So in constructor I can provide my implementation of IDoubleComparator { int compare(double a, double b); }. In my case (you are right) I will use something similar to JUnit but others might use some other logic. For example, currently I use standard java TreeSet<Double> which does autoboxing which I would like to avoid. It would be easy to replace with TDoubleSet if it would have implementation with custom comparator parameterization (like TreeSet<T> has).

[Vladimir Sapronov]

Please let me know if this is out of scope or non-priority. I might implement sorted collections myself (and implement trove collections API), let me know if this is something that could be included into trove later. Otherwise I would solve my local need and do not implement such wide collections interface.

Thanks

[Rob Eden]

I think it's a fine request and in scope, but it sounds like it makes sense to roll it into issue #11.

As for timing, contributions are always good. ;-) It's been something people have wanted for a while but hasn't percolated to the top of my list and no one else has contributed anything.

[Rob Eden]

Duplicate of #11.