Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > compareTo() for primitive types?

Reply
Thread Tools

compareTo() for primitive types?

 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-13-2006
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 ?perations (or if's), or is
there some nicer idiom?

 
Reply With Quote
 
 
 
 
Mark Jeffcoat
Guest
Posts: n/a
 
      11-13-2006
Andreas Leitgeb <(E-Mail Removed)> 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 ?perations (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
 
Reply With Quote
 
 
 
 
djthomp
Guest
Posts: n/a
 
      11-13-2006
On Nov 13, 7:54 am, Andreas Leitgeb <(E-Mail Removed)>
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 ?perations (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;

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-13-2006
djthomp <(E-Mail Removed)> wrote:
> On Nov 13, 7:54 am, Andreas Leitgeb <(E-Mail Removed)>
>> 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 <(E-Mail Removed)>
< 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.
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      11-14-2006
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


 
Reply With Quote
 
Mark Jeffcoat
Guest
Posts: n/a
 
      11-14-2006
"Chris Uppal" <(E-Mail Removed)-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
 
Reply With Quote
 
Mark Rafn
Guest
Posts: n/a
 
      11-14-2006
>>> 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" <(E-Mail Removed)-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.velocityreviews.com/forums/(E-Mail Removed) <http://www.dagon.net/>
 
Reply With Quote
 
Mark Jeffcoat
Guest
Posts: n/a
 
      11-14-2006
(E-Mail Removed) (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
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      11-14-2006

djthomp wrote:
> On Nov 13, 7:54 am, Andreas Leitgeb <(E-Mail Removed)>
> 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 ?perations (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));
}

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      11-15-2006
Daniel Pitts <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Default primitive values from primitive Class<?> object. Daniel Pitts Java 7 10-23-2008 04:30 PM
How to cast object to primitive array? antonyliu2002@yahoo.com ASP .Net 3 04-08-2006 07:33 PM
Primitive vs. non-primitive l-value richardclay09@yahoo.co.uk C++ 7 05-09-2005 02:52 PM
ObjectDataSource non-primitive data fields DoesDotNet ASP .Net 2 04-22-2005 05:33 PM
How to pass other than a primitive type as a property of a custom control? Henri ASP .Net 0 05-17-2004 02:41 PM



Advertisments