http://qs321.pair.com?node_id=442322

I was thinking about Conway's audioactive sequence and how easy it would be to write a perl program generating it. Well, here it is, as a oneliner:
perl -e '$_=1;print,s/((\d)\2*)/(length$1).$2/ge while~<>'
(this waits for user to press return before emitting the next term of the sequence.)

By comparison see e.g. this link. (Please note however that it's just a random hit from Google: don't consider it to have an absolute indicative power.)

Replies are listed 'Best First'.
Re: Conway's audioactive sequence oneliner
by ambrus (Abbot) on Mar 25, 2005 at 14:47 UTC
Re: Conway's audioactive sequence oneliner
by japhy (Canon) on Mar 25, 2005 at 14:50 UTC
    The interesting thing about it is that it shows a very-bad-case for run-length encoding.
    _____________________________________________________
    Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
    How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

      The interesting thing about it is that it shows a very-bad-case for run-length encoding.

      It's ironic that each item in the sequence is a sort of rle of the previous one. Granted, it is a very inept rle, since it causes the length of the "encoded" string to grow, but it is rle "in spirit". In fact, with a different starting point (e.g. 111111122222222), the rle would be initially OK (i.e. 7182). Of course, it would immediately start to grow again (17111812, 111731181112, etc.). It is also interesting to note that this "encoding" has one fixed point, namely 22, and it's not hard to convince oneself that it is unique. Anyway, I don't know much about rle, but I wonder if it is a property of every run-length encoding scheme that repeated applications of the scheme, starting with some string of integers, would lead to increasingly longer strings... But this is beginning to get very OT...

      the lowliest monk

      The interesting thing about it is that it shows a very-bad-case for run-length encoding.
      Interesting indeed. Do you have any data from which this is apparent? Or is it just a well known "feature" of the sequence - I plainly don't know!
        Let's examine the properties of the sequence:

        It is made up only of 1's, 2's, and 3's

        We can prove this by contradiction. Because the sequence starts with '1', the only way a '4' can show up is as the first number in a pair (the "run" value -- the bold values in 312211). After all, that's the only way that the '2' and '3' ever show up. So this means we must have a sub-sequence such as "1111", "2222", or "3333" in our sequence. Let's abstract these as "xxxx".

        There are two ways "xxxx" can be placed in the sequence, at an even offset or an odd offset. At an even offset, the first and third 'x's are counts; at an odd offset, the second and third 'x's are counts. Let's examine the the even offset first. You can't have "C1xC2x" in the sequence, because that means it should have been encoded as "(C1+C2)x". Similarly, at an odd offset, there must be a count before the first 'x' (we'll call it C1 again), which means we have "C1xxxx" in our sequence. Again, you can't have two counts in a row for the same value! The subsequence would have to be "(C1+x)xx".

        So this means there will never be four like values in a row, thus '4' will never be in this sequence. (You can prove that '2' and '3' WILL be in the sequence.)

        Size tradeoffs are minimal

        Every span of like values results in a two-character sequence (count and value). 1 value in a row results in a gain of a character, 2 values in a row results in no change, and 3 values in a row results in a loss of 1 character. What we have to examine is the sequence and show that triplets are far less common than singlets and couplets.
        _____________________________________________________
        Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
        How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart