Comment On How Not to compareTo()

frist!

frest!

fw:

frist!

tawt

Get lost babies

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

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

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.

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!

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

Eleventh

one-thousand-seven-hundred-twenty-first

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.

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

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

i'm always nr 1!

16th/17th/whateverth!

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

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

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.

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?

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.

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;

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.

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.

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.

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)

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

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.

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!

fw:

frist!

Being a site about programming, shouldn't the first poster be 0th?

Well, language dependent I guess.

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.

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

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.

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.

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.

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?

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

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.

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

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!

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.

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.

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

Comment.01
Comment.02

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!

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.

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

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

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!

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)

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.

[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?