The most crucial observation is that if \sigma_1(m) is divisible by 2017, then according to (3) almost every multiple is, too
(the exception is when m and n are not coprime, for example for m = n).

My function search() starts with equation (2) (and k >= 2) because there are only few such numbers.
I check for every prime whether \sigma_1(p^k) = dfrac{p^{k+1} - 1}{p - 1} is a multiple of 2017.
If yes, then that number including all its multiples (except every p-th multiple) has a divisor sum that is divisible by 2017.
Since p^2 <= 10^11 less than a million number have to be checked which is done in less than a second.

Much more computation time is spent on equation (1):
every prime p where p+1 is a multiple of 2017 and its multiples have a matching divisor sum.
Instead of finding all primes below 10^11 I check every number 2017k - 1 whether it is prime.
The Miller-Rabin test from my toolbox is pretty fast but I had to include a GCC optimization to stay below one minute execution time.

A substantial part of my code is devoted to detecting duplicates: a few number are found multiple times.
For example 12101 is the smallest prime where \sigma_1 is divisible by 2017. The next prime is 24203.
Their product 12101 * 24203 = 292880503 will be found while processing all multiples of 12101 and then again while processing all multiples of 24203.
The container found is a simple std::vector because it has pretty much zero data structure overhead (unlike std::set).

Duplicates (or a "collision") is impossible for the first 12101-1=12100 multiples of a matching prime (since 12101 is the smallest).
To keep my code more generic I simplified that idea and only assume that a collision is impossible for the first 2017-1=2016 multiple.
If the current prime p is larger than sqrt{10^11} then a collision can only occur if the multiple was seen before because it must be smaller than `p.
Therefore I sort the list of primes found so far and perform a lookup with binary search.
All these optimizations have only one goal: reduce the size of found until it drops below the 256 MByte limit.

When all primes are processed then found is sorted again to eliminate all duplicates with std::unique.

Note

I had the solution pretty fast but my code needed about 6 minutes and almost 2 GByte RAM.
Most of the time was spent optimizing the code (e.g. refactor from std::set to std::vector).
And while optimizing, I "broke" the algorithm quite a few times ...

Right now my solution has still high memory consumption and execution time.
It's by far the highest ranking expensive solution which doesn't exceed the memory or CPU limits.

Interactive test

You can submit your own input to my program and it will be instantly processed at my server:

Input data (separated by spaces or newlines):Note: The second parameter must be a prime else the result will be garbage

This is equivalent toecho "1000000 2017" | ./565

Output:

(please click 'Go !')

Note: the original problem's input 100000000000 2017cannot be enteredbecause just copying results is a soft skill reserved for idiots.

(this interactive test is still under development, computations will be aborted after one second)

My code

… was written in C++11 and can be compiled with G++, Clang++, Visual C++. You can download it, too.

Those links are just an unordered selection of source code I found with a semi-automatic search script on Google/Bing/GitHub/whatever.
You will probably stumble upon better solutions when searching on your own.
Maybe not all linked resources produce the correct result and/or exceed time/memory limits.

Heatmap

Please click on a problem's number to open my solution to that problem:

green

solutions solve the original Project Euler problem and have a perfect score of 100% at Hackerrank, too

yellow

solutions score less than 100% at Hackerrank (but still solve the original problem easily)

gray

problems are already solved but I haven't published my solution yet

blue

solutions are relevant for Project Euler only: there wasn't a Hackerrank version of it (at the time I solved it) or it differed too much

orange

problems are solved but exceed the time limit of one minute or the memory limit of 256 MByte

red

problems are not solved yet but I wrote a simulation to approximate the result or verified at least the given example - usually I sketched a few ideas, too

black

problems are solved but access to the solution is blocked for a few days until the next problem is published

[new]

the flashing problem is the one I solved most recently

I stopped working on Project Euler problems around the time they released 617.

The 310 solved problems (that's level 12) had an average difficulty of 32.6&percnt; at Project Euler and
I scored 13526 points (out of 15700 possible points, top rank was 17 out of &approx;60000 in August 2017)
at Hackerrank's Project Euler+.

My username at Project Euler is stephanbrumme while it's stbrumme at Hackerrank.

Copyright

I hope you enjoy my code and learn something - or give me feedback how I can improve my solutions.All of my solutions can be used for any purpose and I am in no way liable for any damages caused.You can even remove my name and claim it's yours. But then you shall burn in hell.

The problems and most of the problems' images were created by Project Euler.Thanks for all their endless effort !!!

more about me can be found on my homepage,
especially in my coding blog.
some names mentioned on this site may be trademarks of their respective owners.
thanks to the KaTeX team for their great typesetting library !