• (cs) in reply to javascript jan
    Anonymous:
    The real WTF is that I fell for your obvious self-pimping :-)
     

    50% self-pimping, 50% interested in getting the opinions of opinionated people. :)

  • Jason (unregistered) in reply to Tim Gallagher

    This thread is enough of a WTF for me! How many times does the rand() snippet need to be described before people get it?

     Recursive error handling *shudder*

     
    Captcha: clueless - like so many, so many...
     

  • (cs) in reply to RiX0R
    RiX0R:

    The following code is correct, but illustrates why the previous code is wrong (the initialization doesn't always happen):

    # Biff or Cliff
    $Owner->LoadById('70656');
    if (rand() < 0.5) {$Owner->LoadById('72586');}

    That might be wrong if the system emails the new ticket owner as soon as the ticket is assigned.  In that case, 70656 would always be emailed, even if the ticket ended up being assigned to 72586. 

  • (cs) in reply to emurphy
    emurphy:

    I suppose

    use define SALESPERSON1_ID => 70656; # Biff
    use define SALESPERSON2_ID => 72586; # Cliff

    is considered too obvious to bother pointing out explicitly?

    I would do:

    use define BILL_ID => 70656;
    use define CLIFF_ID => 72586;

    More explicit, you don't have to look up the definition of the salesperson to see who it is, and you can save yourself the comments. 

  • Procyon (unregistered) in reply to Jason
    Anonymous:

    This thread is enough of a WTF for me! How many times does the rand() snippet need to be described before people get it?

     Recursive error handling *shudder*

     
    Captcha: clueless - like so many, so many...
     

     

    At least it's tail recursive ;) 

  • Lummox (unregistered) in reply to Dr_Barnowl

    I was thinking the 0 to RAND_MAX too when I made the comment, I didn't realize that PERL returned a float between 0 and 1 (I have almost never used PERL).  I was used to the C methodology of returning a number between 0 and RAND_MAX which I thought PHP did as well.  My bad on that.

     As for totally overlooking the names, like I said, it was late and I was not thinking clearly :P
     

  • wayne (unregistered) in reply to mol
    Anonymous:
    Anonymous:

     BTW: I'm curious about what you guys would call the best php templating strategy if plain php files and smarty both suck badly.

    Since PHP 5: XSLT  

    I knew that someone would say this. XSLT is fine: if you have some XML to transform. For most (advanced) templating purposes it sucks ass. I smell some major WTFs there.
     

  • Jason (unregistered) in reply to wayne
    Anonymous:
    Anonymous:
    Anonymous:

     BTW: I'm curious about what you guys would call the best php templating strategy if plain php files and smarty both suck badly.

    Since PHP 5: XSLT  

    I knew that someone would say this. XSLT is fine: if you have some XML to transform. For most (advanced) templating purposes it sucks ass. I smell some major WTFs there.
     

    Oh man, don't get me started on using XSLT as a templating platform.  If you've ever had to touch Cocoon, you know my pain. XSLT stylesheets are the most difficult to write, understand, and debug of all web templating systems, as as the above said, you STILL need a base XML to transform, so it really gets you nothing.

    In regards to templating with PHP, I would say Smarty templates, but those clutter up the HTML something fierce though are still much, much better than XSLT.
     

  • Corporate Cog (unregistered)

    I've absolutely what the first one "aMethod" is supposed to do, but I think that's the biggest wtf I've ever seen.

    I don't have any clue what the third one should do either (the 2 end braces after each statement are confusing). 

  • (cs) in reply to Corporate Cog

    It really boggles my mind when I see code like the ticket tracking one.

    Why didn't an else statement come to ming when writing it?

    -Adam

    www.winemakingjournal.com

  • Anonymous (unregistered) in reply to boflexson

    It baffles me that no one is batting an eyelid about the fact that the code is:

     a) hardcoded for the staff - surely that could be replaced with something which specifies a list of the staff and the hours they work?

    b) that random is the criteria for assignment - surely an even distribution would work better?

     Even better, don't assign - just list and have the relevant staff share a view and assign on a first come, first served basis? I mean, really - what happens when one of the two are on holiday - you need to modify the code?

    Baffling... 

  • (cs)

    Good intentions sometimes outweigh the reality of <there are idiots everywhere you go/>

  • (cs) in reply to Anonymous
    Anonymous:

    b) that random is the criteria for assignment - surely an even distribution would work better?



    Anyone (Andrew Zhilenko, for example) care to enlighten Anon, UncleMidriff, Anonymous and me on this one?
  • Anonymous Coward (unregistered) in reply to Anonymous

    There's one other issue, however--calling rand() that close together, it's likely that a lot of implementations are going to return the exact same value if rand isn't seeded correctly or if the implementation of rand relies on something like the system timer.  For example, many rand implementations rely on tick count values as a seed.  However, if two calls to rand are adjacent, and there is no seed between them, the likelyhood of them occuring on the same tickcount is pretty damn high.

    For example, see http://blogs.msdn.com/toub/archive/2006/04/07/571086.aspx

    I'm not totally sure what language this particular WTF is implemented in (sorry, I'm just a C/C++/C# nerd, and don't bother looking out the window very often :P), but if he forgot to seed between calls to rand, it's likely that he'd end up with the exact same value both time.  Were that the case, there's a 50% chance that both of them would get it, or a 50% chance that neither of them would get it.

     So the bugs for this code include:

    • calling rand twice where one call would suffice
    • potentially not seeding rand, or calling rand so closely together that the likelyhood of it returning the exact same value is very respectable, depending upon the implementation of rand() for that API.
    • some very debatable if statements
  • Anonymous Coward (unregistered) in reply to Anonymous Coward
    Anonymous:

    There's one other issue, however--calling rand() that close together, it's likely that a lot of implementations are going to return the exact same value if rand isn't seeded correctly or if the implementation of rand relies on something like the system timer.  For example, many rand implementations rely on tick count values as a seed.  However, if two calls to rand are adjacent, and there is no seed between them, the likelyhood of them occuring on the same tickcount is pretty damn high.

    For example, see http://blogs.msdn.com/toub/archive/2006/04/07/571086.aspx

    I'm not totally sure what language this particular WTF is implemented in (sorry, I'm just a C/C++/C# nerd, and don't bother looking out the window very often :P), but if he forgot to seed between calls to rand, it's likely that he'd end up with the exact same value both time.  Were that the case, there's a 50% chance that both of them would get it, or a 50% chance that neither of them would get it.

     So the bugs for this code include:

    • calling rand twice where one call would suffice
    • potentially not seeding rand, or calling rand so closely together that the likelyhood of it returning the exact same value is very respectable, depending upon the implementation of rand() for that API.
    • some very debatable if statements

     

    Whoops, got my own wtf....my percentages are wrong....if rand() returns the same value both times (which is possible), the code would work "correctly".  However, if it split a system tick, then......yeah.

  • aes (unregistered) in reply to Anonymous Coward
    Anonymous:

    There's one other issue, however--calling rand() that close together, it's likely that a lot of implementations are going to return the exact same value if rand isn't seeded correctly or if the implementation of rand relies on something like the system timer.  For example, many rand implementations rely on tick count values as a seed.  However, if two calls to rand are adjacent, and there is no seed between them, the likelyhood of them occuring on the same tickcount is pretty damn high.

    For example, see http://blogs.msdn.com/toub/archive/2006/04/07/571086.aspx

     
    I looked at your article, because you seem to be describing a fairly sucky random number generator :-)

    You've misunderstood the point slightly. Mr Toub describes a situation where he seeds multiple random number generators with the same seed (ie. the system tick count), and then they come up with the same random number on their first call. However, what you want to do is call the random number function twice *without reseeding*, at which point it should come up with two different pseudorandom numbers (that is, indeed, the point of a random number generator). So basically, correct:

     

    seed_rand();

    a = rand();

    b = rand();

     

    and wrong:

     

    seed_rand();

    a = rand();

    seed_rand();

    b = rand();

     

    In an object oriented context (which this isn't), that involves holding onto the object instead of recreating it. 


    In other words, you've got it backwards.

  • (cs) in reply to rbs

    No, it's two calls to rand.

    There's a 50% chance that 70656 gets the ticket.

    Of the other tickets, there's a 50% chance that 72586 gets it.

    It's even better than that... once 70656 gets the ticket, that's not the end of it; it's chucked back into the tombola, and if it gets pulled out again 72586 gets it instead. So in fact, the chance of 70656 getting the ticket only ends up being about 25%, and 72586 has a 50% chance of ending up with the ticket. The rest are flushed down a manhole somewhere.

    Of course, random events only conform to their probabilities on aggregate, so it's entirely possible (but unlikely) that a whole day - or week, or sales quarter - could go by without assigning either of them a ticket. 

    It's a masterful piece of code, one has to admit.

    (update: lots of other people have explained this too. But I can't delete my post. Hmm... so if you could just pretend I deleted it, OK?)

  • (cs) in reply to Anonymous

    It baffles me that no one is batting an eyelid about the fact that the code is:

    a) hardcoded for the staff - surely that could be replaced with something which specifies a list of the staff and the hours they work?

    b) that random is the criteria for assignment - surely an even distribution would work better?

    Well, before getting onto questions of whether the code is actually doing the right thing in a real-world situation, it makes sense to first fix the coder's "not knowing about ELSE statements, non-repeatable functions, or basic probability maths" problems... the other stuff that you quite correctly point out would just go sailing over his head.

    (But yes, you're right - a workqueue would be the best option, absent all other constraints... where "constraints" is a euphemism for "micromanagement, stupidity and / or departmental corruption".)

  • (cs) in reply to Skroog
    Skroog:

    Um.... why don't you just call them Biff and Cliff in your conversation? :P

    Which is which? ...Well, we could assign their names randomly, according to the algorithm presented here.

    And then we can say that  will get 25% of the tickets and  will get 50%.

  • Anna Knee Mouse (unregistered) in reply to cdr
    Anonymous:
    Tim Gallagher:

    This is funny to me personally because I just wrote an article on PHP templating.



    Where's the link to the printable version? Shame.


    Why are you wasting paper printing things out?  Shame.`
  • Anonymous (unregistered) in reply to yv
    Anonymous:
    Anonymous:
    pointless.

    The thrid one it is posible that both will get it the job and even sometimes nun of the them would get the job.


    They have nuns working on the helpdesk now? Cool... :)

    Yeah, they sent off for ninjas but they got nuns.  Maybe they're ninjas in disguise.

  • javascript jan (unregistered) in reply to SpComb
    SpComb:
    Anonymous:

     The system you describe is just PHP; in particular, you describe content pages as pulling in formatting (headers, footers, etc). Typically when people talk about "templating engines" they are referring to a top-down organisation where _content_ is pulled in and requires no cargo-cult boilerplate.

     
    The real WTF is that I fell for your obvious self-pimping :-)

    template file:
     (excellent example snipped)

     That's exactly what I was talking about, and about a million times preferable to the stock PHP cruft in the article in question.

  • Justin (unregistered)

    why is it that no-one (that I saw) even mentioned the "if ($hour>=7 and $hour<18) {" bit ... if the hour is not in this range, then no-one gets it...

  • (cs)

    SOD 1: Ladies and gentlemen, welcome the brillant try-catch-recurse pattern...

    SOD 2: Wow, I didn't realize that it's so hard to do "\n" x $count in Poor Hacker's Perl... :o)

  • mol (unregistered) in reply to Jason
    Anonymous:
    Anonymous:
    Anonymous:
    Anonymous:

     BTW: I'm curious about what you guys would call the best php templating strategy if plain php files and smarty both suck badly.

    Since PHP 5: XSLT  

    I knew that someone would say this. XSLT is fine: if you have some XML to transform. For most (advanced) templating purposes it sucks ass. I smell some major WTFs there.
     

    Oh man, don't get me started on using XSLT as a templating platform.  If you've ever had to touch Cocoon, you know my pain. XSLT stylesheets are the most difficult to write, understand, and debug of all web templating systems, as as the above said, you STILL need a base XML to transform, so it really gets you nothing.

    You don't need any XML file, you just need it in memory (e.g. as a DOM) -- but anyway that's not visible, API for the PHP programmer is the same as for any other templating system (e.g. something like $page->set("name", $name);). You can use those fancy XML editors to write them and maybe even debug (I don't personally use them :-) so I don't know how much sophisticated they are). And the best thing: you can rewrite your application in something better than PHP and still use them without change.

  • (cs) in reply to mol

    Apparently nobody has figured out the Real WTF (TM) in the second snippet.

    http://www.php.net/str_repeat

    Those who don't know the language's built-in functions are doomed to re-implement them poorly.

     

     For people wondering about a decent template engine for PHP, http://trac.php-tools.net/patTemplate is pretty good.

  • (cs) in reply to Anonymous
    Anonymous:
    Anonymous:
    Anonymous:
    pointless.

    The thrid one it is posible that both will get it the job and even sometimes nun of the them would get the job.


    They have nuns working on the helpdesk now? Cool... :)
    Yeah, they sent off for ninjas but they got nuns.  Maybe they're ninjas in disguise.
    <font size="+1">W</font>ell, they both wear black and cover their faces, so who can tell?
  • John Nowak (unregistered) in reply to UncleMidriff
    UncleMidriff:
    Is there any reason to be randomly assigning tickets?  It could very well happen, even with a perfectly random ticket assigning process, that, out of 100 tickets, Person #1 could get 1 ticket, Person #2 could get 5 tickets, and Person #3 could get 94 tickets.  That'd be unlikely, I suppose, but it could happen.  Ideally, shouldn't such a system, upon receiving a new ticket to assign, check to see who has how many tickets, and then assign the new ticket to the guy with the fewest tickets already?  I've never worked on a ticketing system before, so I'm speaking out of ignorance here, but it seems to me that randomly assigning tickets is an odd way to go about things.

    It's not odd at all. If you just flip a coin and assign it, the function doesn't need to know about anything else. Depending on how the program is structured, getting at such data may be more trouble than it is worth. 
  • (cs)
    Tim Gallagher:
     public boolean aMethod(Object anObject) {
    try {
    /*
    * Some 50 lines of unreadable obfuscated code littered with
    * return statements, throwing some exceptions and performing
    * various exception prone operations like:
    * - parsing
    * - database access
    * - calling other methods of similar signature (but not catching Exception)
    */
    return true;
    } catch (Exception e /*PANIC. NEVER DO THIS AT HOME*/) {
    //call a method of similar signature
    aMethod(anObject); //RECURSION in exception handler => BUG => PANIC
    }
    }

    Right up there with "if it doesn't work, try again until it does"... Only you'll probably get to retry only ~ 300 or so times before you overflow the stack.

    Tim Gallagher:
    function br($count=1) {
    $br = '
    ';
    $out = '';
    for($i=0;$i<$count;$i++) {
    $out .= $br;
    }
    return $out;
    }

    Ok, I want to know, is there something wrong with "\n" I don't know about (not a big WTF, but would annoy me, personally)? Not to mention there's str_repeat("\n", $count) ...

    Tim Gallagher:
    if ($hour>=7 and $hour<18) {
    # Biff or Cliff
    if (rand() > 0.5) {$Owner->LoadById('70656');}
    if (rand() < 0.5) {$Owner->LoadById('72586');}
    }

    It looks like php, where rand() is an *integer* between 0 and RAND_MAX. 70656 must feel really loved.

    And in case it is (as someone mentioned) in fact Perl, and rand() is thus [0, 1), it would mean 25% chance of 70656, 25% chance of 72586, 25% chance of both, 25% chance of neither. Fun.

  • Jay Tee (unregistered) in reply to Tim Gallagher

    Regardless of whether you actually *want* their opinions, PHP template "engines" have left a bad taste for the most part.  The problem is bulkiness.

    The smarty engine is gigantic and does this massive search and replace thing - at least that's how it was when I first looked at it.

    The engine you're speaking of lends itself to be more efficient - and we all continue to struggle in trying to figure out how to implement an efficient MVC model in PHP

    The DB classes seem to work, the controllers are pretty straightforward - but how to I get the f*#$ing View to work right?  Well...we're stuck with some sort of variable substitution/template engine, aren't we?

     
    captcha: stfu - I think it's talking to me


     

  • (cs) in reply to Dragnslcr
    Dragnslcr:

    Apparently nobody has figured out the Real WTF (TM) in the second snippet.

    http://www.php.net/str_repeat

    Those who don't know the language's built-in functions are doomed to re-implement them poorly.

    I so desperately wanted someone to figure out the str_repeat solution without my telling them. The original submitter pointed that out, but I enjoy the discussions too much to just give free solutions out! Way to go.

  • mariush (unregistered)

    if ($hour>=7 and $hour<18)

    { # Biff or Cliff

    $Owner->LoadById(iif (rand()>0.5) ? '70656' : '72586');

    }

     

    This should do it...     

  • mariush (unregistered) in reply to mariush

    Sorry, please ignore the iif ... reminiscences of my past experience with VB ...

  • wayne (unregistered) in reply to Jay Tee
    Anonymous:

    Regardless of whether you actually *want* their opinions, PHP template "engines" have left a bad taste for the most part.  The problem is bulkiness.

    The smarty engine is gigantic and does this massive search and replace thing - at least that's how it was when I first looked at it.

    I guess you should have a second look at Smarty if working with php. It does the massive search/replace stuff just once (if you're not explicitly telling to do it every time, e.g. for debugging). The result is cached as plain old php, which is doubtless the best for performance, and no search/replace has to be done from that first time on. Of course there's still some overhead, but that's reasonable.

  • (cs) in reply to UncleMidriff

    UncleMidriff:
    Is there any reason to be randomly assigning tickets?  It could very well happen, even with a perfectly random ticket assigning process, that, out of 100 tickets, Person #1 could get 1 ticket, Person #2 could get 5 tickets, and Person #3 could get 94 tickets.  That'd be unlikely, I suppose, but it could happen.  Ideally, shouldn't such a system, upon receiving a new ticket to assign, check to see who has how many tickets, and then assign the new ticket to the guy with the fewest tickets already?  I've never worked on a ticketing system before, so I'm speaking out of ignorance here, but it seems to me that randomly assigning tickets is an odd way to go about things.

    You make some valid points.  The answer is "It depends."

    First, checking how many tickets are in queue for each salesperson might be an expensive proposition.  A random dispersement over a reasonable time period should give everyone roughly the same number of tickets to work.

    Second, the compensation plan must be taken into account.  If the salespeople are paid on the ticket, then your system would benefit the person who processed the tickets as quickly as possible.  That might lead to shoddy work.  A random dispersement scheme doesn't reward a salesperson for being quick, potentially encouraging that salesperson to be thorough.

    In the end, random distribution of tickets can't be considered a WTF without knowing a lot more about the company.

  • usestrict (unregistered) in reply to mariush

    you can patch the rand() example quite easily (assuming it is Perl):

     

    use Memoize;

    memoize('rand'); 

     

     

  • radiantmatrix (unregistered) in reply to Vector
    Vector:

    Good haul for a CodeSOD. :) As for the random allocation...

    if ( ($hour >= 7) && ($hour <= 18) )
    {
        $id = ( rand() > 0.5 ) ? 70656 : 72586;
        $Owner->LoadByID( $id );
    }

    Done. 

    Nice use of the ternary, but why store the result?

    if ( ($hour >= 7) && ($hour <= 18) ) { $Owner->LoadByID( rand() > 0.5 ? 70656 : 72586 }
     

  • radiantmatrix (unregistered) in reply to Vector
    Vector:

    Good haul for a CodeSOD. :) As for the random allocation...

    if ( ($hour >= 7) && ($hour <= 18) )
    {
        $id = ( rand() > 0.5 ) ? 70656 : 72586;
        $Owner->LoadByID( $id );
    }

    Done. 

    Nice use of the ternary, but why store the result?

    if ( ($hour >= 7) && ($hour <= 18) ) { $Owner->LoadByID( rand() > 0.5 ? 70656 : 72586) }
     

  • doc0tis (unregistered) in reply to Ahox

    Anonymous wrote the following post at 11-20-2006 4:34 AM:

    				</p><blockquote><div><img src="/Themes/default/images/icon-quote.gif" /> <strong>Anonymous:</strong></div><div><blockquote><div><img src="/Themes/default/images/icon-quote.gif" /> <strong>Anonymous:</strong></div><div><p>The thrid one it is posible that both will get it the job and even sometimes nun of the them would get the job.<br /></p></div></blockquote><br />&nbsp;<p>No, it&#39;s two calls to rand.</p><p>&nbsp;There&#39;s a 50% chance that 70656 gets the ticket.</p><p>&nbsp;Of the other tickets, there&#39;s a 50% chance that 72586 gets it.</p><p>All other tickets are left unassigned.</p></div></blockquote>
    

     

    Actually no,

    there is a 25% chance for 70656 and a 50% chance for the second and in a quarter of all cases no one gets it.

     

    Actually there are four equally likely options

    1. Person 1 gets the ticket, only
    2. Person 2 gets the ticket, only
    3. Person 1 and Person 2 get the ticket
    4. The nun get's the ticket
    --doc0tis

     

  • (cs) in reply to Grimoire
    Grimoire:
    emurphy:

    I suppose

    use define SALESPERSON1_ID => 70656; # Biff
    use define SALESPERSON2_ID => 72586; # Cliff

    is considered too obvious to bother pointing out explicitly?

    I would do:

    use define BILL_ID => 70656;
    use define CLIFF_ID => 72586;

    More explicit, you don't have to look up the definition of the salesperson to see who it is, and you can save yourself the comments. 

    And the #1 reason not to do that? Why are you assigning Biff's ID to Bill?

    The #2 reason? What are you going to do when Cliff gets fired because he always has more open tickets than Biff?

  • Mladen Gogala (unregistered) in reply to Tim Gallagher

    Your templating article is nice, but the whole thing is exceptionally funny because of the actual code which is,

    I dare say, less then brilliant. The "br" function could acutally be rewritten as $ret=str_pad("",$count,"\n");  but that

    wouldn't be eligible for the Daily WTF. 

  • Matt (unregistered) in reply to Anonymous Coward
    Anonymous:

    There's one other issue, however--calling rand() that close together, it's likely that a lot of implementations are going to return the exact same value if rand isn't seeded correctly or if the implementation of rand relies on something like the system timer.  For example, many rand implementations rely on tick count values as a seed.  However, if two calls to rand are adjacent, and there is no seed between them, the likelyhood of them occuring on the same tickcount is pretty damn high.

    You're very confused. If you DO seed the RNG with a timer value twice in a row, then you might get the same value twice. They way it is supposed to work is that you seed it once and forget about it. Each new number is generated by a formula loosely based on the previous one. You won't get two numbers the same twice in a row, 99.9999....% of the time. 

    Further, no implementations of rand rely on the timer for each value. If the timer is used, it is only used as a source of supposedly random data for the initial seeding. "Seed" means exactly what it sounds like. It's used once to start the thing off, that's all.

    Try writing a program that just calls rand over and over , and then output the results. 

  • grimlock (unregistered) in reply to wayne
    Anonymous:
    Anonymous:

    Regardless of whether you actually *want* their opinions, PHP template "engines" have left a bad taste for the most part.  The problem is bulkiness.

    The smarty engine is gigantic and does this massive search and replace thing - at least that's how it was when I first looked at it.

    I guess you should have a second look at Smarty if working with php. It does the massive search/replace stuff just once (if you're not explicitly telling to do it every time, e.g. for debugging). The result is cached as plain old php, which is doubtless the best for performance, and no search/replace has to be done from that first time on. Of course there's still some overhead, but that's reasonable.

    We use Smarty to cover all our templating needs. Main reasons are:

    1. Being maintained by third party (smarty folk) which saves us a lot of developer cycles
    2. Its cheaper to buy hardware then to spend time on coding some 'homegrown-wtf-templating' engine
    3. Custom Smarty plugins are sexy
    4. Smarty + Op-code Cache = fast fast fast
    5. XSLT is teh suck (try teaching your junior devs XML + XSL/XSLT/Xpath the 'correct' way)

    Only gripe I have with Smarty is the learning curve. It takes a bit getting used to, but what system doesn't. The XSLT curve is _a_lot_ steeper then Smarty's. Oh and the not-so-small Yahoo uses smarty too, so I'd say its pretty 'production' stable.

  • Rich (unregistered) in reply to mariush
    Anonymous:

    if ($hour>=7 and $hour<18)

    { # Biff or Cliff

    $Owner->LoadById(iif (rand()>0.5) ? '70656' : '72586');

    }

     

    This should do it...     

     

    Naaaahhhh.

    $Owner->LoadById(70656+1930*floor(rand()*2));

    Innit. 

    Rich 

  • (cs) in reply to Alex Brick

    Anonymous:
    why is it that no-one (that I saw) even mentioned the "if ($hour>=7 and $hour<18) {" bit ... if the hour is not in this range, then no-one gets it...

    Because the lead-in states that the tickets are randomly assigned "during the business hours".

  • Olddog (unregistered) in reply to Rich
    Anonymous:
    Anonymous:

    if ($hour>=7 and $hour<18)

    { # Biff or Cliff

    $Owner->LoadById(iif (rand()>0.5) ? '70656' : '72586');

    }

     

    This should do it...     

     

    Naaaahhhh.

    $Owner->LoadById(70656+1930*floor(rand()*2));

    Innit. 

    Rich 

    Ouch.  What if they hire a third employee?

  • Nicholas (unregistered) in reply to Anonymous
    Anonymous:
    Anonymous:
    There's a 50% chance that 70656 gets the ticket.

     

     Of the other tickets, there's a 50% chance that 72586 gets it.

     

    All other tickets are left unassigned.

    That would be the case if it was an if/else-if pair. However, it's two if's, so what you said there is incorrect. There's a 50% chance the first guy gets the ticket, and there's a 50% chance the second guy gets the ticket. Hence, altogether, there's a 25% chance that both of them claim the ticket, 25% that neither, and a 50% chance that only one of them will claim the ticket.

    GAH it's not 50%! there's a chance it might equal exactly 0.5, so in both cases it is just below 50%. Anyway, I think we can all agree that sometimes one will get it, sometimes they will both get it, and on other occasions nobody will get the ticket.

  • Spam Sucks (unregistered)

    TRWTF is 2 pages of spam

  • jordanwb (unregistered)

    Oh man that last one is just plain awful.

Leave a comment on “Triple Play”

Log In or post as a guest

Replying to comment #:

« Return to Article