We don't need no stinking abs.



  • The code is Java.  rng is a java.security.SecureRandom.  It was developed by our off-shore developers.  The purpose is to generate a temporary ID value; temporary IDs are denoted by their being negative.  The use of a 32-bit RNG to generate temporary IDs is in and of itself a WTF; it (unsurprisingly) generated the occasional duplicate ID.  Quality with a capital K.

    	static protected int generateTemporaryIntId()
    	{
    		int id = rng.nextInt();
    		// convert to a negative number
    		String sId = Integer.toString(id);
    		if(sId.startsWith("-"))
    		{
    			// number is already negative
    			return id;
    		}
    		// else add a negative value to it
    		String sNegativeId = "-" + sId;
    		return new Integer(sNegativeId).intValue();
    	}
    

    Apparently Math.abs(rng.nextInt(); was too easy for them.  That the RNG could return 0 also never occurred to them (that happened too).  Of course, this is a recursive WTF. Their negation mechanism is a WTF. That they have to check what the value is is another WTF. Though Java's RNG has no way of forcing negative numbers, it does have a way of forcing *positive* ones, and if you know that a number is positive, you can simply negate it without having to examine the number itself (let alone convert it to a fucking string, prepend a -, and convert back to an integer). -rng.nextInt(0x7fffffff) would do the right thing.

    This is of course generated by a third level of WTFs--the use of these numbers as IDs. A straight decrementing counter would never create clashing IDs (we can't have 231 in-flight temporary values at any one time, so even if the counter wraps around we wouldn't have a problem)--this is what we ultimately ended up using--and avoid all the WTFs completely.



  • rng is a java.security.SecureRandom

    Sorry; I got this wrong.  It was meant to be, but it wasn't.  It's an off-shore developer-supplied java.util.Random subclass which appears inferior to java.util.Random.  They designed it so that it "should" defer to a java.security.SecureRandom using bytes from /dev/random as a seed.  However, this code path failed to work (Windows has no /dev/random...) so it defaulted to its own custom pRNG as a fallback.

     



  • These posts appear all the time here. The 'Classic' WTFs, you might call them. They seem to demonstrate a sophisticated understanding of the task at hand:

    • What a random number generator is, and how it differs from a pseudo-RNG;
    • Sub-classing of built-in objects to "add" functionality;
    • Graceful degradation, using a software pRNG if /dev/random isn't available
    And so on.

    And yet at the very bottom level, the level of line-by-line implementation, something really bloomin' funny happens. But can anyone explain why it happens? Is it a case of separation of architecture and implementation? Is it just that someone who knows (something about) what they're doing designs the skeleton, and then the idiots fill in the blanks?

    Or is there something subtler than that? I'm not a professional coder and I've never worked on any multi-person projects with any scope. Can someone who's met these things first hand explain how it happens?



  • @DrPizza said:

    rng is a java.security.SecureRandom

    Sorry; I got this wrong.  It was meant to be, but it wasn't.  It's an off-shore developer-supplied java.util.Random subclass which appears inferior to java.util.Random.  They designed it so that it "should" defer to a java.security.SecureRandom using bytes from /dev/random as a seed.  However, this code path failed to work (Windows has no /dev/random...) so it defaulted to its own custom pRNG as a fallback.

     

    Hmm, I'd recommend making a file called C:\dev\random and putting a value of '1' in it.  That way you could get rid of a potential 'file not found' error.

    (And, no.  I'm not serious.)



  • @DrPizza said:

    Apparently Math.abs(rng.nextInt(); was too easy for them.  



    Can't you just check if it is less than zero?  I don't know Java, so I'm not sure if this is possible, but even this seems less convoluted:

    	int id = rng.nextInt();
    if (id > 0) {
    id *= -1;
    }

    or even:

    int id = rng.nextInt();
    if (id < 0) return id;
    return -id;
    But that still does not change the fact that the whole thing is a WTF.

         -dZ.



  • @ithika said:

    These posts appear all the time here. The
    'Classic' WTFs, you might call them. They seem to demonstrate a
    sophisticated understanding of the task at hand:
    • What a random number generator is, and how it differs from a pseudo-RNG;
    • Sub-classing of built-in objects to "add" functionality;
    • Graceful degradation, using a software pRNG if /dev/random isn't available
    And so on.

    And
    yet at the very bottom level, the level of line-by-line implementation,
    something really bloomin' funny happens. But can anyone explain why
    it happens? Is it a case of separation of architecture and
    implementation? Is it just that someone who knows (something about)
    what they're doing designs the skeleton, and then the idiots fill in
    the blanks?

    Or is there something subtler than that? I'm not a
    professional coder and I've never worked on any multi-person projects
    with any scope. Can someone who's met these things first hand explain
    how it happens?


    It's NIH (not invented here) syndrome, which is in turn related to the
    "do everything yourself" mentality I mentioned in another thread. 
    The practice named in your second bullet item is where the trouble
    lies:  programmers think they can invent something better. 
    But when they get down to rolling their own implementation, they end up
    having to learn all the same lessons that were learned by the authors
    of the original object.  Except the authors of the original object
    had hundreds of eyes reviewing it and offering advice and
    improvements.  Someone who rolls his own is usually in a vacuum,
    and so ends up learning maybe 10% of the lessons that the original
    object's authors learned.  The result:  an inferior
    implementation.




  • [OT] Re: We don't need no stinking abs.

    Am I the only here who thought of

    1. a muscular stomach
    2. anti-lock braking systems
    before thinking of the math function?



  • @ithika said:

    Or is there something subtler than that? I'm not a professional coder and I've never worked on any multi-person projects with any scope. Can someone who's met these things first hand explain how it happens?


    Not knowing.
    Not knowing that you don't know.
    Not thinking.
    Not wanting to think.

    Mental Blindness.


Log in to reply