• Eric (unregistered)

    75th

  • wtf (unregistered)

    When i++ just won't do... When while loops are just too loopy... Maybe he should have used the structure suggested by the CAPTCHA: an enim (sort of like an enum, on a diet)

  • bob (unregistered)

    64th

    Maybe somebody tried to explain the concept of UUIDs to him.

  • Anonymous (unregistered) in reply to wtf
    wtf:
    When i++ just won't do...
    Well, the specs *said* the number should be non-sequential. Hence, i++ just won't do, indeed.
  • Anonymous (unregistered)

    This one actually had me in hysterics! Generate three random numbers and hope one of them is unique - how genius is that? Of course, this code could easily be fixed by generating 48 random numbers, ensuring none of them clash and then performing the same logic. Bulletproof, right?!

  • (cs)

    TRWTF is.. Why non-sequential?

  • Studley (unregistered)

    Third time isn't necessarily the charm... of course the developer wasn't that narrow-minded, that's why he included a catch-all:

    return rand.Next(99).ToString();

    So if the third time isn't the charm... the fourth time will be!

    (Depending on how your sarcasm detector is configured, you may need to imagine a winking smiley here)

  • Sarge2009 (unregistered) in reply to DocBrown

    Probably some psuedo-requirement from someone who thought they were helping...

  • Anonymous (unregistered) in reply to DocBrown
    DocBrown:
    TRWTF is.. Why non-sequential?
    Maybe this is for a web form, where the ID is passed in on the querystring. So to buy themselves a bit of security through obscurity they insist that IDs are non sequential so people can't access records by guessing the next ID and putting it in the querystring. Retarded, I know, but I've seen this done more times than I care to remember.
  • (cs)

    A little bit of calculation indicates that the tipping point when you'd start to expect a lot of trouble would be about 19. (You need to work out what the chance of finding a unique value is with four attempts, given how many unique values are already present.)

    Of course, it could also just be ornery and give trouble on the fourth insert. Lovely.

  • (cs) in reply to Sarge2009
    Sarge2009:
    Probably some psuedo-requirement from someone who thought they were helping...

    Then, actually, TRWTF is that the code doesn't check the generated numbers to be compliant with this requirement =O

  • (cs) in reply to bob
    bob:
    64th

    Maybe somebody tried to explain the concept of UUIDs to him.

    Maybe someone should explain the concept to you.

  • (cs) in reply to Anonymous

    The real WTF is the requirement for a "unique non-sequential 2 digit identifier", Unless the Activity identifier only has to be unique within a specific period, and even then it's a little odd.

    You would run out of unique identifiers after a few periods.

    So many ways to do this. And all of them wrong.

    It reminds me of the "randomly assign jobs" code we've been asked to implement. I'll do a full write up later.

  • Yazeran (unregistered) in reply to DocBrown
    DocBrown:
    Sarge2009:
    Probably some psuedo-requirement from someone who thought they were helping...

    Then, actually, TRWTF is that the code doesn't check the generated numbers to be compliant with this requirement =O

    What do you mean... It checks perfectly for all activities (for values of all less than 4 that is... ;-)

    Yazeran

    Plan: To go to Mars one day with a hammer

  • (cs) in reply to wtf
    wtf:
    When i++ just won't do...
    You could always try i+=2 - that matches the given criteria (depending on the exact required meaning of "sequential") with the first value either "00" or "01"

    If not, just build a list of 48 numbers that don't repeat or form a sequence, and iterate through it - you can even pick a random start point if you want!

  • Jellineck (unregistered) in reply to Medezark
    Medezark:
    You would run out of unique identifiers after a few periods.

    I've found that you can run out of unique identifiers after a number of missed periods.

  • (cs)

    I was really hoping to write the 3rd, 6th or 10th comment today, but those spots are all taken. Therefore I'll just be the 2nd.

  • (cs) in reply to Yazeran
    Yazeran:
    DocBrown:

    Then, actually, TRWTF is that the code doesn't check the generated numbers to be compliant with this requirement =O

    What do you mean... It checks perfectly for all activities (for values of all less than 4 that is... ;-)

    Yazeran

    No, you can't trust random number generators these days! What if it does provide 3 sequential numbers? What do you do then, huh?

  • the beholder (unregistered) in reply to Jellineck
    Jellineck:
    Medezark:
    You would run out of unique identifiers after a few periods.
    I've found that you can run out of unique identifiers after a number of missed periods.
    When my wife missed her periods we had to start thinking on an identifier. It didn't have to be unique, though.
  • (cs)

    It's a good thing they're checking activity.Cod. Can you imagine the smell if they checked activity.Haddock instead?

  • Selis (unregistered)

    I couldn't help myself ...

    With a new seed each hit/miss-iteration:

    Hits=100 Misses=8491
Hits=100 Misses=7467
Hits=100 Misses=7346
Hits=100 Misses=7733
Hits=100 Misses=7336
Hits=100 Misses=8124
Hits=100 Misses=8083
Hits=100 Misses=8780
Hits=100 Misses=7629
Hits=100 Misses=7909

    With a static seed:

    Hits=100 Misses=392
Hits=100 Misses=287
Hits=100 Misses=344
Hits=100 Misses=449
Hits=100 Misses=488
Hits=100 Misses=389
Hits=100 Misses=391
Hits=100 Misses=445
Hits=100 Misses=415

    With the method in question being used to generate these Cod's there still is some room for performance improvement! :D

    Cheers!

  • Selis (unregistered) in reply to the beholder

    Good thing here in Sweden the government provides an NSGUID for you if you wait for a couple of months after you've run out of periods ... :D

  • asdf (unregistered)

    Nothing in the requirement stipulated random numbers. Random does not mean non-sequential. I agree with a previous poster implementing a lookup into an array of 48 suitably chosen two digit numerals. I would not infer anything that is not in the requirement.

  • Knux2 (unregistered) in reply to GettinSadda
    GettinSadda:
    wtf:
    When i++ just won't do...
    You could always try i+=2 - that matches the given criteria (depending on the exact required meaning of "sequential") with the first value either "00" or "01"

    i+=3 would work better - it would wrap around w/o repeating numbers until it used all 100 options (00-99)...

    (captcha:sagaciter - someone you never want to get in a Star Wars argument with)

  • Anon (unregistered) in reply to Medezark
    Medezark:
    The real WTF is the requirement for a "unique non-sequential 2 digit identifier", Unless the Activity identifier only has to be unique within a specific period, and even then it's a little odd.

    RTFA, it specifically says that the ids are unique for a given period. So no danger of running out of IDs.

  • That Guy (unregistered)

    I think those of you focusing on a list of 48 potential numbers are missing the fact that Periods may have up to 100 activities. The requirements are either inconsistent, or "non-sequential" was stated when it should have said "arbitrary".

    Has anyone else noticed that the first three numbers generated need not even all be distinct? Further fail.

  • (cs) in reply to Eric

    While this code is bad and stupid and ineffective but I can't see how it can generate many conflicts.

    The risk of conflict is very small.

    (Rounding a bit in my mat).

    With 25 activities where are 3/4 change that a generated number is unique, and 1/4 that it have been used.

    So the risk of generating 4 an ids already in use is 1/41/41/4*1/4=1/256 or something like 0.3%

    Or did I miss something.

    ps: The function does not generate 2 digit results for numbers 0 to 9.

  • patrick (unregistered) in reply to bob

    haha

    just hat a report about db4o uuid at school today ...

  • Anon (unregistered) in reply to the beholder
    the beholder:
    Jellineck:
    Medezark:
    You would run out of unique identifiers after a few periods.
    I've found that you can run out of unique identifiers after a number of missed periods.
    When my wife missed her periods we had to start thinking on an identifier. It didn't have to be unique, though.

    Indeed. Just ask George Foreman (and 5 of his 10 children who are also called George Foreman).

  • My Name (unregistered) in reply to dkf

    Actually, seeing how he doesn't check that the generated numbers aren't the same, you could get into trouble on the second insert.

  • asdf (unregistered) in reply to That Guy

    [A Period can have anywhere from zero to forty eight Activities]

    48 is adequate to meet the requirement.

  • Anonymous (unregistered) in reply to That Guy
    That Guy:
    I think those of you focusing on a list of 48 potential numbers are missing the fact that Periods may have up to 100 activities.
    The article clearly states that a period may have up to 48 activities.
  • wds (unregistered) in reply to Anon
    Anon:
    Medezark:
    The real WTF is the requirement for a "unique non-sequential 2 digit identifier", Unless the Activity identifier only has to be unique within a specific period, and even then it's a little odd.

    RTFA, it specifically says that the ids are unique for a given period. So no danger of running out of IDs.

    TFA says:

    ...and each Activity within a Period should have a unique, non-sequential, two-digit identifier (e.g. 02, 41, 99).
    You assumed that this meant unique within a period. It doesn't really say that though. If it said what you think it said it should say "each Activity should have a unique ... identifier within a Period". I agree that it's probably meant to say that, but TRWTF is, as always, the requirements.
  • Steve Johnstone (unregistered)

    I would love to know what those requirements are for. Any solution that involves generating a random number has a chance of being wrong because true randomness can and will generate sequential numbers.

  • This would make a good Perl golf question (unregistered)

    Here we go

    [code]$id=sprintf('%02d',(1..48)[int(rand(47))+1]);[code]

    Yes I know that Perl is the real WTF :)

  • Anonymous (unregistered) in reply to Steve Johnstone
    Steve Johnstone:
    I would love to know what those requirements are for. Any solution that involves generating a random number has a chance of being wrong because true randomness can and will generate sequential numbers.
    Bear in mind that the requirements said nothing about the IDs being random. It was the idiot coder who decided that was a good idea, it certainly never came from the requirements.
  • Steve (unregistered) in reply to bob
    bob:
    64th

    Maybe somebody tried to explain the concept of UUIDs to him.

    You might want to read up on that concept for yourself. You do realise that there is no such thing as a two digit UUID, don't you?

  • (cs) in reply to asdf
    asdf:
    Random does not mean non-sequential. I agree with a previous poster implementing a lookup into an array of 48 suitably chosen two digit numerals. I would not infer anything that is not in the requirement.

    However, by creating that array of 48 numbers, you've just defined a new sequence. From the first result off of googling "define:sequence":

    serial arrangement in which things follow in logical order or a recurrent pattern

    So if you set up a pattern like '02', '41', '99', ... for every period, then you're following a sequence. It may be a sequence of your own invention, but it still a recognizable sequence where '99' always follows '41' (except when the sequence is truncated to less than 3 elements), and so forth. It's a recurrent pattern that occurs over and over again for each period.

    While I applaud your devotion to not inferring things that aren't in the spec, your solution fails the non-sequential rule. If the intent of the non-sequential rule was to prevent people from being able to easily enumerate the activities in each period by guessing sequential activity ids, then your solution has produced a less useful result.

    Now one could argue that a liberal enough definition of sequence makes everything a sequence -- similar to the classic argument about how there are no uninteresting numbers. Still, I suspect that randomly chosen ids would satisfy the customer. However, the only truly proper solution would be to seek clarification on the requirement.

  • (cs) in reply to Anonymous
    Anonymous:
    Steve Johnstone:
    I would love to know what those requirements are for. Any solution that involves generating a random number has a chance of being wrong because true randomness can and will generate sequential numbers.
    Bear in mind that the requirements said nothing about the IDs being random. It was the idiot coder who decided that was a good idea, it certainly never came from the requirements.

    Can you have a non-random set of numbers that's not a sequence?

  • (cs) in reply to That Guy
    That Guy:
    I think those of you focusing on a list of 48 potential numbers are missing the fact that Periods may have up to 100 activities. The requirements are either inconsistent, or "non-sequential" was stated when it should have said "arbitrary".
    Exactly what I was thinking. In this case I think they meant "non-sequential" to be "it's ok if there are gaps".
  • TGVish (unregistered) in reply to tiller
    So the risk of generating 4 an ids already in use is 1/4*1/4*1/4*1/4=1/256 or something like 0.3%

    Or did I miss something.

    The probability that two people in a group share the same birthday is 50% when there are more than 23 people, and that's with 365 numbers to chose from. So yes, you did miss something, like probability 101.

    Take the worst case scenario: 47 out of 100 numbers have been taken. Then random guess #1 has a probability of failing of 47/100, #2 as well, #3 as well and #4 as well. The chance that they all fail is therefore (47/100)^4 = 5%. And that is assuming the random generator doesn't get reset...

  • TGVish (unregistered) in reply to TGVish

    [quote user="TGVish"][quote] The chance that they all fail is therefore (47/100)^4 = 5%.[/quote] And I forgot to add that it is cumulative. On the first round, failure probability is 0%. On the second, 1/100. On the third, approximately 2/100, etc. That means that by the time you reach a higher number, the probability that any one of the previous calls failed is pretty high. The most likely position to hit before it happens might be around 25...

    Anyway, what idiotic system is this? Why is it needed? To avoid that people can guess the next number?

  • Gumby (unregistered)

    Nine. Nine. Nine.

  • Jon H (unregistered) in reply to wds
    wds:
    Anon:
    Medezark:
    The real WTF is the requirement for a "unique non-sequential 2 digit identifier", Unless the Activity identifier only has to be unique within a specific period, and even then it's a little odd.

    RTFA, it specifically says that the ids are unique for a given period. So no danger of running out of IDs.

    TFA says:

    ...and each Activity within a Period should have a unique, non-sequential, two-digit identifier (e.g. 02, 41, 99).
    You assumed that this meant unique within a period. It doesn't really say that though. If it said what you think it said it should say "each Activity should have a unique ... identifier within a Period". I agree that it's probably meant to say that, but TRWTF is, as always, the requirements.

    Requirements are never complete and well-defined, never. That's why someone invented Scrum and iterative development and such nice things. However, if given requirements should have any sensible interpretation, I find it obvous that uniqueness was meant to be confined to a period.

    There are ambiguities enough without beginning to make a lot more just to be smart.

  • anon (unregistered)

    If at first you don't succeed. try try and try again.

    After that Fail!

  • Pedants R Us (unregistered)

    TRWTF is using activity.Cod instead of activity.Flounder.

  • ipeet (unregistered) in reply to TGVish
    TGVish:
    So the risk of generating 4 an ids already in use is 1/4*1/4*1/4*1/4=1/256 or something like 0.3%

    Or did I miss something.

    The probability that two people in a group share the same birthday is 50% when there are more than 23 people, and that's with 365 numbers to chose from. So yes, you did miss something, like probability 101.

    What TGVish is implying but not explicitly mentioning is how unlikely events become more and more likely to happen at least once over many tries. We're not worried about the probability of finding a unique ID for any given creation, we're worried about the overall probability.

    Let's take something that has 1/100 probability of happening. That's pretty unlikely, if you take only one shot at it. But how likely is it if you try 20 times? To figure this out, you use negation. The probability of the event happening at least once is the complement of the probability of the event never happening.

    Over 20 attempts, the probability of a 1/100 event happening at least once is (1 - (99/100)^20) = 18%. It kind of snowballs, by the way.

    The probabilities in the WTF are a bit more complicated, but it's the same idea.

  • asdf (unregistered) in reply to Erasmus Darwin

    sequential:

    Adapted From: WordNet 2.0 Copyright 2003 by Princeton University. All rights reserved.

    sequential A adjective 1 consecutive, sequent, sequential, serial, successive

    Please see the definition of "sequential", not "sequence".

  • Anonymous (unregistered) in reply to Charleh
    Charleh:
    Anonymous:
    Steve Johnstone:
    I would love to know what those requirements are for. Any solution that involves generating a random number has a chance of being wrong because true randomness can and will generate sequential numbers.
    Bear in mind that the requirements said nothing about the IDs being random. It was the idiot coder who decided that was a good idea, it certainly never came from the requirements.

    Can you have a non-random set of numbers that's not a sequence?

    Of course you can. You could generate a set of numbers based on some equation, which would produce a non-random result with no apparent sequence.
  • JR (unregistered)

    static int lastGeneratedCode = 0; final int MAX_NUM_ACTIVITIES = 48;

    public string GenerateNewActivityCode(Period period) { lastGeneratedCode+=2; return ... ; // add your favorite string conversion here }

    Am I missing something? Non-sequential? Yes, the odd numbers are missing. Uniqueness? Of course.

Leave a comment on “Something Weird”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article