• boohiss (unregistered)

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

  • Anonymous Coward (unregistered) in reply to boohiss

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

  • Martin Carolan (unregistered)

    I bet that took him -1029 millseconds to write

  • (cs)

    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.
  • (cs)

    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.

  • mrsticks1982 (unregistered)

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

  • (cs)
    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.

  • Dave Markle (unregistered) in reply to limelight

    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 (unregistered) in reply to Anonymous Coward
    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.
  • Martin Carolan (unregistered) in reply to limelight

    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

  • (cs)

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

  • (cs) in reply to Martin Carolan
    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.
  • (cs) in reply to Anonymous
    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.
  • (cs) in reply to limelight
    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.
  • Somnus (unregistered) in reply to Martin Carolan

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

  • (cs) in reply to Dave Markle

    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)

  • (cs) in reply to kipthegreat

    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.

  • Anon (unregistered) in reply to Ytram

    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?

  • (cs) in reply to tedbilly
    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!
  • Anon (unregistered) in reply to Anon
    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?

  • (cs) in reply to Anon

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

    KABOOM!

  • Lethargically Anonymous (unregistered) in reply to DeusEx

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

  • Dave (unregistered) in reply to Anon

    Why worry about division by zero in this example anyway?

  • (cs) in reply to Dave

    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.

  • Jon (unregistered) in reply to 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.
  • (cs) in reply to Anonymous Coward

    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.

  • (cs)

    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

     

  • Mike (unregistered)

    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.

  • (cs) in reply to OneFactor
    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.
  • (cs)
    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

  • (cs) in reply to Anon
    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 (unregistered) in reply to Jon

    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.

     

  • (cs) in reply to OneFactor
    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(((<FONT style="BACKGROUND-COLOR: #ffffff" color=#0000ff>int</FONT>) -2.3).ToString());

  • Erin (unregistered) in reply to OneFactor
    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.

  • (cs) in reply to Lethargically Anonymous
    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....

  • Chris in Edmonton (unregistered) in reply to boohiss

    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.

  • (cs) in reply to DeusEx
    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.
  • toxik (unregistered)

    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!

  • Anonymous coward (unregistered)

    Wow.  Wow.  This is definitely brillant.

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

  • Anonymous coward (unregistered) in reply to Djinn
    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?
  • (cs) in reply to Chris in Edmonton

    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.

  • Homer (unregistered) in reply to Djinn
    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)
  • (cs) in reply to Chris in Edmonton
    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.

  • (cs) in reply to limelight
    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

  • (cs) in reply to Ytram
    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.

  • (cs)
    Alex Papadimoulis:

     //Watch out for exceptional value 0
      

     

    BWAAAAHAHAHAHHAHAHAHAAHHAHA! What a tosser!

  • (cs) in reply to Rank Amateur
    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

  • (cs) in reply to Ytram

     

  • (cs) in reply to Rank Amateur
    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)

  • (cs) in reply to limelight
    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.

Leave a comment on “The Millisecond Converter”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article