did exactly the same, some 30 years ago, on the C64 ;-)

This made me think hard about how to avoid my usual slow brute-force frontal assault. I got oh-so-close with a few different approaches, and then finally shocked myself with a one-liner. That never happens! Thanks for the fun challenge!

A belated thanks for the review and the feedback!

Thanks for the fun kata. Brings back memories of looking at hex dumps of RPG programs and wondering what in the world they meant.

What does this kata add that other kata's about primes haven't done before?

I enjoyed everything, it was an awesome challenge.

ready

ready

ready

Very confusing description. (Copy paste the markdown)

Task :

Hello, warrior!

In this kata, you need to complete the function sum_not_prime, which takes two parameters :

• max_prime.
• max_num.
  and must return an array of length max_num where for each index 0 <= i <= max_num -1 :

array[i] = \sum_{p \, \le max-prime, p | i} p

Example :

• sum_not_prime(10, 15)
  The primes that need to be considered : $2$, $3$, $5$ and $7$.

  1. With $p=2$ : [0, 0, 2, 0, 2, 0, 2, 0, 2, 0, 2, 0, 2, 0, 2]
  2. With $p=3$ : [0, 0, 2, 3, 2, 0, 2+3=5, 0, 2, 3, 2, 0, 2+3=5, 0, 2]
  3. With $p=5$ : [0, 0, 2, 3, 2, 5, 5, 0, 2, 3, 2+5=7, 0, 5, 0, 2]
  4. With $p=7$ : [0, 0, 2, 3, 2, 5, 5, 7, 2, 3, 7, 0, 5, 0, 2+7=9]

  Final result : [0, 0, 2, 3, 2, 5, 5, 7, 2, 3, 7, 0, 5, 0, 9]

Note :

Although 0 % prime == 0, index 0 is always excluded from being updated.

The description isn't clear. I needed to study the example pretty carefully to figure out what needed to be done. For one thing, it should be clarified that the prime divisor is never added to the element at index 0, despite the fact that 0 % [prime] equals 0.

Here's an example of input whose expected output does not follow the "one vowel per line" rule:
"oGweQFMoJNk KnJLHOtimUtRTu GirCkKZBLIzXtOfTfNvfI h"

If the test conformed to the description, the last line of expected output would be "fTfNvfI h". But the expected output instead puts a newline after the I and leaves h on the last line by itself.

In testing and modifying my code to handle cases like this, I found that it was the space following the I that was triggering the newline. If that space were not there, the last line of the expected output would be "fTfNvfIh". This is not explained in the description.

You should really not mark issues as "Resolved" until they have been resolved. I think you first need to reach a clear understanding in your own mind about the rules for the expected output. Then these rules will be easier to express accurately in the description.

that still leaves 2) 3) 4) 6) unaddressed

6) on my list is such a case:

input:    'a5 '
expected: 'a-\n5 '
but got:  'a5 '

and it also doesn't hold when there are \n's in the input

furthermore the description contradicts that by saying that there should be a \n after each vowel

if you say that there should be exactly one vowel on each line, then one needs to be able to split it into lines and find a vowel in each line. that is not the case.

OK, but I saw at least one case where the test did require a new line after the final vowel if there was a space after that final vowel. That should be explained.

Danke gleichfalls!