• (cs) in reply to Beau "Porpus" Wilkinson
    Beau "Porpus" Wilkinson:
    There is a potential flaw in your argument. You basically say that "Visual Studio does X by default therefore it's not a WTF." That assumes something that's not necessarily true. Some of us think that XML comments are a WTF. For instance, they lead to boilerplate type crap like:
        /// <summary>
        ///  shifts all windows
        /// </summary>
        /// <param name="processName">name of process</param>
    

    Truly, XML at its finest.

    Javadocs use something similar, just not XML. You can put useless comments there. But if someone does take the time to add meaningful comments, it's nice to have a tool to pull those out for you.

    If someone is going to fill out the comment like you show above, they wouldn't have added a better comment without the markup either.

  • wtf (unregistered) in reply to Josh
    Josh:
    I'm not smart enough to appreciate the horror of the code, but I like the faux markup (FauXML?) in the comments. To people actually do that or is it further WTFery?
    This comment is itself quite horrifying :-/
  • Jhon (unregistered) in reply to Beau "Porpus" Wilkinson
    Beau "Porpus" Wilkinson:
    John:
    Visual Studio uses this format by default. There is not wtf in here. Doxygen (documentation program) can also read this kind of a markup.

    There is a potential flaw in your argument. You basically say that "Visual Studio does X by default therefore it's not a WTF." That assumes something that's not necessarily true. Some of us think that XML comments are a WTF. For instance, they lead to boilerplate type crap like:

        /// <summary>
        ///  shifts all windows
        /// </summary>
        /// <param name="processName">name of process</param>
    

    Truly, XML at its finest.

    And you might shot yourself in a leg if given a gun. I personally think XML comments are effective and easy to read. It also enables easy access to 3rd party programs to extract comments out of code (Doxygen)

  • Beau "Porpus" Wilkinson (unregistered) in reply to wtf
    wtf:
    Josh:
    I'm not smart enough to appreciate the horror of the code, but I like the faux markup (FauXML?) in the comments. To people actually do that or is it further WTFery?
    This comment is itself quite horrifying :-/

    Not necessarily... there are developers out there who use languages other than C#. I like C# myself, but I must say it is one of the most over-evangelized languages out there.

  • (cs)

    The comments are not a WTF because .NET only makes sense if you use Visual Studio.

  • jbosss (unregistered)

    Hillaaarious! This is maybe better than the True/False/FileNotFound WTF.

    It is stunning that the coder did not bother to test is his "algofithm" returns at least closely good values. I still havent found a single input with even close correct result.

    My googles! They dont help! My eyeeees

  • fist-poster (unregistered)

    It seems that one assumption of the code was that a/b = (a+c)/(b+c). Math is hard and he should have simply converted the values to string first. By the way, what is wrong with dividing 0 by non-zero?

  • AdT (unregistered) in reply to amoore
    amoore:
    Is the real WTF the fact that this code is commented?

    No, the real WTF as usual are the article comments.

    Just Some Guy:
    New terms for standard mathematical words (eg "dividend" for "numerator"): check.

    There is another new fangled thing that's called a dictionary. You may be interested in getting one. The real WTF is "divider" instead of "divisor" as was pointed out before.

    Captcha: blind, sorry, bling. Oh the irony.

  • Harrow (unregistered)

    I think this comment line is particularly telling:

    /// <returns></returns>

    Obviously the coder himself couldn't say WTF is returned.

    -Harrow.

  • Anonymously Yours (unregistered)

    The only thing missing is a call to containsNotEqualBackwards(), to confirm the variables at the end there.

  • Random ASUS user (unregistered) in reply to Quietust
    Quietust:
    Keko:
    0/0 = FILE_NOT_FOUND

    No, dividing by zero yields OH SHI--

    The moment I read that, I heard someone else say "OH SHI-". He was not reading this page. What a bizarre coincidence.

  • Paul (unregistered) in reply to fist-poster
    fist-poster:
    It seems that one assumption of the code was that a/b = (a+c)/(b+c).

    It is for sufficiently small values of c, but even after replacing 10 by 10^-10 you don't get the correct answer. Using the de facto standard test of 10/2, the result returned by the code tends to 1.8 as c -> 0.

  • (cs) in reply to Just Some Guy
    Just Some Guy:
    New terms for standard mathematical words (eg "dividend" for "numerator"): check.
    No. dividend (dividende in French) is like numerator (numérateur in French). Dividend come from Latin dividendum and means "is being divided". -endum is a special suffixe in Latin and always means "is being-". You guess what "fuckendum" means. See http://en.wiktionary.org/wiki/dividend.

    You can say dividend/divisor when speaking about Euclydian division and numerator/denominator when speaking about a fraction. See Wikipedia definition for all tis stuff.

    But this Division by 0 is trully a WTF. Not only the resulult is always false, but when it invents the mathematical concept that dividing by 0 is determined and not null and included in Q (all real number that can be represented as X/Y, X & Y being integers).

  • Choda (unregistered)

    You just have to love how the code snippet never checks wether the dividend or divider actually ARE zero.

  • Jim (unregistered) in reply to Wameng Vang
    Wameng Vang:
    <snip> Somebody needs to re-take Programming 101.<snip>

    Forget Programming 101, he needs to go back to Pre-Algebra. (His code, although horrible for the eyes, is... correct... (For Programming 101) Now if you will excuse me, I need to flush what I just saw out of my system.)

  • Argon (unregistered) in reply to Faxmachinen

    since the integer operation "*= 2" is identical with "<<= 2"

    WTF? "= 2" is "<<= 1". "= 4" is "<<= 2".

  • reigmund (unregistered) in reply to Jim
    Jim:
    Now if you will excuse me, I need to flush what I just saw out of my system.)

    How can you unread what you have read?

    Please, tell me, since I follow this site I think I'm learning how to do things the bad way and I doubt that I can do them right from now on :`(

    Heeeeeeeelp!!!!

  • Wait, maybe that was TV (unregistered) in reply to LiquidFire
    LiquidFire:
    What's wrong with:
    if (divider == 0) /* handle it however you want */;
    else return dividend/divider;

    0.0000000000000(insert more zeros here if required)0000001 != 0, but dividing by the former might still cause a division error. You'd probably get an overflow (+Inf or -Inf) rather than division by zero, but it's an error nonetheless.

  • (cs) in reply to Paul
    Paul:
    fist-poster:
    It seems that one assumption of the code was that a/b = (a+c)/(b+c).

    It is for sufficiently small values of c, but even after replacing 10 by 10^-10 you don't get the correct answer. Using the de facto standard test of 10/2, the result returned by the code tends to 1.8 as c -> 0.

    Just looked closer, and for the case where dividend is greater than divider, this simplifies (excluding that special case in the middle, I'm not sure what that is trying to catch) to (2*dividend - divider + c)/(dividend +c), so you're not actually dividing by the divider at all.

  • sf (unregistered) in reply to HappilyEverAfter
    HappilyEverAfter:
    The person who wrote this ...code was my coworker. You can not imagine how happy I was when company decided to let him go. Alltough we got rid of the meanace he left behind hundreds and hundreds of lines bad code. But there is something good even that. I have never laughed as much when I read some of his code trough. You really should have seen how he managed to convert integer to decimal :D
    Have you submitted those as well? This is one of the better ones we've seen in a while. I'd like to see more!
  • Wait, maybe that was TV (unregistered)

    OK, so at first glance it looks like he's using a very clever way to deal with the problem of dividing by values very close to zero. These are very easy values to get with innocuous-looking math, e.g. 40.0 / 4000.0 - 0.01 = -2.0837010502455788341080733516719192266464233398438e-19.

    The problem is that for sufficiently small values of x, (x != 0.0) is true, but (1000.0 / x) will result in an error (specifically an overflow). I suppose the math implementation might also try to denormalize the divisor before division and end up with zero, which will result in a different error (division by zero).

    If you instead do the check (divisor + 10 == 10) then you effectively truncate the divisor to zero if it is less than epsilon * 2 ^ (log2(10) - 51). Addition with doubles starts by shifting the mantissa of the lower-exponent value to match the higher-exponent value, which in the case of values smaller than 2^-51 * (higher-exponent-value) will turn the lower-exponent value into zero. If your floating point implementation has more or less than 51 bits in its mantissa then adjust accordingly.

    To use the example above:

    (40.0 / 4000.0 - 0.01) != 0.0

    but

    (40.0 / 4000.0 - 0.01) + 10.0 == 10.0

    (at least on an i686 machine with GCC 4.1).

    Unfortunately it seems that he's not doing anything near that smart...

  • sf (unregistered) in reply to jbosss
    jbosss:
    Hillaaarious! This is maybe better than the True/False/FileNotFound WTF.

    It is stunning that the coder did not bother to test is his "algofithm" returns at least closely good values. I still havent found a single input with even close correct result.

    My googles! They dont help! My eyeeees

    Well it does return the correct values for the arguments (n,n) for all n not equal to 0. So he's got THAT going for him :-)

  • Steve (unregistered)

    That's just painful.

    My brain is bleeding.

  • HappilyEverAfter (unregistered) in reply to sf
    sf:
    HappilyEverAfter:
    The person who wrote this ...code was my coworker. You can not imagine how happy I was when company decided to let him go. Alltough we got rid of the meanace he left behind hundreds and hundreds of lines bad code. But there is something good even that. I have never laughed as much when I read some of his code trough. You really should have seen how he managed to convert integer to decimal :D
    Have you submitted those as well? This is one of the better ones we've seen in a while. I'd like to see more!
    Not yet. And by the way it was not me who actually submitted that piece of code. But do not worry you can expect brilliant code examples from the areas of; Data type conversion, SQL query, Calculation and common error handling.
  • Brandon (unregistered)

    Results: running this code for both values being -10000 to 10000, excluding numerator / denominator, and excluding numerator / 0, these are the only correct results:

    -2040 / -850 = 2.4 -2040 / 4920 = -0.414634146341463 -850 / -2040 = 0.416666666666667 -350 / -150 = 2.33333333333333 -350 / 840 = -0.416666666666667 -150 / -350 = 0.428571428571429 -60 / -30 = 2 -60 / 140 = -0.428571428571429 -30 / -60 = 0.5 -10 / 20 = -0.5 20 / -10 = -2 140 / -60 = -2.33333333333333 840 / -350 = -2.4 4920 / -2040 = -2.41176470588235

  • hibikir (unregistered)

    The code is insane, but the terminology is not completely wrong: dividend does mean 'quantity to be divided'.

    A coworker of mine does worse though: In some reports, a division by zero is represented by 'fifty', in text!

  • (cs)

    Gah, I hate seeing crap like this. If you are about to divide by zero, things are already terribly wrong. There is no appropriate answer to a question that makes no sense.

    If you are about to divide by zero, this indicates that you are in some kind of exceptional case, which is going to require different handling. YOU SHOULD HAVE IDENTIFIED THIS SPECIAL CASE LONG AGO, not at the moment before you are about to do the division. I don't care what domain you're working in -- a special divide function with divide-by-zero protection is just freaking dumb.

    "My arm hurts when I do this!" Well, don't DO that then.

  • rumpelstiltskin (unregistered) in reply to Eric
    Eric:
    Demi:
    Although this seems C# code, I'd like to point out that Java can divide by zero without errors. System.out.println(5.0 / 0); will print "Infinity".
    That's not always true though, 5.0 / 0 could easily be NaN or negative infinity.

    Captcha: hmm, I got this captcha once before, it's even in the auto-form-filler as the last used....

    No, it can't. Unless, by "easily", you mean, "incorrectly".

  • eric76 (unregistered)

    Does this mean that another Martian lander is going to be lost?

  • liltim (unregistered)

    Wow...this can't be true. No, seriously, it just can't. I know that some programmers are retards but DAMN! I only hope that this one doesn't go to teaching and pass this crap on to the kids. Oh the horror!

    MIGRAINE!!! Must take Advil NOW!

    CAPTCHA: dubya (fitting, isn't it?)

  • Jaga (unregistered)

    сабж

  • Zygo (unregistered) in reply to Wait, maybe that was TV
    Wait:
    If you instead do the check (divisor + 10 == 10) then you effectively truncate the divisor to zero if it is less than epsilon * 2 ^ (log2(10) - 51).

    If by "epsilon" you mean "one", or by "51" you mean zero, then yes.

  • Dot For Now (unregistered) in reply to Just Some Guy

    Dividend and Divisor are standard though old-fashioned terminology.

    And for the English guy, well, divide by zero freaks turn up all the time.

    However, IEEE floating point has the concept of a NaN (Not A Number) which is produced by various invalid operations. I suppose that's what Anderson was trying to do, but it's hardly a great breakthrough and probably too tricky for younger students.

  • knock it off... (unregistered) in reply to Kilwch
    Kilwch:
    Dividend come from Latin dividendum and means "is being divided". -endum is a special suffixe in Latin and always means "is being-".
    Not exactly... sorry, but I have to nit-pick a little ;o)

    The suffix is not always "-endum" and it is not just a fixed "special suffix" - it is the gerundive (see http://en.wikipedia.org/wiki/Gerundive) and the exact form depends on the conjugation of the verb, the genus, the grammatical number etc. popular examples: "ceterum censeo carthaginem delendam esse" or "quod erat demonstrandum" etc.

    Otherwise, I concur :o)

  • AnnC (unregistered) in reply to Anonymous
    Anonymous:
    LiquidFire:
    What's wrong with:
    if (divider == 0) /* handle it however you want */;
    else return dividend/divider;

    That won't work because a divider is that thing that seperates a room into two parts. A divisor however... that's a different story.

    Maybe the programmer was a untie-er not a divisor.

  • AdT (unregistered) in reply to Zygo
    Zygo:
    If by "epsilon" you mean "one", or by "51" you mean zero, then yes.

    Ha ha! Another WTF comment par excellence. If divisor's absolute value is less than 10, then the addition will likely truncate a part of its mantissa (which happens to be 52 bits and not 51 bits wide for "double"s) in the addition. This is what the formula is intended to express. Your "corrections", OTOH, don't make any sense whatsoever.

    There is one caveat: By default, x86 processors use 80-bit floats internally and only perform conversions to IEEE single and double precision floats when asked to do so. Therefore, 10 + x may be considered not equal to 10 even if x is less than 10 * 2^(-52) as long as the result of the addition is kept in a floating-point register and not explicitely rounded. The joys of floating-point arithmetic... in Java, this could be avoided with the strictfp keyword. In this case, it would force 10 + x to be rounded to double precision before the comparison, so e.g.

    public static strictfp boolean truncateTest() { double x = 1e-16; return 10 + x == 10; }

    would return true on all platforms.

    Here's some output from Hugs which uses doubles by default and obviously rounds intermediate results:

    Hugs> (10 + 1e-13) - 10 9.9475983006414e-014 Hugs> (10 + 1e-14) - 10 1.06581410364015e-014 Hugs> (10 + 1e-15) - 10 1.77635683940025e-015 Hugs> (10 + 1e-16) - 10 0.0

  • Sigivald (unregistered)

    I'm with Sgt. Preston, though I credit the Utah Public Schools, not Canada.

    "Dividend" for "That which is Divided", was standard in my day... and according to the dictionary, it still is.

    (Admittedly, using "divider" rather than "divisor" is non-standard, but faulty memory suffices to explain it - and at the level of English rather than Jargon it's correct.)

    The Real WTF is having to use BBCode. There's already an absolutely standard system for formatting text and inserting links, that our browsers and this site already implement. We call it "HTML".

  • Anonymoose (unregistered) in reply to Just Some Guy

    Just tossing this out there: divisor/dividend are also standard terms (not divider, though).

  • (cs) in reply to Sigivald
    Sigivald:
    The Real WTF is having to use BBCode. There's already an absolutely standard system for formatting text and inserting links, that our browsers and this site already implement. We call it "HTML".

    The use of BBCode has one rather nice advantage: You don't have to worry about sanitizing HTML. If you just disallow ALL HTML and make people stick to a small set of explicitly-defined BBCode tags, you're much safer.

    As with anything else that needs to be sanitized, you don't want to specify what you don't want...You want to specify what you do want and then implicitly deny everything else. Then your ass is covered. ;)

  • (cs) in reply to SuperousOxide
    SuperousOxide:
    Beau "Porpus" Wilkinson:
        /// <summary>
        ///  shifts all windows
        /// </summary>
        /// <param name="processName">name of process</param>
    

    Truly, XML at its finest.

    If someone is going to fill out the comment like you show above, they wouldn't have added a better comment without the markup either.

    // Summary: // shifts all windows // // Params: // processName: Name of Process that owns the windows //

    WOW a much better comment because it is easier to humanly read.

  • (cs)

    O - M - G !!!!!

  • ounos (unregistered) in reply to n9ds
    n9ds:
    if divider = 0 then don't even bother trying to divide because it will cause an error.
    (Not really an error but) he must have been seeing strange NaN values get printed or something, and provided a "fix" for this obvious bug :-P
  • (cs) in reply to Just Some Guy
    Just Some Guy:
    if divider = 0 then don't even bother trying to divide because it will cause an error.

    Well, exceptions would typically be faster than running that test 1,000,000 times in the off chance that it might actually return True once.

    No, thats a myth. In most compilers its the opposite. The checks usually get optimized by the compiler, while exceptions are somewhat costly (for instance you have to create an object, and there is very little optimization done as exceptions are supposed to rarely occur).

  • (cs)

    Holy cow. The WTF of this article fades to nothing compared with that of James Anderson.

  • Robert (unregistered) in reply to Anonymous German
    Anonymous German:
    Just Some Guy:
    New terms for standard mathematical words (eg "dividend" for "numerator"): check.

    Nah, this just confirms that the "coder" is a German...

    Don't know in which universe you checked, but when I was in school, we called those "Dividend" and "Divisor", which would actually be the correct terms for the two operands of a division; "numerator" and "denominator" are used for a fraction ("Bruch"), and the correct German words are "Zähler" and "Nenner".

  • Synonymous Awkward (unregistered) in reply to Opie
    Opie:
    Sigivald:
    The Real WTF is having to use BBCode. There's already an absolutely standard system for formatting text and inserting links, that our browsers and this site already implement. We call it "HTML".

    The use of BBCode has one rather nice advantage: You don't have to worry about sanitizing HTML. If you just disallow ALL HTML and make people stick to a small set of explicitly-defined BBCode tags, you're much safer.

    As with anything else that needs to be sanitized, you don't want to specify what you don't want...You want to specify what you do want and then implicitly deny everything else. Then your ass is covered. ;)

    And indeed there was a recent <script> incident on this very site that demonstrated precisely why this is desirable.

  • (cs)

    I didn't even know it's possible to ++ floating points :)

  • James (unregistered) in reply to fist-poster
    fist-poster:
    It seems that one assumption of the code was that a/b = (a+c)/(b+c). Math is hard and he should have simply converted the values to string first. By the way, what is wrong with dividing 0 by non-zero?

    Thanks. In a lot of these WTFs you can see what they were trying to do. In this case I was really struggling to see what he was trying to achieve.

    An excellent combination of bad programming and bad maths.

  • Hognoxious (unregistered) in reply to Just Some Guy
    Just Some Guy:
    New terms for standard mathematical words (eg "dividend" for "numerator"): check.
    We have some tables here with fields "Numerator" and "Denumarator" that are used for inflation indexing. The latter (or is it the former, I can't remember if he got them the right way round - anyway, the one on the bottom) is always a power of ten, so I assume he did it like that because he never really mastered how to use decimals and/or percentages.
  • sirGustav (unregistered) in reply to Waffles
    Waffles:
    Demi:
    Although this seems C# code, I'd like to point out that Java can divide by zero without errors. System.out.println(5.0 / 0); will print "Infinity". System.out.println(0.0 / 0); will print "NaN".
    Yup, pretty much any language can do that. Including C# or C++ for that matter. It's a property of the IEEE floating point standard. Few languages bother to actually throw exceptions on a divide-by-zero.

    But of course, that doesn't really make the result "correct". It's hard to do much useful with a NaN. :)

    System.out.println(5.0 / 0.0); throws DivisionByZero System.out.println(0.0 / 0.0); throws DivisionByZero

    That is division by float/double throws, division by integers results in nan/infinity. I can only guess why.

Leave a comment on “Division By Zero, Solved Yet Again”

Log In or post as a guest

Replying to comment #:

« Return to Article