Comment On The Millisecond Converter

Let's get these out of the way:

Brillant!
He shoud have used if(IsTrue(milliDiff==0))!
The real WTF is (insert lame callback here).

I don't get how making it positive then negative again is any easier than just doing it with the negative value.

I bet that took him -1029 millseconds to write

I like this:

Alex Papadimoulis:

  if (milliDiff < 0)
  {
    negative = true;
    milliDiff = -milliDiff; // Make positive (is easier)

  }

As if any part of his algorithm would be "hard" if there were the possibility of a negative number.

Is there a prize for when the number of WTF's exceeds the number of lines of code?



Nice to see the function accounts for the posibility of negative
milliseconds and minutes. Must be used in conjunction with the flux
capacitor.



And I don't know *how many* times I've forgotten to watch out for the
exceptional value 0. Maybe this comment will help me remember.

I wish I could code that well, maybe I would make more money!!!!

Alex Papadimoulis:

  if (milliDiff == 0) // Watch out for exceptional value 0

    minutesDiff = 0;

  else

    minutesDiff = (int) (milliDiff / 1000) / 60;

 

  I suppose he is a little confused about what "divison by zero" really means. The last time I checked dividing zero by any number always returns zero, so the extra check here is not necessary.

He's not avoiding that.  He's avoiding a bug that showed up in
.NET (and hasn't been fixed!) whereby if you divide zero by a number,
you keep getting zero, instead of a DivisionWithZero
exception.   I attempt to avoid such problems in my code by
writing only Javascript.

Anonymous:

I don't get how making it positive then
negative again is any easier than just doing it with the negative
value.

I like how the comments on this site are usually bigger WTFs than the posts themselves.

Actually, if you divide by zero a DivisionByZero exception will be
thrown in C#, something similar in Java and IIRC C++ will throw an
exception aswell

I'm still trying to figure out when this would be used. My guess is that he's subtracting two different time values (anyone want to wager how many lines he took to do that? how many type conversions?) then converting that difference to minutes. But any system that measures and stores enough milliseconds to make subtractable minute values is borked up enough as it is. At that point you might as well meaure fractional minutes (5.25 minutes = 5 minutes, 15 seconds).

Anonymous:

Actually, if you divide by zero a DivisionByZero exception will be
thrown in C#, something similar in Java and IIRC C++ will throw an
exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

Anonymous:

Anonymous:

I don't get how making it positive then
negative again is any easier than just doing it with the negative
value.

I like how the comments on this site are usually bigger WTFs than the posts themselves.

I don't get it Anonymous.  What's wrong with what Anonymous said?  Anonymous is right.

limelight:

Alex Papadimoulis:

  if (milliDiff == 0) // Watch out for exceptional value 0

    minutesDiff = 0;

  else

    minutesDiff = (int) (milliDiff / 1000) / 60;

 

  I suppose he is a little confused about what "divison by
zero" really means. The last time I checked dividing zero by any
number always returns zero, so the extra check here is not
necessary.

Not always true that 0/x = 0:  x could be 0 as well.  And if
these were float/double values, x could also be NaN, +inf, -inf, or
-0.0.



Of course, this doesn't change the fact that there is nothing exceptional about 0 in the WTF code.

Anonymous:

Actually, if you divide by zero a DivisionByZero exception will be thrown in C#, something similar in Java and IIRC C++ will throw an exception aswell

Sarcasm escapes some people...

0 / n = 0 // This is NOT a bug in .NET, this is valid math!

n / 0 = DivideByZero Exception

In this case his math should be; milliseconds / 60000 = minutes.  If milliseconds is 0 then minutes will be 0 (try it if you don't believe me)

kipthegreat:

Not always true that 0/x = 0:  x could be 0 as well.  And if these were float/double values, x could also be NaN, +inf, -inf, or -0.0.

Of course, this doesn't change the fact that there is nothing exceptional about 0 in the WTF code.

 

This is true, but I meant it in the more general sense that dividing zero is the same as dividing any other number. You still have to look out for division by zero, etc.

Ytram:

Anonymous:

Actually, if you divide by zero a DivisionByZero exception will be thrown in C#, something similar in Java and IIRC C++ will throw an exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

What's sarcasm?

tedbilly:

0 / n = 0 // This is NOT a bug in .NET, this is valid math!

n / 0 = DivideByZero Exception

In this case his math should be; milliseconds / 60000 =
minutes.  If milliseconds is 0 then minutes will be 0 (try it if
you don't believe me)

I don't believe you!  I'm joining up with Dave Markle and sticking with Javascript from now on!  Screw .NET!



Oh by the way, everyone knows the example isn't valid C# anyways cuz the coder mispelled "bool"!  LOLOLOL!

Anonymous:

Ytram:

Anonymous:

Actually, if you divide by zero a DivisionByZero exception will be thrown in C#, something similar in Java and IIRC C++ will throw an exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

What's sarcasm?

And where do I find a detector for it?

Comic Book Guy: A sarcasm detector, that's a real useful invention.



KABOOM!

"Nice to see the function accounts for the posibility of negative milliseconds and minutes. Must be used in conjunction with the flux capacitor."

From the name of the passed parameter, it looks like he's expecting a difference of two timestamps, which could well be negative.

Possibly he converts to positive to get a consistent round-towards-zero regardless of the sign of the input, rather than floor rounding, as well? Maybe this isn't quite as WTF as it looks at first glance.

Why worry about division by zero in this example anyway?

Anonymous:

Why worry about division by zero in this example anyway?

That's exactly the point. This guy was writing the code and thought, "oh man, I better be careful not to divide by zero" and so put in this crazy check. I guess he didn't understand the difference of divison by zero as opposed to divison of zero.

Anonymous:

I like how the comments on this site are usually bigger WTFs than the posts themselves.

Me too. There seems to be a prevalance of dumb people with no sense of
humour who read thedailywtf.com. My request to these dumb people, is
please keep posting, I enjoy laughing at you.



And the best thing is that the dumb people i'm talking about don't even know i'm talking about them.

Anonymous:

I don't get how making it positive then negative again is any easier than just doing it with the negative value.

Possibly because he wants to round towards zero rather than to the floor. That is -2.3 minutes should round to -2 rather than -3.

Well, nothing wrong with handling those exceptionals of negative differences and 0. But what if the difference in milliseconds is evenly divible by 617? Isn't that exceptional too? He needs to divide the milliseconds by 2 then multiply the resulting minutes by 2. Or is it divide and multiply by 4? Help me out here.

And there's so many other exceptionals that could happen. What if the number of milliseconds happens to equal the number hours since I was born? Wouldn't that be exceptional? I don't see an if block for it.

Oh, and rounding those milliseconds to the nearest (int) minute? That's just for dweebs who don't get Web 2.0.

--Rank

 

Actually I could see somebody writing something like this if they were for some reason worried about the rounding behavior of division with negative integers.  e.g. if he were concerned that (-11)/3 might be different than -(11/3) and that difference was important for some reason.  It's a stretch I'll admit.

The check for zero looks like an extremely common case of premature optimization.  He knows what the answer is so he avoids the overhead of doing the divide.

OneFactor:

Anonymous:

I don't get how
making it positive then negative again is any easier than just doing it
with the negative value.

Possibly because he wants to round towards zero rather than to the
floor. That is -2.3 minutes should round to -2 rather than -3.

As far as I know, integer division does not necessarily use a floor
function to perform the division.  It just simply takes the
integer portion of the number without regard to the numbers after the
decimal point.



-2.3 as a result of integer division becomes -2

2.3 as a result of integer division becomes 2



I tested it in .NET and this is the case for that implementation of integer division at least.

Alex Papadimoulis:

private int convertToMinutes(long milliDiff)

{

  boolean negative = false;

  int minutesDiff = -1;



  if (milliDiff < 0)

  {

    negative = true;

    milliDiff = -milliDiff; // Make positive (is easier)

  }



  if (milliDiff == 0) // Watch out for exceptional value 0

    minutesDiff = 0;

  else

    minutesDiff = (int) (milliDiff / 1000) / 60;



  if (negative) minutesDiff = -minutesDiff; // Make it negative again



  return minutesDiff;

}

Yeah, okay - but what's the WTF here? I mean, just look: descriptive variable names (and no Hungarian notation to boot!), nicely indented, just enough comments - I wish my colleagues would write code like this!

(Later) Ah, NOW I see it - he should have used public instead of private, to encourage re-use of this great piece of code!

   Oh, and for those who just don't get it:
   </sarcasm>

Best, Hugo

Anonymous:

Ytram:

Anonymous:

Actually, if you divide by zero a DivisionByZero
exception will be thrown in C#, something similar in Java and IIRC C++
will throw an exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

What's sarcasm?

I think it's like rhetorics. Do you know what that is?

Anonymous:

Anonymous:

I like how the comments on this site are usually bigger WTFs than the posts themselves.

Me too. There seems to be a prevalance of dumb people with no sense of humour who read thedailywtf.com. My request to these dumb people, is please keep posting, I enjoy laughing at you.

And the best thing is that the dumb people i'm talking about don't even know i'm talking about them.

I used to think otherwise until I read your comments.

 

OneFactor:

Anonymous:

I don't get how making it positive then negative again is any easier than just doing it with the negative value.

Possibly because he wants to round towards zero rather than to the floor. That is -2.3 minutes should round to -2 rather than -3.

 

There's no rounding involved here. He is simply taking the result of a divison operation and casting it to an integer, which drops off the decimal portion. Casting -2.3 to an integer produces -2 just as casting 2.3 to an integer produces +2. Try evaluating the following (C# code):

Console.WriteLine(((int) -2.3).ToString());

OneFactor:

Anonymous:

I don't get how making it positive then negative again is any easier than just doing it with the negative value.

Possibly because he wants to round towards zero rather than to the floor. That is -2.3 minutes should round to -2 rather than -3.

Except integer division doesn't round, it truncates, and will therefore always go towards zero anyways.

Anonymous:

From the name of the passed parameter, it looks
like he's expecting a difference of two timestamps, which could well be
negative.

Aye, I didn't consider that at first. However, would there be any
significance to a negative return value from the function? The
difference is still a positive number of milliseconds, regardless of
which one went first. I suppose we'd need to see the rest of the
implementation in the app for that (not that I'd especially *like* to,
mind you).

Anonymous:

Possibly he converts to positive to get a
consistent round-towards-zero regardless of the sign of the input,
rather than floor rounding, as well?

But doesn't integer division just truncate the decimal anyway? Plus,
based on the rest of the function, I'd be willing to bet that wasn't
the coder's thought process....

Assuming there are more than ten additional bits in a long data type compared to an int data type, there's also an overflow here.

DeusEx:

But doesn't integer division just truncate the decimal anyway?

Ok, I guess my responding before reading the rest of the comments is a WTF in itself.

I know how we always try to explain why the code was written in such a way...





... I just can't come up with anything for this grand masterpiece!

Wow.  Wow.  This is definitely brillant.



The only mitigating factor is that the code works for all inputs.

Djinn:

Anonymous:

Ytram:

Anonymous:

Actually, if you divide by zero a DivisionByZero
exception will be thrown in C#, something similar in Java and IIRC C++
will throw an exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

What's sarcasm?

I think it's like rhetorics. Do you know what that is?

Is that like generics in Java 5.0?

Anonymous:

Assuming there are more than ten additional bits in a long data type compared to an int data type, there's also an overflow here.

You're right in that there is a possible overflow; I didn't even notice that. Although, to hit the overflow, the difference passed in would have to be equal to just at 4082 years, so it's doubtful that it would happen in practical usage. Still, I hate to see code where a bug is possible even if it's not practical.

Djinn:

Anonymous:

Ytram:

Anonymous:

Actually, if you divide by zero a DivisionByZero
exception will be thrown in C#, something similar in Java and IIRC C++
will throw an exception aswell

You might want to re-read his comment.  Try turning your sarcasm detector on also.

What's sarcasm?

I think it's like rhetorics. Do you know what that is?

Do I know what rhetorical means? (8(1)

Anonymous:

Assuming there are more than ten additional
bits in a long data type compared to an int data type, there's also an
overflow here.

On x86 (I doubt the coder was using something else), longs and ints are both 4 bytes long.

limelight:

Anonymous:

Assuming there are more than ten additional bits in a long data type compared to an int data type, there's also an overflow here.

You're right in that there is a possible overflow; I didn't even notice that. Although, to hit the overflow, the difference passed in would have to be equal to just at 4082 years, so it's doubtful that it would happen in practical usage. Still, I hate to see code where a bug is possible even if it's not practical.

Worse than that. 2^15 minutes is only about 23 days, so overflow hits at about 2 billion (US) milliseconds.

Wasn't there a bug in Windows like that that forced you to reboot servers after they were left on for about a month?

--RA

Ytram:

OneFactor:

Anonymous:

I don't get how making it positive then negative again is any easier than just doing it with the negative value.

Possibly because he wants to round towards zero rather than to the floor. That is -2.3 minutes should round to -2 rather than -3.

As far as I know, integer division does not necessarily use a floor function to perform the division.  It just simply takes the integer portion of the number without regard to the numbers after the decimal point.

-2.3 as a result of integer division becomes -2
2.3 as a result of integer division becomes 2

I tested it in .NET and this is the case for that implementation of integer division at least.

And for those of you just tuning in, today's WTF is brought to you by the letters J, A, V, and A.

Alex Papadimoulis:

 //Watch out for exceptional value 0
  

 

BWAAAAHAHAHAHHAHAHAHAAHHAHA! What a tosser!

Rank Amateur:

limelight:

Anonymous:

Assuming there are more than ten additional bits in a long data type compared to an int data type, there's also an overflow here.

You're right in that there is a possible overflow; I didn't even notice that. Although, to hit the overflow, the difference passed in would have to be equal to just at 4082 years, so it's doubtful that it would happen in practical usage. Still, I hate to see code where a bug is possible even if it's not practical.

Worse than that. 2^15 minutes is only about 23 days, so overflow hits at about 2 billion (US) milliseconds.

Wasn't there a bug in Windows like that that forced you to reboot servers after they were left on for about a month?

--RA

Oh, wait, integers take 32 bits these days, don't they? Gah! I'm showing my age!

--RA

 

Rank Amateur:

limelight:

Anonymous:

Assuming there are more than ten additional bits in a long data type compared to an int data type, there's also an overflow here.

You're right in that there is a possible overflow; I didn't even notice that. Although, to hit the overflow, the difference passed in would have to be equal to just at 4082 years, so it's doubtful that it would happen in practical usage. Still, I hate to see code where a bug is possible even if it's not practical.

Worse than that. 2^15 minutes is only about 23 days, so overflow hits at about 2 billion (US) milliseconds.

Wasn't there a bug in Windows like that that forced you to reboot servers after they were left on for about a month?

--RA

With a 32-bit integer, the max value it can handle would be 2^31 - 1. This comes out to

2,147,483,647 minutes or 
35,791,394.12 hours or
1,491,308.088 days or
4082.979 years (taking a year as being 365.25 days, which is not totally accurate, but close enough for this example)

limelight:

Alex Papadimoulis:

  if (milliDiff == 0) // Watch out for exceptional value 0

    minutesDiff = 0;

  else

    minutesDiff = (int) (milliDiff / 1000) / 60;

 

  I suppose he is a little confused about what "divison by zero" really means. The last time I checked dividing zero by any number always returns zero, so the extra check here is not necessary.

To be fair, some of those zeroes are pretty exceptional.... except for the ones that aren't.