The ending never-ending loop



  • Probably you've seen this in more than one variation, but I liked this one.

    double a = 1;
    for(double b=0;b < a; b++)
    {
    a++;
    }

    What o what goes wrong here?



  •  It's not quite a never-ending loop. Once a gets above about 2^53 the increment won't change it, so b will catch up.



  • This has been Photoshopped. 



  •  



  • TRWTF is using floats for a loop counter in the first place.


  • :belt_onion:

    @morbiuswilters said:

    This has been Photoshopped. 

    Now that you mention it.... the blue color on the sleeve of your avatar doesn't seem to match with the color of the vest...


  • Shriley the loop will never be used since b starts off as < a. Or am I missing some in joke?


  • Discourse touched me in a no-no place

    @NeoMojo said:

    Shriley the loop will never be used since b starts off as < a.
    Programming 101 - the loop continues while the condition is true, not false. If it helps, here it is as a while loop:

     

    double a = 1;
    double b = 0;
    while(b < a){
    a++;
        b++;
    }

     



  •  oh, yeah, hence ending never-ending loop



  • @NeoMojo said:

    Shriley the loop will never be used since b starts off as < a. Or am I missing some in joke?

    You're missing something far, far worse: an understanding of basic for loops.

  • Discourse touched me in a no-no place

    @NeoMojo said:

    oh, yeah, hence ending never-ending loop
    In theory.

    As pointed out previously, in reality, since they're floats, there'll come a time when the limitatation of the floating point format means that the number is large enough that adding one won't actually change the value, so a will equal b. (Alternatively, with integers, a will roll round just before b, making b > a.)



  • And as floating point calculations differ from machine to machine it fill the requirements.



    It delays execution depending on the running machine.



  • @bstorer said:

    @NeoMojo said:

    Shriley the loop will never be used since b starts off as < a. Or am I missing some in joke?

    You're missing something far, far worse: an understanding of basic for loops.
    Awesome. After Visual Basic for Applications Micosoft has finally released Visual Basic for Loops. The perfect tool to let highly-paid consultants play without giving them a chance to do any real damage. All-new ability to store your loops in an Access database! Order today.


  • @NeoMojo said:

    Shriley the loop will never be used since b starts off as < a. Or am I missing some in joke?


    TRWTF is that you don't know how to properly misspell "surely".



  • @A Wizard A True Star said:

    TRWTF is that you don't know how to properly misspell "surely".
    Are you trolling or are you not getting the reference?




  •  Please provide a non You-Tube link so that I may view all of the Shriley goodness at work.

     

    Thank you,

    The Management



  • @A Wizard A True Star said:

    @NeoMojo said:

    Shriley the loop will never be used since b starts off as < a. Or am I missing some in joke?

    TRWTF is that you don't know how to properly misspell "surely".
    Maybe he meant "shrilly," as in "the loop will never be used in a shrill manner."  Of course, I have absolutely no idea what that means.

  • Discourse touched me in a no-no place

    @Zecc said:

    @A Wizard A True Star said:
    TRWTF is that you don't know how to properly misspell "surely".
    Are you trolling or are you not getting the reference?

    Did you not notice the OP incorrectly misspelt surely, Shriley, instead of Shirley?



  • @PJH said:

    @Zecc said:
    @A Wizard A True Star said:
    TRWTF is that you don't know how to properly misspell "surely".
    Are you trolling or are you not getting the reference?

    Did you not notice the OP incorrectly misspelt surely, Shriley, instead of Shirley?

    I completely misread and subsequently misunderstood A.W.A.T.S.' comment.

    I apologize and retreat in shame. 



  •  @amischiefr said:

    Please provide a non You-Tube link so that I may view all of the Shriley goodness at work.

    Thank you,
    The Management

    Ted Striker: Surely you can't be serious.

    Rumack:
    I am serious... and don't call me Shirley.

    --Airplane! (1980)



  • @PJH said:

    @NeoMojo said:

    oh, yeah, hence ending never-ending loop
    In theory.

    As pointed out previously, in reality, since they're floats, there'll come a time when the limitatation of the floating point format means that the number is large enough that adding one won't actually change the value, so a will equal b

    Hence, *ending* never-eding loops.  A "never-ending" loop which ends.  A finite "infinite loop". Or just a really slow busy loop.

     



  •  If the loop survives this iteration, you will still be parted. If a is defeated, and b made king and the conditions that you checked for become false, it will still have to taste the bitterness of mortality. Whether by the incrementing or the slow decay of silicon, the loop will terminate. And there will be no comfort for you. No comfort to ease the pain of its passing. It will come to completion, an image of the splendor of loops of Java in glory undimmed before the surpassing of Double.MAX_VALUE. But you, my intel x86 processor, you will linger on in solitude, as a GUI in .NET that comes without a DataGridView.ColumnHeaderMouseClick event. Here you will dwell, bound to your objectDataSource1, under the fading menus, until all the Form is changed and the long cycles of your life are utterly spent. Pentium, there is nothing for you here... only termination of loops.



  •  you sir, are the true master of BS.



  •  @PJH said:

    @NeoMojo said:

    oh, yeah, hence ending never-ending loop
    In theory.

    As pointed out previously, in reality, since they're floats, there'll come a time when the limitatation of the floating point format means that the number is large enough that adding one won't actually change the value, so a will equal b. (Alternatively, with integers, a will roll round just before b, making b > a.)

     Interesting note:  I coded this up and set it up to run overnight on my work machine.  16 hours later, and:

     1)  The Console version is still going, currently at 3770983985 < 3770983986

     2) The logged version (really just CrazyLoop.exe > file1.txt) crashed when file1 took up too much of the hard disk (18,609,824,752 bytes).

    Fun!



  • @TwelveBaud said:

    Ted Striker: Surely you can't be serious.

    Rumack:
    I am serious... and don't call me Shirley.

    --Airplane! (1980)

     

    Ahh yes, a classic.  



  • @halcyon1234 said:

    Interesting note:  I coded this up and set it up to run overnight on my work machine.  16 hours later, and:

     1)  The Console version is still going, currently at 3770983985 < 3770983986

     

    Its clearly a matter of processing power...

    We should write an official tdwtf screensaver which processes the given loop in a distributed environment (simply copying SETI screensaver will do) ...

    If we could use the GPUs as well, it would even double the performance ... 



  • @Nelle said:

    @halcyon1234 said:
    Interesting note:  I coded this up and set it up to run overnight on my work machine.  16 hours later, and:

     1)  The Console version is still going, currently at 3770983985 < 3770983986

    Its clearly a matter of processing power...

    We should write an official tdwtf screensaver which processes the given loop in a distributed environment (simply copying SETI screensaver will do) ...

    If we could use the GPUs as well, it would even double the performance ...

    Sweet, TDWTF@Home.

    Plz send me teh codez.



  • @halcyon1234 said:

     @PJH said:

    @NeoMojo said:

    oh, yeah, hence ending never-ending loop
    In theory.

    As pointed out previously, in reality, since they're floats, there'll come a time when the limitatation of the floating point format means that the number is large enough that adding one won't actually change the value, so a will equal b. (Alternatively, with integers, a will roll round just before b, making b > a.)

     Interesting note:  I coded this up and set it up to run overnight on my work machine.  16 hours later, and:

     1)  The Console version is still going, currently at 3770983985 < 3770983986

     2) The logged version (really just CrazyLoop.exe > file1.txt) crashed when file1 took up too much of the hard disk (18,609,824,752 bytes).

    Fun!

     

    You're spending too much time outputting numbers. The cost of converting the double to a decimal representation in ASCII and outputting it to stdout is running way past the cost of a simple floating-point add. Try this, see if it works faster:

    #include <stdio.h>

    int main(int argc, char *argv[]) {

    double a = 1, b = 0;

    for (; b < a; b++) a++;

    printf("%f", a);

    }

     

    [i]*Note: There is a 30% chance that I am entirely, woefully wrong here. Should this be the case, feel free to mock me mercilessly.[/i]


  • Discourse touched me in a no-no place

    @TopCod3rsBottom said:

    @PJH said:

    @NeoMojo said:

    oh, yeah, hence ending never-ending loop
    In theory.

    As pointed out previously, in reality, since they're floats, there'll come a time when the limitatation of the floating point format means that the number is large enough that adding one won't actually change the value, so a will equal b

    Hence, *ending* never-eding loops.  A "never-ending" loop which ends.  A finite "infinite loop". Or just a really slow busy loop.

    Well since the post that prompted that/my reply had a distinct lack of understanding of what a for loop in most languages does, I thought it prudent to clarify any other potential misunderstandings about the subject/1st OP to the post I was replying to.

    Feel free to boost your ego by pointing out another error in this post. Otherwise STFU.



  • Gaah, edit timeout. Here's what I meant to post:

    #include <stdio.h>
    
    int main(int argc, char **argv) {
        double a = 1, b = 0;
        for (; b < a; b++) {
            a++;
        }
        printf("%f", a);
        return 0;
    }
    

    Running something similar (with a signal handler added to print the numbers) on my laptop reached the number reached by halcyon in about 3 minutes.


Log in to reply