compareTo() for primitive types?

M

Marc Dzaebel

Hi there,

l1,l2 are of type "long" and I need to compare them. Currently I do it by

new Long(l1).compareTo(l2) // autoboxing

However, there should be a static method in Long.compareTo(long l1, long l2)
in order to avoid the generation of two unnecessary Long objects? The same
problem occurrs for other primitive types. I would always have to write a
methods like:

public static int compareTo(long l1, long l2) {
return l1<l2? -1 : l1==l2? 0 : 1;
}

Shouldn't the current design be refactored in this way or do I miss
something? May be the costs of creating the two objects (and collect them)
are not as high as I assume?

Thanks, Marc
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Dzaebel schreef:
Hi there,

l1,l2 are of type "long" and I need to compare them. Currently I do it by

new Long(l1).compareTo(l2) // autoboxing

However, there should be a static method in Long.compareTo(long l1, long l2)
in order to avoid the generation of two unnecessary Long objects? The same
problem occurrs for other primitive types. I would always have to write a
methods like:

public static int compareTo(long l1, long l2) {
return l1<l2? -1 : l1==l2? 0 : 1;
}

Shouldn't the current design be refactored in this way or do I miss
something? May be the costs of creating the two objects (and collect them)
are not as high as I assume?

Do you rely on the result of compareTo being -1 or +1? You shouldn’t!
If not, then why even write a function and not just use l1-l2?

Same goes for ints. For bytes, shorts and chars the situation is
different, because of auto-conversion. But then again, compareTo gives
you an int too, so this is exactly what you want.

Only for floating point numbers would you have to watch out, because
float1-float2 is not always 0, even when they have the ‘same’ value (or
the inverse).

H.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEfueUe+7xMGD3itQRAtxLAJ43BzqSNYRI0af8ay6hczcX88Z7mwCfW2li
bF8Yi1sieflft7HmojKe6OY=
=zXWI
-----END PGP SIGNATURE-----
 
P

Patricia Shanahan

Hendrik said:
Do you rely on the result of compareTo being -1 or +1? You
shouldn’t! If not, then why even write a function and not just use
l1-l2?

42L is greater than Long.MIN_VALUE, but 42L - Long.MIN_VALUE is
negative. The problem is that the subtraction result is greater than the
maximum value that can be stored in a long, and wraps around to a
negative number.
Same goes for ints. For bytes, shorts and chars the situation is
different, because of auto-conversion. But then again, compareTo
gives you an int too, so this is exactly what you want.

The auto-conversion really helps here, because no pair of bytes, chars,
or shorts can have a difference greater than Integer.MAX_VALUE.

Patricia
 
T

Thomas Weidenfeller

Marc said:
l1,l2 are of type "long" and I need to compare them. Currently I do it by

new Long(l1).compareTo(l2) // autoboxing

There are only a few cases when you need an explicit method to compare
numbers. Typically simple if() statements are OK:

if(l1 > l2) {

} else if(l1 < l2) {

} else {

}

Which is anyhow simpler than:

int c = MyUtility.compareTo(l1, l2);
if(c > 0) {

} else if(c < 0) {

} else {

}

or

int c = new Long(l1).compareTo(l2);
if(c > 0) {

} else if(c < 0) {

} else {

}


You only need to explicitly call compareTo() methods in Java if you need
to determine some order between instances of a class, but if your code
has no knowledge about that order. This is typically not the case if you
know you are dealing with longs.

It is e.g. the case for universal/reusable sort routines which are
supposed to be capable of sorting "everything". Such routines are
typically written to handle only objects, not to handle primitive types
- to avoid having to duplicate code. So using such routines typically
has to result in boxing/unboxing when you want to use them with
primitives. But that boxing happens because of the particular sorting
routine's implementation. Methods like Long.compareTo() simply exist to
support such routines. They are not intended for general usage.
However, there should be a static method in Long.compareTo(long l1, long l2)
in order to avoid the generation of two unnecessary Long objects? The same
problem occurrs for other primitive types. I would always have to write a
methods like:
public static int compareTo(long l1, long l2) {
return l1<l2? -1 : l1==l2? 0 : 1;
}


public static long compareTo(long l1, long l2) {
return l1 - l2;
}

Shouldn't the current design

Design of what? What is it what you actually want to change? class Long?

/Thomas
 
C

Chris Uppal

Marc said:
However, there should be a static method in Long.compareTo(long l1, long
l2) [...]
Shouldn't the current design be refactored in this way or do I miss
something?

I think it's just that there isn't a lot of need for such a method, and it's
easy enough to create your own. Maybe it'll be added someday.

-- chris
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Weidenfeller schreef:
public static long compareTo(long l1, long l2) {
return l1 - l2;
}

You stepped in the same trap as I did: this isn’t overflow-safe.

H.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEfvYNe+7xMGD3itQRAsEVAJ4oGk+smAN9wDvY/tFgGUJ1Wr5Q9ACfVvZ7
WH+wU2vcnEsGI/fGtIY+tDQ=
=e7JY
-----END PGP SIGNATURE-----
 
M

Marc Dzaebel

Chris Uppal said:
Marc said:
However, there should be a static method in Long.compareTo(long l1, long
l2) [...]
Shouldn't the current design be refactored in this way or do I miss
something?
I think it's just that there isn't a lot of need for such a method, and
it's
easy enough to create your own. Maybe it'll be added someday.

Yes, maybe the tradeoff between language complexity and usefullness might be
the reason.

Thanks all for your comments!
 
W

Wibble

Hendrik said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Dzaebel schreef:

Do you rely on the result of compareTo being -1 or +1? You shouldn’t!
If not, then why even write a function and not just use l1-l2?

Same goes for ints. For bytes, shorts and chars the situation is
different, because of auto-conversion. But then again, compareTo gives
you an int too, so this is exactly what you want.

Only for floating point numbers would you have to watch out, because
float1-float2 is not always 0, even when they have the ‘same’ value (or
the inverse).

H.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEfueUe+7xMGD3itQRAtxLAJ43BzqSNYRI0af8ay6hczcX88Z7mwCfW2li
bF8Yi1sieflft7HmojKe6OY=
=zXWI
-----END PGP SIGNATURE-----
Autoboxing will work great in 1.5, but what about 1.4?

Arrays.sort requires objects passed to the comparator
and if you're sorting in a non-conventional order,
like by bits-set-count, then you're mostly out of luck.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top