compareTo() for primitive types?

Discussion in 'Java' started by Andreas Leitgeb, Nov 13, 2006.

  1. Suppose I've got a class that contains an "int" field.
    Then I want to make my class "Comparable", and the
    order depends on the int-field.

    what's the standard idiom to use in the overridden
    compareTo method?

    return that.intVar - this.intVar;
    is surely wrong, due to wraparound, as one can see when
    comparing MAX_VALUE to MIN_VALUE
    Using Integer.compareTo() involves boxing twice, which feels
    too heavy.

    Does one need to nest two ?:-operations (or if's), or is
    there some nicer idiom?
    Andreas Leitgeb, Nov 13, 2006
    #1
    1. Advertising

  2. Andreas Leitgeb <> writes:

    > Suppose I've got a class that contains an "int" field.
    > Then I want to make my class "Comparable", and the
    > order depends on the int-field.
    >
    > what's the standard idiom to use in the overridden
    > compareTo method?
    >
    > return that.intVar - this.intVar;
    > is surely wrong, due to wraparound, as one can see when
    > comparing MAX_VALUE to MIN_VALUE
    > Using Integer.compareTo() involves boxing twice, which feels
    > too heavy.
    >
    > Does one need to nest two ?:-operations (or if's), or is
    > there some nicer idiom?


    Either one will work, in almost every domain, but I'd
    go ahead and use Integer's compareTo(), since it's already
    written and makes it obvious that you're not doing anything
    unusual.

    You've likely already spent more time thinking about this
    than will be spent boxing and unboxing primitives in
    the lifetime of every program you'll ever write during
    your career. Don't fear the wrapper classes.

    --
    Mark Jeffcoat
    Austin, TX
    Mark Jeffcoat, Nov 13, 2006
    #2
    1. Advertising

  3. Andreas Leitgeb

    djthomp Guest

    Re: compareTo() for primitive types?

    On Nov 13, 7:54 am, Andreas Leitgeb <>
    wrote:
    > Suppose I've got a class that contains an "int" field.
    > Then I want to make my class "Comparable", and the
    > order depends on the int-field.
    >
    > what's the standard idiom to use in the overridden
    > compareTo method?
    >
    > return that.intVar - this.intVar;
    > is surely wrong, due to wraparound, as one can see when
    > comparing MAX_VALUE to MIN_VALUE
    > Using Integer.compareTo() involves boxing twice, which feels
    > too heavy.
    >
    > Does one need to nest two ?:-operations (or if's), or is
    > there some nicer idiom?


    You might take a look at the implementation of Integer.compareTo(). I
    seem to recall it does something like:

    if (thisVal < anotherVal)
    return -1;
    else if (thisVal > anotherVal)
    return 1;
    else
    return 0;
    djthomp, Nov 13, 2006
    #3
  4. Re: compareTo() for primitive types?

    djthomp <> wrote:
    > On Nov 13, 7:54 am, Andreas Leitgeb <>
    >> Suppose I've got a class that contains an "int" field.
    >> what's the standard idiom to use in the overridden
    >> compareTo method?


    >> Using Integer.compareTo() involves boxing twice, which feels
    >> too heavy.


    > You might take a look at the implementation of Integer.compareTo(). I
    > seem to recall it does something like:
    > if (thisVal < anotherVal)
    > return -1;
    >...


    < From: Mark Jeffcoat <>
    < You've likely already spent more time thinking about this
    < than will be spent boxing and unboxing primitives in
    < the lifetime of every program you'll ever write during
    < your career. Don't fear the wrapper classes.

    Ok, thanks to both! I think 99% of situations will be fine
    with Integer.compareTo()+boxing, the rest I'll have to do
    with "if ... else if ... else ...".

    PS: I hoped to have missed something like python's <=> operator.
    Andreas Leitgeb, Nov 13, 2006
    #4
  5. Andreas Leitgeb

    Chris Uppal Guest

    Mark Jeffcoat wrote:

    > Either one will work, in almost every domain, but I'd
    > go ahead and use Integer's compareTo(), since it's already
    > written and makes it obvious that you're not doing anything
    > unusual.
    >
    > You've likely already spent more time thinking about this
    > than will be spent boxing and unboxing primitives in
    > the lifetime of every program you'll ever write during
    > your career. Don't fear the wrapper classes.


    My gut feeling is that this is probably false -- autoboxing is /not/ free and
    if used with large amounts of data, or in contexts where the number of
    operations is more than linear in the amount of data (as is the case for
    sorting -- the OP's target application) then it should not be used lightly.

    This is /especially/ true since the direct representation (either as a double
    conditional, or by doing the simple arithmetic with longs) is at least as
    transparent as invoking the stuff in Integer.

    -- chris
    Chris Uppal, Nov 14, 2006
    #5
  6. "Chris Uppal" <-THIS.org> writes:

    > Mark Jeffcoat wrote:
    >
    >> You've likely already spent more time thinking about this
    >> than will be spent boxing and unboxing primitives in
    >> the lifetime of every program you'll ever write during
    >> your career. Don't fear the wrapper classes.

    >
    > My gut feeling is that this is probably false -- autoboxing is /not/ free and
    > if used with large amounts of data, or in contexts where the number of
    > operations is more than linear in the amount of data (as is the case for
    > sorting -- the OP's target application) then it should not be used lightly.
    >


    It's possible that I'm exaggerating, but I've never
    seen anything in a profiler that suggested that it
    might be causing a problem, and I have strong allergies
    to thinking about performance concerns at all during
    normal development.

    I suspect the JIT compiler does something clever
    in the simpler cases. My gut feeling is that inlining
    Integer.compareTo() is a simpler case, but I'd yield
    to contrary profiling.

    --
    Mark Jeffcoat
    Austin, TX
    Mark Jeffcoat, Nov 14, 2006
    #6
  7. Andreas Leitgeb

    Mark Rafn Guest

    >>> You've likely already spent more time thinking about this
    >>> than will be spent boxing and unboxing primitives in
    >>> the lifetime of every program you'll ever write during
    >>> your career. Don't fear the wrapper classes.


    >> Mark Jeffcoat wrote:
    >> My gut feeling is that this is probably false -- autoboxing is /not/ free
    >> and if used with large amounts of data, or in contexts where the number of
    >> operations is more than linear in the amount of data (as is the case for
    >> sorting -- the OP's target application) then it should not be used lightly.


    >"Chris Uppal" <-THIS.org> writes:
    >It's possible that I'm exaggerating, but I've never
    >seen anything in a profiler that suggested that it
    >might be causing a problem, and I have strong allergies
    >to thinking about performance concerns at all during
    >normal development.


    This depends a LOT on the type of application you're writing. In most
    business logic, Chris is completely right - just do what's clearest to the
    developers and most provably correct, worrying about microperformance a lot
    less than your overall algorithms unless the profiler says otherwise.

    >I suspect the JIT compiler does something clever
    >in the simpler cases.


    Additionally, Sun's wrapper objects cache autobox objects for 256 values
    near 0. However, Mark's right too: it's not magic. There _IS_ a hit for
    this, and if you're writing an app where you think it's important, you're
    probably right, and you should take the time to do the right thing (and
    document that you've thought about and covered the edge cases).

    >My gut feeling is that inlining Integer.compareTo() is a simpler case, but
    >I'd yield to contrary profiling.


    Yup, that about covers it.
    --
    Mark Rafn <http://www.dagon.net/>
    Mark Rafn, Nov 14, 2006
    #7
  8. (Mark Rafn) writes:

    > This depends a LOT on the type of application you're writing. In most
    > business logic, Chris is completely right - just do what's clearest to the
    > developers and most provably correct, worrying about microperformance a lot
    > less than your overall algorithms unless the profiler says otherwise.
    >
    >>I suspect the JIT compiler does something clever
    >>in the simpler cases.

    >
    > Additionally, Sun's wrapper objects cache autobox objects for 256 values
    > near 0. However, Mark's right too: it's not magic. There _IS_ a hit for
    > this, and if you're writing an app where you think it's important, you're
    > probably right, and you should take the time to do the right thing (and
    > document that you've thought about and covered the edge cases).
    >


    You've switched the references, here: I'm defending the
    idea of ignoring any potential performance hit from boxing
    primitives.

    The key difference of opinion, I suspect, is in your last
    paragraph: I think that intelligent, experienced, well-meaning
    programmers will be wrong about the magnitude (and occasionally
    even the direction) of performance choices like this when
    they try to make those decisions ahead of time.

    (I admit occasional exceptions; for example, when your
    entire program is to implement a single algorithm. Even
    so, why cultivate bad habits?)

    --
    Mark Jeffcoat
    Austin, TX
    Mark Jeffcoat, Nov 14, 2006
    #8
  9. Andreas Leitgeb

    Daniel Pitts Guest

    Re: compareTo() for primitive types?

    djthomp wrote:
    > On Nov 13, 7:54 am, Andreas Leitgeb <>
    > wrote:
    > > Suppose I've got a class that contains an "int" field.
    > > Then I want to make my class "Comparable", and the
    > > order depends on the int-field.
    > >
    > > what's the standard idiom to use in the overridden
    > > compareTo method?
    > >
    > > return that.intVar - this.intVar;
    > > is surely wrong, due to wraparound, as one can see when
    > > comparing MAX_VALUE to MIN_VALUE
    > > Using Integer.compareTo() involves boxing twice, which feels
    > > too heavy.
    > >
    > > Does one need to nest two ?:-operations (or if's), or is
    > > there some nicer idiom?

    >
    > You might take a look at the implementation of Integer.compareTo(). I
    > seem to recall it does something like:
    >
    > if (thisVal < anotherVal)
    > return -1;
    > else if (thisVal > anotherVal)
    > return 1;
    > else
    > return 0;


    In JDK 1.5.0_05 src.zip, the Integer.compareTo implementation is:

    public int compareTo(Integer anotherInteger) {
    int thisVal = this.value;
    int anotherVal = anotherInteger.value;
    return (thisVal<anotherVal ? -1 : (thisVal==anotherVal ? 0 : 1));
    }
    Daniel Pitts, Nov 14, 2006
    #9
  10. Re: compareTo() for primitive types?

    Daniel Pitts <> wrote:
    > In JDK 1.5.0_05 src.zip, the Integer.compareTo implementation is:
    > public int compareTo(Integer anotherInteger) {
    > int thisVal = this.value;
    > int anotherVal = anotherInteger.value;
    > return (thisVal<anotherVal ? -1 : (thisVal==anotherVal ? 0 : 1));
    > }


    If (back to the original usecase) that one int-field isn't the
    last criterion of some cascade, then

    // previous criteria...
    if (that.intVar > this.intVar) return 1;
    if (that.intVar < this.intVar) return -1;
    // continue with next criterion...

    is probably both clearest and fastest, I'd guess.
    Andreas Leitgeb, Nov 15, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?ISO-8859-1?Q?S=F8ren_Bak?=

    Collections API for primitive types

    =?ISO-8859-1?Q?S=F8ren_Bak?=, Aug 27, 2003, in forum: Java
    Replies:
    0
    Views:
    407
    =?ISO-8859-1?Q?S=F8ren_Bak?=
    Aug 27, 2003
  2. munki
    Replies:
    5
    Views:
    3,064
    Michael Borgwardt
    Oct 8, 2003
  3. Replies:
    7
    Views:
    600
    Victor Bazarov
    May 9, 2005
  4. Marc Dzaebel

    compareTo() for primitive types?

    Marc Dzaebel, Jun 1, 2006, in forum: Java
    Replies:
    8
    Views:
    14,531
    Wibble
    Jun 2, 2006
  5. Daniel Pitts
    Replies:
    7
    Views:
    471
Loading...

Share This Page