Python: new test framework to be used.

and 17 must stay

19 must be deleted from array, but they , i think, have the mistake in the example

[5, 7, 11, 13, 17, 19 ...]
The first deleted number is 3 -> Ludic = {1, 2, 3}.

Take the first element from the resulting array: 5.
Remove every 5th number.
[7, 11, 13, 19 ...]
The first deleted number is 5 -> Ludic = {1, 2, 3, 5}.

where is 17??? Why not 19??? 19 is 5th element
must be [7, 11, 13 ,17 ...]

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.