compareTo() for primitive types?

Discussion in 'Java' started by Marc Dzaebel, Jun 1, 2006.

  1. Marc Dzaebel

    Marc Dzaebel Guest

    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
     
    Marc Dzaebel, Jun 1, 2006
    #1
    1. Advertising

  2. -----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


    You could always use a LongComparator implements Comparator<Long, Long>
    to avoid the new Long()

    > 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-----
     
    Hendrik Maryns, Jun 1, 2006
    #2
    1. Advertising

  3. Marc Dzaebel

    Chris Uppal Guest

    Hendrik Maryns wrote:

    > If not, then why even write a function and not just use l1-l2?


    That's not safe if the arithmetic can wrap around.

    -- chris
     
    Chris Uppal, Jun 1, 2006
    #3
  4. Hendrik Maryns wrote:

    > 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
     
    Patricia Shanahan, Jun 1, 2006
    #4
  5. Marc Dzaebel wrote:
    > 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
    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, Jun 1, 2006
    #5
  6. Marc Dzaebel

    Chris Uppal Guest

    Marc Dzaebel wrote:

    > 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
     
    Chris Uppal, Jun 1, 2006
    #6
  7. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Thomas Weidenfeller schreef:
    > Marc Dzaebel wrote:
    >> 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;
    > }


    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-----
     
    Hendrik Maryns, Jun 1, 2006
    #7
  8. Marc Dzaebel

    Marc Dzaebel Guest

    "Chris Uppal" <-THIS.org> schrieb im
    Newsbeitrag news:447ef1b5$0$658$...
    > Marc Dzaebel wrote:
    >> 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!
     
    Marc Dzaebel, Jun 1, 2006
    #8
  9. Marc Dzaebel

    Wibble Guest

    Hendrik Maryns wrote:
    > -----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

    >
    > You could always use a LongComparator implements Comparator<Long, Long>
    > to avoid the new Long()
    >
    >> 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-----

    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.
     
    Wibble, Jun 2, 2006
    #9
    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:
    413
    =?ISO-8859-1?Q?S=F8ren_Bak?=
    Aug 27, 2003
  2. munki
    Replies:
    5
    Views:
    3,100
    Michael Borgwardt
    Oct 8, 2003
  3. Replies:
    7
    Views:
    614
    Victor Bazarov
    May 9, 2005
  4. Andreas Leitgeb

    compareTo() for primitive types?

    Andreas Leitgeb, Nov 13, 2006, in forum: Java
    Replies:
    9
    Views:
    647
    Andreas Leitgeb
    Nov 15, 2006
  5. Daniel Pitts
    Replies:
    7
    Views:
    490
Loading...

Share This Page