That's an impressive trick. I'll have to remember it.

Need to focus on index

If you have indications, I have the same result

agree

Looks to me that the testcases sumLudic(10) -> 107 and sumLudic(25) -> 1100 are wrong.
Instead, they should be:
sumLudic(10) -> 101 = 1 + 2 + 3 + 5 + 7 + 11 + 13 + 17 + 19 + 23
sumLudic(25) -> 964 = 1 + 2 + 3 + 5 + 7 + 11 + 13 + 17 + 19 + 23 + 29 + 31 + 37 + 41 + 43 + 47 + 53 + 59 + 61 + 67 + 71 + 73 + 79 + 83 + 89

How can we calculate an effective (lowest as possible) upper bound N to the first array of integers (2..N)?

The exact bound is n-th ludic number of course, but we don't know this number before sieving, so we need to make some assumption.

For example, if you will construct a list of (n-th ludic / n) you can see, that this value is lesser than sqrt(n). This means that we can make a bound for n-th number as ceil(n * sqrt(n)). But this number is rather big when n is 10000 (it is 100 * 10000 = 1000000), and in my first solution 25 * 10000 was enough.

Will be very interesting to do some math...

sumlucid(10) = 1 + 2 + 3 + 5 + 7 + 11 + 13 + 17 + 19 + 23 = 101 not 107

sumlucid(25) = 1 + 2 + 3 + 5 + 7 + 11 + 13 + 17 + 19 + 23 + 29 + 31 + 37 + 41 + 43 + 47 + 53 + 59 + 61 + 67 + 71 + 73 + 79 + 83 + 89 = 964 not 1100

Is there something wrong?

Well done!

actually loping upto the given number would be very slow....

You need to swap assert's arguments actual and expected results in java test cases. Currently, it's showing the actual result as expected and vice versa.

Golang Translation with Improved Testing

There are a few differences that I want to highlight:

• Test case added for minimum n (n = 1)
• Test case added for maximum n (n = 10000)
• Test cases added for randomly generated n (1 ≤ n ≤ 10000)
• Solution changed to be capable of solving high n (n ≈ 10000)

The previous solution couldn't handle n = 10,000. It would panic with a runtime error: index out of range. The reason for the panic is that the sieve was of size 70,000 which isn't enough natural numbers to find 10,000 ludic numbers. If you attempt to increase the size of the sieve, then the process will timeout. My solution can handle n ≈ 25000 before timeout occurs.

The modifications to the test cases are to increase test coverage to include the minimum and maximum n

ah.... thanks! (TIL about yet another code golf site - more hours to be wasted :-)

Actually, this is the top solution to an old anagol challenge by golfing legend xnor :).

Here is the original one, and honestly, I have no idea how he came up with such an intricate formula. The ^ and ~ seem rather unuintuitive, making me think that he used brute force, perhaps with a little bit of mathematical insight. I've attempted to reproduce his magic formula using brute force, and interestingly I get no results if I omit either the ^ or ~ operators. Yes, it is truly magic :P

Wow!

How do you find such a magic formula?! Would you care to explain? :-)