mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Anil <robin.a...@gmail.com>
Subject Re: compareTo() issue
Date Fri, 08 Jan 2010 18:26:45 GMT
That one was specifc to ordering of sub patterns in Fpgrowth stage. I did
that as an optimisation where in the object needs to be at a random place in
the heap if they are of equal length and support. Since it is the most
called function in the entire algorithm, I got some performance benefit from
it, because there were many patterns of the same length and support by
differnet pattern underneath. Plus there is no need of comparing the two
arrays which would be expensive.  If the compareTo contract has to be
maintained, I will move it out to another class and use it as the comparator
during heap initialization.


public int compareTo(Pattern cr2) {
    long support2 = cr2.support();
    int length2 = cr2.length();
    if (support == support2) {
      if (length == length2) {
        // if they are of same length and support order randomly
        return 1;
      } else {
        return length - length2;
      }
    } else {
      if (support > support2) {
        return 1;
      } else {
        return -1;
      }
    }
  }

On Fri, Jan 8, 2010 at 2:58 PM, Sean Owen <srowen@gmail.com> wrote:

> I see some compareTo() methods with logic like this --
>
> int a = object1.foo();
> int b = object2.foo();
> if (a == b) {
>  return 1; // order randomly
> } else {
>  return a - b;
> }
>
> Three problems here:
> - This does not produce a random ordering when used with a sort; it's
> quite deterministic
> - This violates the contract of compareTo() -- true that
> a.compareTo(b) = -b.compareTo(a)
> - "a-b" can overflow and give the wrong sign
>
> Mind if I fix?
>
> There's still code going in with lots of variances from what I think
> are our agreed standards too.
>
> Sean
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message