[seqfan] Re: Interesting discovery by Dan Preston concerning a Recaman-like sequence

hv at crypt.org hv at crypt.org
Wed Mar 20 17:10:23 CET 2019


Neil Sloane <njasloane at gmail.com> wrote:
:Dan Preston just wrote to me about an interesting discovery he has made.
:The Recaman-variant A228474 seems to have an extraordinary jump at n=11281
:(or, less likely, it doesn't converge there)
:He finds the following values:
:
:WreckerBall[11276] = 632100
:WreckerBall[11277] = 632102
:WreckerBall[11278] = 632104
:WreckerBall[11279] = 632106
:WreckerBall[11280] = 631064
:WreckerBall[11281] still calculating after 32,200,000,000 steps...
://Segmentation fault: 11
:WreckerBall[11282] = 631072
:WreckerBall[11283] = 631070
:WreckerBall[11284] = 19675891
:WreckerBall[11285] = 631078
:WreckerBall[11286] = 631076
:
:He found other indices at 22044, 36618 which also fail to converge in a
:timely manner.

I've written some code to attempt this, available via commit b8eef3ea at
<https://github.com/hvds/seq>.

This keeps a bit vector of the values seen, split into chunks, and spills
chunks to disk to limit the memory use.

It appears to give correct values for known n, but trying it with 11281 it
gives a bus fault a little after 12,213,813,248 (which takes about 5 minutes).
That's around the time I run out of disk space, so that may be the whole
of the problem, but there may be a deeper problem.

If someone with a few TB of disk free fancies giving it a go (Max?), feel
free to give me a shout if you need any help getting it to compile and run.

The current values of constants such as CHUNK_SIZE and LOCAL_CHUNKS limit
the memory use to 16 GB; those can easily be tweaked to suit another system.

Hugo



More information about the SeqFan mailing list