# Talk:Zumkeller numbers

## Why this limitation in c++

// if we get here and n is odd or n has at least 24 divisors it's a zum! if (n % 2 || d.size() >= 24) return true;

99504 has 30 divisors and is not a Zumkeller number.

Tested with GO version:
<lang go>func main() {

fmt.Println("The first 220 Zumkeller numbers are:") for i, count := 99500, 0; count < 5; i++ { if isZumkeller(i) { fmt.Printf("%3d ", i)</lang>

99500 99510 99512 99516 99520

Tested with cpp version: <lang cpp> int main() {

cout << "First 220 Zumkeller numbers:" << endl; vector<uint> zumz; for (uint n = 99500; zumz.size() < 5; n++) if (isZum(n)) zumz.push_back(n); cout << zumz << endl << endl;

...

// if we get here and n is odd or n has at least 24 divisors it's a zum! if (n % 2 || d.size() >= 29) return true;</lang>

99500 99504 99510 99512 99516

Checked the first 100,000 Zumkeller numbers.

First occurrence of Non-Zumkeller number with count of divisors

Div count number 12 738 16 7544 18 3492 20 56816 24 14184 30 58896 36 236448

Horsth 06:56, 9 May 2021 (UTC)

Good find! It's probably a bug. I'll look into it when I get a chance, thank you. --Mckann (talk) 16:47, 11 May 2021 (UTC)

I took a look and I'm not getting those numbers in the output. Can I see how you unit tested this? I'm not sure why that would matter though... my best guess is an OS dtype issue causing overflow but that seems unlikely. What IDE/OS did you run this on?--Mckann (talk) 03:35, 12 May 2021 (UTC)

- I think the overflow will happen with 32 Bit aka uint.

If you change d.size to >30-Bit it will take a while and find 99504 to be a non-Zumkeller number.<lang c++>// if we get here and n is odd it's a zum!

if (n % 2 || d.size() > 30) return true;</lang>

- Your program is limited to 31 divisors.

I'm testing mostly in the web on TIO.RUN like TIO.RUN/#cpp-gcc to be comparable. d.size >30 takes more than 60s limit :-(

Horsth (talk) 06:41, 12 May 2021 (UTC)

Alright, so I'm not seeing any overflow here. the variable d points to a vector of unsigned ints, stored in an array, so d.size() can become extremely large. I think the largest set I saw was 88 divisors, and the sum did not overflow. I also am still not seeing the bad outputs you did, so I'm not sure what's going on there, except for 99504. I use the condition odd|n divisors > 24 but I don't think that holds for large N if N is even. 99504 may be the first number that gets through. Given the problem description I didn't anticipate large even numbers to be evaluated; they get filtered before printing to console anyhow, so I think I wrote it that way for efficiency. I really don't remember. If you remove that condition the output looks fine through the first 100 000, but it will take a very long time. Probably, if you want to improve on this, there are a few handy properties of the sequence that could be used to bring time complexity down. But really, changing the data structure for d to make insertion faster and working with base 2 throughout instead of converting for no good reason would really speed up computation time. And there are lots of places to trade space for time, too. --Mckann (talk) 23:38, 12 May 2021 (UTC)

- My real intention was to find a justification for
or n has at least 24 divisors it's a zum!

- There is no.

In 'OEIS:A083207 - Zumkeller numbers someone stated and checkedAll 205283 odd abundant numbers less than 10^8 that have even abundance are Zumkeller numbers. - T. D. Noe, Nov 14 2010

something one can use.

- My real intention was to find a justification for

Oh I see. It works, empirically, for N >> max Zumkeller number needed for the problem and reduces runtime appreciably. That's the justification. I should put a comment in there, thank you. --Mckann (talk) 16:45, 15 May 2021 (UTC)

## Where to find count of Zumkeller to verify solutions.Is there a constant ratio 0.228...?

I have modified the program to run up to 1E9.On AMD 2200G Linux 64-bit

Start 1 at 1 100000000 tested found 22879037 ratio 0.2287904 recursion 1.101 runtime 9.777 s 200000000 tested found 45744040 ratio 0.2287202 recursion 1.116 runtime 10.640 s 300000000 tested found 68603020 ratio 0.2286767 recursion 1.171 runtime 11.159 s 400000000 tested found 91458844 ratio 0.2286471 recursion 1.230 runtime 11.506 s 500000000 tested found 114316149 ratio 0.2286323 recursion 1.283 runtime 11.770 s 600000000 tested found 137176153 ratio 0.2286269 recursion 1.332 runtime 20.701 s 700000000 tested found 160037821 ratio 0.2286255 recursion 2.834 runtime 22.288 s 800000000 tested found 182899550 ratio 0.2286244 recursion 2.786 runtime 13.064 s 900000000 tested found 205760422 ratio 0.2286227 recursion 2.691 runtime 12.682 s 1000000000 tested found 228620760 ratio 0.2286208 recursion 2.620 runtime 12.842 s total 136s = 2m16s ( 228620758 1000000000 time 2763.437 s (2 with high recursion >1e8 added as true ) )

Horst.h 06:28, 20 June 2021 (UTC)

## Cheating odd no 5 zumkeller numbers

there are more restrictions for finding those zumkeller numbers quick: The first not divisible by 3^2*7 aka 63 is #204:6,789,783

203:6729723 : 80 : 3^4*7*11*13*83_chk_6729723<_SoD_13660416< 6830208 = 21+117+1079+11869+87399+6729723 = 6830208 204:6789783 : 96 : 3*7^2*11*13*17*19_chk_6789783<_SoD_13789440< 6894720 = 931+15827+88179+6789783 = 6894720 205:6837831 : 96 : 3^3*7*11^2*13*23_chk_6837831<_SoD_14300160< 7150080 = 3+33+759+14157+297297+6837831 = 7150080

The first not divisible by 3*7 aka 21 is #908:28,683,369

907:28639611 :108 : 3^2*7*11^2*13*17^2_chk_28639611<_SoD_59449936< 29724968 = 9+187+17017+200277+867867+28639611 = 29724968 908:28683369 :128 : 3^3*11*13*17*19*23_chk_28683369<_SoD_58060800< 29030400 = 19+57+1311+55913+289731+28683369 = 29030400 909:28765737 : 96 : 3^2*7*11*13*31*103_chk_28765737<_SoD_58146816< 29073408 = 1+9+63+143+2163+14729+290563+28765737 = 29073408

It might be possible that those numbers aren't divisible by 3. Replace 5 by 7. Therefor it must be a very large number.

first zumkeller not divible by 2 or 3 0: 5,391,411,025 :384 : 5^2*7*11*13*17*19*23*29_SoD_10799308800 this:46,797,447,697 :768 : 7^2*11*13*17*19*23*29*31 is to small

- Hi. Thanks for checking out the speed cheat in the AppleScript solution's stretch goal code. While the cheat's a handy way to pre-filter numbers for the particular stretch goal and thus to speed up running the task, it's clearly no use to anyone urgently needing more than the first 203 odd Zumkeller numbers not ending with 5 in real life!

- I was initially more concerned about my assumption in the isZumkeller() handler logic that odd numbers are always either less than or greater than their aliquot sums, never equal to them. But I've tested up to 9,999,999 this morning and it's held true so far. --Nig (talk) 11:25, 21 July 2021 (UTC)
- Look for Perfect_numbers there is a link odd perfect numbers ( > 10^2000 ;-) )
- The "Odd Perfect" link isn't working, but the Wikipedia entry says:
*"It is unknown whether there is any odd perfect number, though various results have been obtained."*Numbers beyond 10^2000 are definitely beyond AppleScript's resolution — not to mention that getting to them would take more than the lifetime of the average AppleScript user. So that's a weight off my mind. ;) --Nig (talk) 13:25, 21 July 2021 (UTC)

- The "Odd Perfect" link isn't working, but the Wikipedia entry says:

- Look for Perfect_numbers there is a link odd perfect numbers ( > 10^2000 ;-) )