8
\$\begingroup\$

Not a dupe to this. That question asks specifically for counting up forever, while this question allows many other approaches.

Write a program or function which, given infinite time and memory, would print an infinite non-periodic output.

Clarifications

  • 'Infinite' means the solution keeps outputting something without any further inputs or operations after successfully started the program or function.
  • 'Non-periodic' means the output has no possibility of eventually repeating the same section forever (regardless of how long that period is). An example of a valid solution would be printing the digits of an irrational number.
  • Random solutions would not count unless you can prove that it fits the requirements. Date/time-based solutions may also be invalid if they are not stored with arbitrary precision.

Winner

Shortest code (in bytes) wins.

\$\endgroup\$
  • 1
    \$\begingroup\$ Regarding non-cyclic, is 1\n12\n123 invalid? \$\endgroup\$ – ATaco Feb 27 '17 at 7:38
  • 4
    \$\begingroup\$ Not a dupe. Though one method is to count up forever, the question here is to output a unique number forever, not specifically counting up forever. How people answer question isn't exactly the question. \$\endgroup\$ – Matthew Roh Feb 27 '17 at 8:33
  • \$\begingroup\$ @no1xsyzy I voted to reopen your question. \$\endgroup\$ – Julian Lachniet Feb 27 '17 at 11:51
  • \$\begingroup\$ I edited your post for clarity. Feel free to undo any changes you don't agree with. \$\endgroup\$ – Martin Ender Feb 27 '17 at 16:58
  • \$\begingroup\$ So, is infinite precision required or not? It's not made super clear in the question. \$\endgroup\$ – mbomb007 Feb 27 '17 at 19:32

40 Answers 40

12
\$\begingroup\$

Hexagony, 2 bytes

(!

Try it online!

The unfolded source code looks like:

 ( !
. . .
 . .

This just runs these two commands in a loop, which are decrement (() and print (!). Hence, the output is:

-1-2-3-4-5-6-7-8-9-10-11-12...

We need to use decrement instead of increment to ensure that the program loops back to the first line (if the memory value was positive, Hexagony would loop between then second and third line, and end up in an infinite loop without doing anything).

\$\endgroup\$
  • 1
    \$\begingroup\$ What happens when Hexagony reaches its smallest representable integer? \$\endgroup\$ – Adám Feb 28 '17 at 7:24
  • 1
    \$\begingroup\$ @Adám Hexagony uses arbitrary-precision integers. \$\endgroup\$ – Martin Ender Feb 28 '17 at 7:24
9
\$\begingroup\$

Python 2, 23 bytes

while 1:print id;id=id,

Try it online!

Prints

<built-in function id>
(<built-in function id>,)
((<built-in function id>,),)
(((<built-in function id>,),),)
((((<built-in function id>,),),),)

and so on. Starts with the built-in function id, the shortest pre-initialized variable name, and repeatedly turns it into a tuple of itself.

In Python 3, this solution is one byte longer because of print(), but the byte can be recovered from print outputting None:

while 1:id=print(id),id

or

while[print(id)]:id=id,
\$\endgroup\$
5
\$\begingroup\$

Labyrinth, 3 bytes

#:!

Try it online!

Prints all non-negative even integers without separator:

024681012141618202224262830323436384042...

The IP bounces back and forth on the code, so this is really #:!: in a loop:

#  Push stack depth.
:  Duplicate.
!  Print.
:  Duplicate.

A bunch of alternatives:

:#!     Prints all positive odd integers.
:)!     Prints all positive integers.
):!     Prints all positive integers.
:(!     Prints all negative integers.
(:!     Prints all negative integers.
\$\endgroup\$
5
\$\begingroup\$

Brachylog, 2 bytes

ẉ⊥

Try it online!

This prints all integers ordered by magnitude. This will never overflow and print already seen integers since Brachylog uses unbounded integers by default.

Explanation

ẉ      Writeln: the Input is anything, so we label it implicitely to an integer and write it
 ⊥     False: backtrack and try another integer value for the Input
\$\endgroup\$
2
\$\begingroup\$

><>, 3 bytes

l:n

Outputs a stream of numbers, counting from 0.

I believe incrementing numbers don't cycle...

Explanation:

l pushes stack length onto stack

: duplicates top stack value on top of stack

n outputs value as number

When the line is finished it goes back to the beginning, so it does it again, but now the stack is longer...

online

\$\endgroup\$
2
\$\begingroup\$

PHP, 20 bytes

for(;;)echo$argc.=0;

Outputs this:

101001000100001000001000000100000001000000001000000000...

If command line arguments are provided, the output will be different, but still non-periodic.

As far as I understand the documentation, the language itself doesn't restrict length of strings.

\$\endgroup\$
2
\$\begingroup\$

JavaScript, 26 22 20 bytes

for(;;)alert(Date())

(Warning: it's evil)

\$\endgroup\$
  • 1
    \$\begingroup\$ I would recommend making it so that this code so that it doesn't have the run option. \$\endgroup\$ – fəˈnɛtɪk Feb 27 '17 at 12:55
  • \$\begingroup\$ You can get rid of both the first and last semicolons: for(n=0;;)alert(n++) \$\endgroup\$ – Arnauld Feb 27 '17 at 13:16
  • 3
    \$\begingroup\$ @Ahemone It won't overflow but it will eventually get stuck forever at 2^53 = 9007199254740992. \$\endgroup\$ – Arnauld Feb 27 '17 at 14:23
  • 5
    \$\begingroup\$ @Arnauld So this answer is not non-periodic... \$\endgroup\$ – kennytm Feb 28 '17 at 5:21
  • 2
    \$\begingroup\$ You could just do for(;;)alert(Date()) for 20 bytes. \$\endgroup\$ – ETHproductions Feb 28 '17 at 19:38
2
\$\begingroup\$

Haskell - 10 bytes

print[1..] 

Although in ghci you could just type [1..] and that would automatically start printing.

\$\endgroup\$
2
\$\begingroup\$

Brainfuck, 13 Bytes, assuming no upperbound but output mod 256

+[[->+++.<]>]

output char code 2 2 4 6 2 4 6 8 10 12 14 16 18 ...

sorry that the old code print loop 0 2 4 6 ... 254,

Brainfuck, 13 12 Bytes (-1 from Jo King)

+[[>.]<[<]+]

output char code 0 1 0 1 1 0 1 1 1 0 ...

\$\endgroup\$
  • \$\begingroup\$ Why not combine the [.>]. into [>.]? +[[>.]<[<]+] prints 010110111011110... \$\endgroup\$ – Jo King Dec 27 '17 at 9:06
  • \$\begingroup\$ Thanks \$\endgroup\$ – l4m2 Dec 27 '17 at 9:08
  • \$\begingroup\$ Do you have an interpreter that meets the specifications required to make this non-periodic? \$\endgroup\$ – Wheat Wizard Dec 27 '17 at 9:09
  • \$\begingroup\$ esoteric.sange.fi/brainfuck/impl/interp/i.html with code +[[>.]<[<],] and fill input bar with '\1' \$\endgroup\$ – l4m2 Dec 27 '17 at 9:13
  • \$\begingroup\$ @WheatWizard I don't know about the first one, but for the second TIO will show a square for 1 and a blank space for 0 \$\endgroup\$ – Jo King Dec 27 '17 at 10:27
1
\$\begingroup\$

Jelly, 3 bytes

‘Ȯß

Try it online! - truncates the output and raises an error, but will go far longer locally (until memory runs out).

With an implicit input of zero this program consists of a single link which increments, , prints Ȯ, and then calls itself with the new value, ß.

\$\endgroup\$
1
\$\begingroup\$

MATL, 4 bytes

`@tD

This solution creates a while loop which pushes the index of the loop to the stack, duplicates it, prints the value and then checks that the loop index is non-zero to repeat again.

Try it Online!

\$\endgroup\$
1
\$\begingroup\$

RProgN 2, 13 bytes

2{22.`2=2p2}:

There are many twos in the output, separated by progressively more sparce newlines.

2{22.`2=2p2}:
2               # Push a two to the stack
 {         }:   # While the top of the stack is truthy
  22.           # Push the value of "2" twice, and concatenate them together.
     `2=        # Set the value of "2" to this.
        2p      # Print the value of "2"
          2     # And push the value of "2"

Which prints 2^n 2s followed by a newline for each iteration.

Try it online!

\$\endgroup\$
  • \$\begingroup\$ I remember you saying Stacked was too verbose? ;) \$\endgroup\$ – Conor O'Brien Feb 28 '17 at 4:04
1
\$\begingroup\$

Befunge, 4 bytes

1+:.

Try it online!

In Befunge, the stack is bottomless and has infinite zeros. That said:

1+ adds one to the top of the stack

: duplicates the top of the stack

. prints the ascii value of the top of the stack as a number

And it continues infinitely, because there's no @ to stop execution. This is actually one of those problems made easier to solve by the way befunge works... weird.

\$\endgroup\$
  • 1
    \$\begingroup\$ Is there a Befunge interpreter that uses arbitrary-precision integers? \$\endgroup\$ – Martin Ender Feb 28 '17 at 7:29
  • 1
    \$\begingroup\$ @MartinEnder Although not strictly spec compliant, I'm fairly sure both Befungee and PyFunge use arbitrary precision integers for their stack cells. \$\endgroup\$ – James Holderness Feb 28 '17 at 23:08
  • \$\begingroup\$ @MartinEnder I'm sorry, I should've noted that in the original response. I think Pyfunge uses arbitrary precision integers, but I'll make sure of it when I get back home \$\endgroup\$ – osuka_ Feb 28 '17 at 23:29
1
\$\begingroup\$

APL (Dyalog APL), 8 bytes

{∇⎕←0⍵}1

{emsp;an anonymous function...

 recurse on

⎕ ← output to STDOUT

0 ⍵ the two element list consisting of a zero and the argument

} applied to the number one

This outputs (on separate lines) [0,1], [0,[0,1]], [0,[0,[0,1]]], etc.

\$\endgroup\$
1
\$\begingroup\$

Processing, 30 29 bytes

1 byte saved thanks to QwerpDerp for using millis() instead of frameRate

void draw(){print(millis());}

Continuously prints the number of milliseconds since the start of the program.

Sample output:

3573743914054244404574734925085205375585755916...
\$\endgroup\$
1
\$\begingroup\$

C (gcc), 83 81 bytes

*p,*t,*g;f(){for(t=p=malloc(1),g=--t;t<p?putchar(55):(t=g,*p++,putchar(9));t++);}

First allocating a pointer on the heap, the function then counts off into the memory addresses ahead until a segfault from *p++, therefore is limited by the amount of memory in the system rather than the data types used which would otherwise eventually overflow and repeat the series. Given infinite memory with infinite addressing capability it would go on forever.

Try it online!

\$\endgroup\$
  • \$\begingroup\$ Saw "Answered 1 min ago by Ahemone", and was excited because I instantly knew it was a C answer! \$\endgroup\$ – Albert Renshaw Feb 28 '17 at 7:09
  • \$\begingroup\$ @AlbertRenshaw I'm glad you enjoy them. I've just realised though, I should be dereferencing the p++ to make my claim. \$\endgroup\$ – Ahemone Feb 28 '17 at 9:08
  • \$\begingroup\$ 65 bytes \$\endgroup\$ – ceilingcat Nov 13 at 3:17
1
\$\begingroup\$

7, 2 bytes

The characters that make up this program are:

240223

When viewing the file in an editor, it'll likely try to interpret it as ASCII, in which case it looks like this:

P$

Try it online!

The program takes input. I've assumed here that the input is at EOF; if you provide it input, it's possible it will crash.

Explanation

Zeroth iteration

240223
240223  Append 240223 to the top stack element

The entire program here is passive, so it'll append an active version of itself to the top stack element (which is initially empty). The program's in an implicit loop, which evaluates the top stack element (while leaving it on the stack) every iteration. So the active version will run. (Pretty much all 7 programs start like this.)

First iteration

240223
2       Copy the top stack element
 40     Escape the second stack element, swapping it to the top
   2    Copy the top stack element
    23  Output the top stack element

Before the output command, the stack contains two copies of 240223 (i.e. passive). The top one gets output (with no observable effect other than selecting output format 2, "numbers"), the one below stays and becomes the program for the next iteration.

Second iteration

240223
240223  Append 240223 to the top stack element

The same as the zeroth iteration, right? Not quite; the stack had different contents. The stack is now 240223 below 240223240223.

Third iteration

240223240223
240223        Append 240223 to the top stack element
      2       Copy the top stack element
       40     Escape the second stack element, swapping it to the top
         2    Copy the top stack element
          23  Output the top stack element

This outputs a stack element that has three more 6s-and-0s than it does 7s-and-1s. Output format 2 interprets this as a request to input a number. We read EOF, with the consequence that the next element on the stack is reduced to a zero-length string. However, due to a bug (which seems mildly useful and may be promoted to a feature?), this only happens after it starts executing. The stack once again has two elements, 240223 below 240223240223240223, but the escaped version of this top element, 72402236240223240223, is now executing.

Fourth iteration

72402236240223240223
72402236240223240223  Append 240223240223240223 to the top of stack

The top of stack was a zero-length string, so we're basically just unescaping the program that ended up there.

Fifth iteration

240223240223240223
240223              Append 240223 to the top stack element
      2             Copy the top stack element
       40           Escape the second stack element, swapping it to the top
         2          Copy the top stack element
          23        Output the top stack element
      2       Copy the top stack element
       40     Escape the second stack element, swapping it to the top
         2    Copy the top stack element
          23  Output the top stack element

This is very similar to the third iteration. There are two changes, though. First, there are now 4 more 0s-and-6s than there are 1s-and-7s, so we'll try to input a character from standard input rather than a number. We still get EOF, though, and still end up reducing the top of stack to a zero-length string as a result. Next, there's code running after the reduction, so the next iteration doesn't start immediately. Rather, we do a bunch of operations on that zero-length element, ending up with three zero-length elements. We output one, the other two disappear (because it's the end of an iteration), and we end up basically where we were at the end of the third iteration.

Sixth iteration

The program we copy from the top of stack is now 240223240223240223240223. Everything works like in the previous iteration until we reach the first output instruction (the first 23). This now has five more 0s-and-6s than there are 1s-and-7s, so it sets a mode in which the next output instruction will be interpretted as a request to change the output format. This also leads to a notable change in behaviour; as there was no input request, we didn't read EOF, and thus didn't trigger the consequence of reading EOF (the new top stack element being blanked), and as such the escaped version of the original stack element stays rather than being removed. This means that the next 2402 is no longer a no-op, creating two escaped copies of the escaped stack element (i.e. they're now double-escaped). We output one, setting the output format to 7 ("same as the input"); this output format has no I/O commands, and no commands to change the format, so we'll stay in it for the rest of the program. We also output 724022362402232402232402232402236 (in the same encoding as the input) to standard output.

Anyway, it's fairly clear what the program's going to be doing from this point onwards: it's a combination of appending various number of copies of variously escaped 240223 to the top of the stack, escaping the top of the stack, and outputting copies of the top of the stack. From this point onwards, the top stack element is never cleared (because we never read EOF), so it just grows and grows and grows. The periodic escaping ensures that the output never repeats (because it means that each iteration, the first output starts with at least one more 7 than it did on the previous iteration).

\$\endgroup\$
1
\$\begingroup\$

Ohm, 4 bytes (CP437)

¼,¡∞

Prints the counter variable, increments it, and goes into an infinite loop! Simple enough.

EDIT (Mar 1 '17): While I was in the process of doing some other updates (after I posted this answer), I changed the behavior of . The updated answer would be ∞^,.

\$\endgroup\$
1
\$\begingroup\$

"modern" DC, 9 bytes

Infinite memory?
Then a continuously growing stack is ok?
]:-)

[zprdx]dx

Commented:

[         # start string constant
 z        #   push current stack depth
  p       #   print TOS without removing
   r      #   swap TOS and NOS
    d     #   duplicate TOS
     x    #   pop TOS and interprete it
      ]   # end string constant, push it
       d  # duplicate TOS
        x # pop TOS and interprete it

Because of using the r command, this will not run on some anicent DCs.

\$\endgroup\$
0
\$\begingroup\$

Ruby, 21 12 bytes

loop{p$.+=1}

Print all natural numbers. As far as I understand the problem description, this should be ok.

\$\endgroup\$
0
\$\begingroup\$

PHP, 21 bytes

for(;;)echo uniqid();

Usage: php -r "for(;;)echo uniqid();"

Outputs unique IDs based on the current time in microseconds: 58b3e065e4b4c58b3e065e4b6358b3e065e4b7b58b3e065e4b9458b3e065e4bac58b3e065e4bc458b3e065e4bdc58b3e065e4bf558b3e065e4c0e58b3e065e4c2658b3e065e4c3e58b3e065e4c5658b3e065e4c6f58b3e065e4c8758b3e065e4c9f...

as a continuous sequence of: 58b3e09390617 58b3e09390651 58b3e0939068a 58b3e093906c3 58b3e093906fc ...

\$\endgroup\$
  • \$\begingroup\$ While it's very unlikely, it's not impossible that this ends up looping if you happen to go through the values with the exact same timing after that number wraps around. The challenge is very clear that there should be no possibility at all that the output could be periodic. \$\endgroup\$ – Martin Ender Feb 27 '17 at 10:24
  • \$\begingroup\$ @MartinEnder you mean the script could output two same consecutive values in the case that the microtime will be the same for two outputs? (very fast execution) \$\endgroup\$ – Mario Feb 27 '17 at 11:07
  • \$\begingroup\$ No, I was under the impression that the output of uniqid has a fixed length. So if you let the program run for long enough that string will overflow and start from the beginning. Then at some point it will hit the initial timing and the in principal could output the exact same sequence of IDs again. That said, if you can show that the length isn't fixed, this should be fine. \$\endgroup\$ – Martin Ender Feb 27 '17 at 11:12
  • \$\begingroup\$ @MartinEnder ´uniqid´ should output an id based on the current time, in this format: first 8 characters are unix time and the last 5 are microseconds, so I think it will go on virtually forever without any string overflow or duplication. Or am I missing something obvious? (I'm not a computer scientist though...) \$\endgroup\$ – Mario Feb 27 '17 at 13:37
  • 1
    \$\begingroup\$ If the length is fixed to 13 characters it has to overflow at some point, because there is only a finite number of possible values. \$\endgroup\$ – Martin Ender Feb 27 '17 at 13:43
0
\$\begingroup\$

Perl 6, 11 bytes

say($++)xx*

Prints the natural numbers.

Try it online!

\$\endgroup\$
0
\$\begingroup\$

Python 2, 24 bytes

Prints 9 times each power of 2.

n=9
while 1:print n;n+=n

Try it online

\$\endgroup\$
  • \$\begingroup\$ 9 times powers of 2? Are you trying to be as weird as possible? If so, I recommend while n:. \$\endgroup\$ – CalculatorFeline Feb 28 '17 at 0:51
  • \$\begingroup\$ @CalculatorFeline That doesn't change the output. But yes, I didn't want to just print every positive integer. This way shows that the integers are arbitrary precision as required, because the output grows quickly. \$\endgroup\$ – mbomb007 Feb 28 '17 at 14:36
0
\$\begingroup\$

Batch, 7 bytes

time|%0

Or:

%random%|%0
\$\endgroup\$
  • \$\begingroup\$ The latter might repeat, it being random \$\endgroup\$ – Conor O'Brien Feb 28 '17 at 3:52
0
\$\begingroup\$

Powershell, 19 Bytes

Boring counting up answer.

for(){[bigint]$i++}

Improved version of answer from Count Up Forever

\$\endgroup\$
0
\$\begingroup\$

stacked, 9 bytes

$out0 ani

Try it online! Similar to my Count up forever answer, this outputs natural numbers from 0, the counter.

\$\endgroup\$
0
\$\begingroup\$

Bourne Shell, 11 bytes

yes date|sh
\$\endgroup\$
0
\$\begingroup\$

TI-Basic, 11 Bytes

While 1
Ans+1
Disp Ans
End
\$\endgroup\$
  • \$\begingroup\$ Don't you get an error when numbers get too big? \$\endgroup\$ – Kritixi Lithos Feb 28 '17 at 17:01
  • \$\begingroup\$ I am assuming infinite memory in float sizes and precision. \$\endgroup\$ – Julian Lachniet Feb 28 '17 at 20:23
0
\$\begingroup\$

GNU sed, 13 bytes

This is an arbitrary precision counter in unary. That's a fancy way of saying that I append one 0 to the pattern space and print it on every iteration (infinite loop).

:
s:0*:&0:p
b

After some time this would normally run into a memory allocation error and stop printing, because it can't store anymore the ever growing pattern space. That's not a problem for this challenge, since the memory is assumed to be infinite.

Try it online! (this interpreter further limits the available resources by design)

Output preview: only the first 5 lines

me@LCARS:/PPCG$ echo | sed -f infinite_non_periodic.sed | head -5
0
00
000
0000
00000
\$\endgroup\$
0
\$\begingroup\$

Sesos, 2 bytes

SASM

set numout
jmp, put, add 1

SBIN

00000000: c40a                                              ..

Prints all non-negative integers in order.

Try it online!

\$\endgroup\$
  • \$\begingroup\$ Will this reach a max integer and overflow, or does sesos use arbpreints? \$\endgroup\$ – FlipTack Dec 27 '17 at 4:21
  • \$\begingroup\$ In the absence of the set mask directive, Sesos uses arbitrary precision integers. \$\endgroup\$ – Dennis Dec 27 '17 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.