• fw (unregistered)

    frist!

  • sd (unregistered)

    frest!

  • stEvil (unregistered) in reply to fw
    fw:
    frist!
    tawt
  • me (unregistered)

    Get lost babies

  • !compareTo() (unregistered)

    Giggeligiggeligiigeligi... One must love the contractor and the experience they bring...

  • jan (unregistered)

    Duh! return Float.compare(f1, f2);

  • Alex (yes there are more then one) (unregistered)

    Surely you know that one can never fix a project by adding more staff in the late stages of a project to make up the time. However, such bad code is unforgivable.

  • stEvil (unregistered) in reply to Alex (yes there are more then one)
    Alex (yes there are more then one):
    Surely you know that one can never fix a project by adding more staff in the late stages of a project to make up the time...

    no, but I admire their scapegoat-diversification scheme!

  • B. Grenger (unregistered)

    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

  • Rufus Dufus (unregistered)

    Eleventh

  • CanCountNot (unregistered) in reply to Rufus Dufus

    one-thousand-seven-hundred-twenty-first

  • Moe (unregistered)

    Although I guess the contractor didn't know that, his method is better than it looks. Comparing floats is inherently difficult, as there is always a finite amount of precision in seemingly infinite-precision floats, let alone inherent precision of input data (measurements, monetary values etc.). Calculation results of floating point data should always be suitably rounded before comparison. His second attempt is a valid compareTo implementation assuming two decimals precision throughout the application.

  • Georgem (unregistered)

    20 years experience in what? Hoodwinking clients, by the sound of it

    CAPTCHA: conventio. I'll get back to you when I've retro-fitted a meaning to it, but it sounds sexy

  • eby (unregistered) in reply to fw

    public int amIfrist(Object 1st) { (int)(100.0 * (frist() - first())); return 1; }

    i'm always nr 1!

  • Alargule (unregistered)

    16th/17th/whateverth!

    OMG...Had a good laugh, though. Maybe this guy should consider a career switch to standup comedian. 100% Failure Guaranteed!

  • (cs) in reply to Moe
    Moe:
    Although I guess the contractor didn't know that, his method is better than it looks. Comparing floats is inherently difficult, as there is always a finite amount of precision in seemingly infinite-precision floats, let alone inherent precision of input data (measurements, monetary values etc.). Calculation results of floating point data should always be suitably rounded before comparison. His second attempt is a valid compareTo implementation assuming two decimals precision throughout the application.
    Does java truncate or round on a float to int cast? C truncates, meaning a compare function like that would consider 3.99999999 and 4.00 as different numbers, despite your "two decimal places of precision".
  • Zapp Brannigan (unregistered) in reply to Alargule

    The consultant was probably experienced in another language and was new to java. When I see others struggle with similar types of errors I try to nicely teach them what is going wrong. It's usually easy to spot because the code just doesn't work. Most people appreciate the help and WE ALL started as noobs! Most people will eventually get it. However if I detect any attitude or arrogance, I am merciless.

  • Alexander (unregistered) in reply to Moe
    Moe:
    Although I guess the contractor didn't know that, his method is better than it looks. Comparing floats is inherently difficult, as there is always a finite amount of precision in seemingly infinite-precision floats, let alone inherent precision of input data (measurements, monetary values etc.). Calculation results of floating point data should always be suitably rounded before comparison. His second attempt is a valid compareTo implementation assuming two decimals precision throughout the application.

    Agreed. Directly comparing floats for equivalence is not a good idea. What is the Requirement Specification says for this method?

  • apz (unregistered)

    Actually, you should NEVER implement Comparables that way.

    Look what would happen if the values were more than Integer.MAX_VALUE away.

    Read Effective Java, it explains this and other common pitfalls very well.

  • Gumpy Guss (unregistered)

    There are so many things wrong here. First of all, you can only make a project later by adding inexperienced help. And they're all inexperienced in your app.

    Next as many others have mentioned, you should think about what you mean by "equal". Floating-point numbers can have up to 128 bits of significance and can go down to 10^-308 or so. Do you really want to consider 1.0000000000001E-302 different from 1.0000000002E-302?

    If there is an exact requirement like "within one cent" (although you should not be using fp numbers for money, really), he should implement that. If the requirement is "within one part per million", then it gets tricky, you have to use a relative compare, with much care:

    Diff = abs( n1 - n2 ) MaxErr = Max( abs(n1), abs(n2) ) * 1.0E-6; AboutEqual = Diff <= MaxErr;

  • Bobble (unregistered) in reply to Zapp Brannigan
    Zapp Brannigan:
    The consultant was probably experienced in another language and was new to java. When I see others struggle with similar types of errors I try to nicely teach them what is going wrong. It's usually easy to spot because the code just doesn't work. Most people appreciate the help and WE ALL started as noobs! Most people will eventually get it. However if I detect any attitude or arrogance, I am merciless.

    If I wanted someone to mentor, I'd have hired a new employee or an intern. If I need a contractor, they had better be ready to go the first day and have the advertised skill set.

  • Flipper (unregistered)
    And yes, I'm still coming in the office, weekend after weekend.
    I hope the HR department doesn't hear about this. Or your girlfriend / wife, unless of course that's who you're coming with.
  • revenant (unregistered)

    TRWTF is that they needed a contractor to write this code. It'd take more time to go to someone and to explain the task then to do it.

  • (cs) in reply to apz
    apz:
    Actually, you should NEVER implement Comparables that way.

    Look what would happen if the values were more than Integer.MAX_VALUE away.

    Read Effective Java, it explains this and other common pitfalls very well.

    Agreed, but sometimes you know the range of the variable (it would be nice if it were documented)

  • (cs)

    Did this "veteran" actually claim to have twenty years of Java experience?

  • Married Guy (unregistered) in reply to Flipper
    Flipper:
    And yes, I'm still coming in the office, weekend after weekend.
    I hope the HR department doesn't hear about this. Or your girlfriend / wife, unless of course that's who you're coming with.
    A girlfriend might be up for something like that. A wife, not likely.
  • (cs) in reply to Gumpy Guss
    Gumpy Guss:
    There are so many things wrong here. First of all, you can only make a project later by adding inexperienced help. And they're all inexperienced in your app.

    Next as many others have mentioned, you should think about what you mean by "equal". Floating-point numbers can have up to 128 bits of significance and can go down to 10^-308 or so. Do you really want to consider 1.0000000000001E-302 different from 1.0000000002E-302?

    If there is an exact requirement like "within one cent" (although you should not be using fp numbers for money, really), he should implement that. If the requirement is "within one part per million", then it gets tricky, you have to use a relative compare, with much care:

    Diff = abs( n1 - n2 ) MaxErr = Max( abs(n1), abs(n2) ) * 1.0E-6; AboutEqual = Diff <= MaxErr;

    Been there, coded that, hated it; randomize is your friend!

  • monkeyPushButton (unregistered) in reply to fw
    fw:
    frist!
    Being a site about programming, shouldn't the first poster be 0th?

    Well, language dependent I guess.

  • (cs) in reply to Someone You Know
    Someone You Know:
    Did this "veteran" actually claim to have twenty years of Java experience?
    I have about 35 years of experience with java, and 20 with java beans, but only about 12 with Java.
  • Eh (unregistered) in reply to B. Grenger
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

  • SCB (unregistered) in reply to Eh
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.
  • Yanman.be (unregistered) in reply to SCB
    SCB:
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.

    He needs a faster computer, hard drive and some more RAM.

  • (cs) in reply to Yanman.be
    Yanman.be:
    SCB:
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.

    He needs a faster computer, hard drive and some more RAM.

    He needs more internets.

  • (cs) in reply to Zapp Brannigan
    Zapp Brannigan:
    The consultant was probably experienced in another language and was new to java.

    20 years of experience, and has never used a language with a floating-point datatype?

  • (cs) in reply to SCB
    SCB:
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.

    Then he need to upgrade his DSL line

  • (cs)

    That compareTo() is as much a WTF as WHERE 1=1 is.

    Hint: It's not.

    Hiring a contractor 'to catch up' is a nice one though. Never heard it before.

  • SCB (unregistered) in reply to ubersoldat
    ubersoldat:
    SCB:
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.

    Then he need to upgrade his DSL line

    Yes, you're right. Eclipse docs say you need around 140 megabytes disk space. Assuming that this is zipped down to 70 megabytes for downloading, on an 8 megabit broadband connection this should still take less than 90 seconds. I don't know how long the installation takes though...

  • Paul W. Homer (unregistered)

    Surely there must be something more unique about an "Activity" than just a VarianceAmount?

    There seems to be a whole series of WTFs working their way through this story. Adding a contractor will slow things down for a while. Poor documentation results in wasted effort. A possibly ambiguous object makes for badly hacked behaviors, and poor management leads to even more wasted effort. Eek!

  • (cs) in reply to Coincoin
    Coincoin:
    That compareTo() is as much a WTF as

    Hiring a contractor 'to catch up' is a nice one though. Never heard it before.

    Theres a reason for that. Its a bad idea. You can't blame problems on the contractor because you're responsible for him.

  • Bobblehead Troll (unregistered) in reply to Rootbeer
    Rootbeer:
    Zapp Brannigan:
    The consultant was probably experienced in another language and was new to java.

    20 years of experience, and has never used a language with a floating-point datatype?

    Perhaps it was just 20 years of inexperience.

  • Georgem (unregistered) in reply to Rootbeer
    Rootbeer:
    Zapp Brannigan:
    The consultant was probably experienced in another language and was new to java.

    20 years of experience, and has never used a language with a floating-point datatype?

    To be fair, at no point was the phrase "20 years technical experience" used

  • Paula (unregistered)

    Comment.01 Comment.02

  • Sumatra (Not Java) (unregistered) in reply to SCB
    SCB:
    ubersoldat:
    SCB:
    Eh:
    B. Grenger:
    I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.

    I think it's time you got a faster computer ...

    That 15 minutes probably includes the "download and install" time.

    Then he need to upgrade his DSL line

    Yes, you're right. Eclipse docs say you need around 140 megabytes disk space. Assuming that this is zipped down to 70 megabytes for downloading, on an 8 megabit broadband connection this should still take less than 90 seconds. I don't know how long the installation takes though...

    Well, we all know that Java is slow!

    [image]
  • Henning Makholm (unregistered) in reply to Gumpy Guss
    Gumpy Guss:
    Next as many others have mentioned, you should think about what you mean by "equal". Floating-point numbers can have up to 128 bits of significance and can go down to 10^-308 or so. Do you really want to consider 1.0000000000001E-302 different from 1.0000000002E-302?
    If you're implementing java.lang.Comparable, then: Yes, definitely so. Its contract is that compareTo implements a total preorder. There MUST NOT be any a, b and c where a.compareTo(b)==0 and b.compareTo(c)==0 yet a.compareTo(c)>0. If this is violated -- as your proposal would -- lots of standard sorting or container algorithms can get very confused.

    In these contexts one is typically not terribly concerned with whether two close values compare as equal or different, so long as what they do is consistent with all other comparisons.

  • (cs)

    Some people have 20 years of experience. Some have 1 year of experience 20 times.

  • (cs) in reply to Alex (yes there are more then one)

    Huh. Why can't I delete this post? Is this a Daily WTF WTF?

  • (cs) in reply to Alex (yes there are more then one)
    Alex (yes there are more then one):
    Surely you know that one can never fix a project by adding more staff in the late stages of a project to make up the time.
    Yeah. Everyone knows only a mystical mammoth could pull off such a feat!
  • twatter (unregistered)

    TRWTF is that Java was born in 1991 and was, in that fase, not yet that usable.

    So I'm not sure what his 20 years of experience were, but them being in Java is scientifically impossible.

    Captcha: facilisis (not a clue what it is, but it sounds gross)

  • Its an INT compare (unregistered)

    So why are you worried about that code inside? It is an INT compare, so since there aren't decimals in integers, 3.1 and 3.2 ARE equal.... You need to consider using the decimal compare if you want to know whether 3.1= 3.2.

  • Georgem (unregistered) in reply to Sumatra (Not Java)

    [quote user="Sumatra (Not Java)"][quote user="SCB"][quote user="ubersoldat"][quote user="SCB"][quote user="Eh"][quote user="B. Grenger"]I could have downloaded and installed Eclipse and had Eclipse do the compareTo() method for me in about 15 mintues.[/quote]

    I think it's time you got a faster computer ... [/quote] That 15 minutes probably includes the "download and install" time. [/quote]

    Then he need to upgrade his DSL line[/quote] Yes, you're right. Eclipse docs say you need around 140 megabytes disk space. Assuming that this is zipped down to 70 megabytes for downloading, on an 8 megabit broadband connection this should still take less than 90 seconds. I don't know how long the installation takes though... [/quote]

    Who "installs" Eclipse?

Leave a comment on “How Not to compareTo()”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article