I managed to reduce the number of divisions by throwing some mathematics on it. Put very short:

If n is a Kaprekar number (to a base b) there must be a divisor ( d=b^m ) with n^2 = xd+r with the constraint n=x+r. (x beeing the quotient and r the remainder)

Substituting r with n-x, we get: n^2 = xd +n -x = x(d-1) + n

So: n(n-1) = x (d-1) --> x = n(n-1)/(d-1) This division can have no remainder!

The quotient x has to be < n (because n=x+r (with r>0)). Conclusion: d>n. It tells me, I should start with exponents m so that b^m >n.

The improvements are:

One modulo division is enough, where my original code had to compute quotient and remainder.

The lower bound for the divisor is increased and, more important, preserved before divisions take place.

The computation time for the search up to 10^8 is reduced to 4 % compared to my original code.

isKaprekarbasen=elem0$-- any remainders 0? takeWhile(<n)$-- remainder has to be < n. Now the list is finite.map(\div->(n*(n-1))`mod`(div-1))$-- compute the critical remaindersdropWhile(<=n)$map(base^)[2..]-- divisors must be > nmain=print$filter(isKaprekar10)[1..10^8]

BTW: I saw a possible error in my last iteration. takeWhile (<n) is not proven to be correct. It's better to do it that way:

isKaprekarbasen=letsqr=n^2inelem0$-- any remainder = 0? <=> is kaprekar!map(\div->(sqr-n)`mod`(div-1))$-- compute the critical remainderstakeWhile(<sqr)$dropWhile(<=n)$-- sensible bounds for divisorsmap(base^)[1..]-- infinite list of divisorsmain=print$1:(filter(isKaprekar10)[1..10^5])

Also, it's nicer to use upper and lower bounds for divisors before computing the devisions. This is proven to be correct now, but I lost speed. ;-) The speed improvement by melting construction and restriction together is only 86% instead of 96%.

Use fixed-width Ints instead of arbitrary sized Integers (by function signature) Large improvement!

It pays off to spend an additional modulo division if the number of possible divisors for the critical division can be heavily reduced.

'any' slightly outperforms 'elem'. (in this case?)

A hand-rolled recursion sometimes performs better (without additional division) and sometimes worse (with additional division) than the folding recursions hidden in the 'elem' or 'any' functions. (But code with builtin folds is much nicer to read.)

The improvement steps were: 1000s - 500s - 90s - 60s - 19s - 13s - 9s. Quite funny to squeeze the algorithm like that. :-) This is what I came up with:

isKaprekar::Int->Int->BoolisKaprekarbasen=letsqr=n^2inany(\div->(sqr-n)`mod`(div-1)==0)$-- any rem = 0? <=> kaprekar!takeWhile(\div->(sqr`mod`div)<n)$-- sensible bounds for divisorsdropWhile(<=n)$map(base^)[1..]-- infinite list of divisorsmain=print$1:(filter(isKaprekar10)[1..10^8])

I wanted to have it in C for reference. Even expressed imperatively, it is now a very simple and nice algorithm. (2-3s)

## re: Challenge: find 'Kaprekar numbers' VIEW POST

FULL DISCUSSIONI managed to reduce the number of divisions by throwing some mathematics on it. Put very short:

The improvements are:

The computation time for the search up to 10^8 is reduced to 4 % compared to my original code.

I love seeing the iterations of your solutions. Not that this challenge was intended to have any "winners," but if we had to choose...

Do you have any ideas for new #challenge posts?

Thanks. I enjoyed learning about Kaprekar number as well as I enjoyed iterating my solutions as I digged deeper into it.

You encouraged me to pose a challenge, hoping it's not too easy and not too hard. dev.to/heikodudzus/challenge---pri...

BTW: I saw a possible error in my last iteration. takeWhile (<n) is not proven to be correct. It's better to do it that way:

Also, it's nicer to use upper and lower bounds for divisors before computing the devisions. This is proven to be correct now, but I lost speed. ;-) The speed improvement by melting construction and restriction together is only 86% instead of 96%.

Some last improvements:

The improvement steps were: 1000s - 500s - 90s - 60s - 19s - 13s - 9s. Quite funny to squeeze the algorithm like that. :-) This is what I came up with:

I wanted to have it in C for reference. Even expressed imperatively, it is now a very simple and nice algorithm. (2-3s)

C profited more by the additional division, it reduced the execution time by 75%, Haskell profited only by 50 %.

I hope, I'm really done, now. :)