

The never-ending finite loop - cperciva
http://www.daemonology.net/blog/2010-08-02-neverending-finite-loop.html

======
tkeller
I was kind of disappointed in this article. He starts off with "It's easy to
write a loop which looks infinite but in fact completes quite quickly..."
which makes it sound like he's going to write a loop that looks finite but in
fact spins forever (maybe because of some trick like the integer overflow he
uses at the beginning). That would have been interesting.

This is just trying to write a short program that'll run for a long time. Meh.

------
SamReidHughes
Here's a 43-character solution.

    
    
        for(int x[99]={1};!x[98];++*x)*x*=!++x[*x];

~~~
SamReidHughes
Aha! 42 characters!

    
    
        for(int x[99]={1};++x[++*x]?*x=1:!x[98];);

~~~
SamReidHughes
Aah! 40 characters!

    
    
        for(int x[99]={98};++x[*x]?*x=98:--*x;);

~~~
SamReidHughes
Sigh. 39 characters!

    
    
        for(int x[99]={1};++x[*x]?*x=98:--*x;);

------
nollidge
As someone points out in the comments, isn't this true of any NP-complete
problem with large enough inputs? This isn't all that surprising then.

~~~
sukuriant
As a side note, you're partly assuming in that statement that P != NP, which
is yet to be determined in either direction.

~~~
sqrt17
He's not. Any program code written today that solves an NP-hard problem
without exploiting special properties of the input data will take exponential
time. If we discover a smart way to do NP-hard problems in polynomial time,
we'll have a better solution for the problem, but the old program code will
stay the same.

If you want an analogy: sorting an array is clearly a task that can be solved
in O(n log n) time, but if you write a bubble sort implementation (or any
other O(n^2) algorithm), the program will still take O(n^2) time.

~~~
SamReidHughes
_Any program code written today that solves an NP-hard problem without
exploiting special properties of the input data will take exponential time. If
we discover a smart way to do NP-hard problems in polynomial time, we'll have
a better solution for the problem, but the old program code will stay the
same._

You could write a program that runs in polynomial time, but be unable to prove
that it does. Then, later, you could find a proof that the program runs in
polynomial time. In fact, if P=NP, you can write such a program right now:

    
    
        for each string s in the enumeration of all strings {
          if (s = p + q where
              (p is a program and
               q is a proof that p solves 3SAT in polynomial time)) {
            run p on the input;
            return;
          }
        }
    

Also, you could interleave the execution of this program with one that solves
3SAT in exponential time. Then you'll have a program that works in any case,
and that solves 3SAT in polynomial time if P = NP.

------
btilly
I think you can save 2 characters. Here is the original

    
    
      char i,x[99];for(x[98]=i=1;x[98];i++)i*=!++x[i];
    

Here is my improved version

    
    
      int i,x[99];for(x[98]=i=1;x[98];)i*=!++x[i++];

~~~
nburger
And you could save an additional character by changing the loop test to a+b
form, i.e.:

int i,x[99];for(x[98]=i=1;x+98;)i*=!++x[i++];

The other array references are l-values.

~~~
gjm11
That would need to be *(x+98), which is longer than x[98].

~~~
nburger
Ahh.. you're right, of course. What I wrote has an undefined termination
condition, besides not being consistent with the original algo. Thanks.

------
jpablo
Not very interesting post. I could think of teens of problems out of the top
of my head that are theoretically finite but there's no enough mass/energy in
the universe for them to complete (like generating a program that solves
chess).

His first example of "for (int i = 1; i > 0; i++);" Would be matched by some
ugly trick like:

int i = 0; while (!i);

That's warranted to halt as the chances for a bit in i to be flipped by cosmic
rays tends to be 1 over time.

~~~
gjm11
The "first example" is merely a preliminary; it _isn't_ an example of what
he's actually trying to do. He's trying to write a _very short_ program that
(1) is valid C, (2) would terminate eventually on a system that perfectly
implements C semantics and can run as long as it wants, but (3) would take so
long to do so that no physically realisable system within the observable
universe could enable it to run to completion.

You are of course welcome to find this uninteresting, but "I can think of lots
of big complicated programs that would terminate but not do so for a very long
time" and "In the real world, an infinite loop may terminate because of a
hardware malfunction" don't seem to me like good reasons for finding it
uninteresting.

------
Andys
How long would it take, exactly, to increment a uint128 until it overflows?

