# [seqfan] Re: A083207 On an observation of Frank Buss.

Donald Alan Morrison donmorrison at gmail.com
Sun Aug 22 02:40:58 CEST 2010

```On Fri, Jul 9, 2010 at 7:48 AM, peter.luschny
>> This observation was extended by T. D. Noe. He writes: "The 229026
>> Zumkeller numbers less than 10^6 have a maximum difference of 12.
>> This leads to the conjecture that any 12 consecutive numbers have
>> at least one Zumkeller number."
[**snip**]
> P.S. Can we find a 'grid' of Zumkeller numbers such that every
> other Zumkeller number is reachable within 12 steps and which has
>
> For example a sequence of numbers Z such that
> (a) Z is Zumkeller
> (b) Z = 2^N*S, where N > 0 and S is an odd squarefree number [A056911]
> (c) is minimal in the sens that the deletion of a member makes
>    at least one Zumkeller number unreachable in 12 steps.

SeqFans,

I guess I'm a "B-File" kind-of-guy (so far). Yann Laigle-Chapuy
optimized my is_zk() python/sage code with Cython, and also added a
prime test and perfect number test to speed it up. Thanks Yann!!

Today I computed the zumkeller numbers over the domain [1, 1 million]
inclusive.  The last 100k took about an hour, so less than ten hours
on a 2.1 Ghz laptop using only one of the two cores.  The RAM for the
whole linux system never used more than 1.3 GB RAM out of the 4GB
available, was very stable (didn't erratically grow), and never used
any swap space.

If anyone wants the B-File, I'd be happy to send it to you.

Some stats:

Count of ZK#s 229020 out of 1 million

As proven in the thread previous, the max deltas are still just 12.

The max deltas for the squarefree numbers march like this:

[(2, 1), (5, 2), (10, 3), (51, 4), (246, 5), (849, 6), (22026, 7),
(217077, 8)]

So it makes sense that the deltas of the intersection of sf and zk
stop at a multiple of 12:

[(30, 24), (174, 36), (762, 48), (5106, 72)]

So I have probably proven nothing, but it was still fun. =)

If someone could let me use their server, I could make zk crunching a
BOINC project just for the heck of it, and to promote the OEIS.  Or
someone could give this "B-Filer" a better idea.  There are plenty of
BOINC crunchers out there just crunching for the credit! =)

With a 64-bit build, using int64_t, we could theoretically crunch to
9223372036854775807 without changing the algorithm.  Assuming RAM
isn't eaten into oblivion by then.  It's just in good fun.  Of course
I'd have to strip down the build, and write the client and server.

Please, let the yawns come forth. =)

Cheers,
Don

```