Hi,

I don't do rust myself, so I cannot tell. That test uses a macro, and this specific test is only closing the instance, without calling any other method (afaict...).

yeah, that one is the issue from years ago that is still opened. It's chemically incorrect, but considering the task, it's still doable (numerically/mathematically) without problems on user's side (as long as they stick to the task only)

edit: and numerically, it shoud have 0 H, so. But again, the molecule cannot exist, yeah.

That's a cheat. Don't use that.

ffs, I thought I had fixed that... x/ Yes, it should be "propenoyl..."

random tests, I guess?

except the test is not on ans...

You should explain the math notations: not all users have a math-college background (hint: I don't ;) )

Also names are not to be chosen randomly. If you can switch the function name from sum_not_prime to sum_prime without changing anything else, this means the name has nothing to do with the task (or one of them is totally wrong).

read below...

The description still doesn't describe the actual task.

What do the mathy shenanigans mean?

also, sum_not_prime became sum_prime whithout any additional explanation: this smells absolutely bad for the quality of the description.

Also, the tags show there are performances requirements => theere should be some kind of info about that in the description. Typically (when relevant): number of tests, range of inputs, ...

The description still doesn't make any sense... When I see "sum not prime", I expect to sum non prime numbers. Obviously, the examples are showing something completely different. Please, properly explain the task.

at least, they aren't public, this time... 'x)

I just created one single fork, but I also see a draft (with the very same content).
How bad is that new bug? As in: do you also see the draft in the current page?

edit: not on the page you'll land on when accessing this comment, but on the root page of the fork (top left link: "rooted by...")

Specs of the python tests are slightly different from the original language: the random tests generate words without any vowel.

All languages should be aligned:

• either this should be added to the fixed tests and random tests in all language
• or python random tests should not generate such a kind of input

in that case, any(arr) is also O(1)

Mmmmh... I get what you mean (I think...), but that's very dangerous wording again.

• Equivalents of bool(arr) are always O(1) (because they rely on the length of the structure, not it's content).
• any uses the iterator protocol so works quite differently. any([]) gives False, but any([0]*100000) also gives False. But in O(N).

And my point about the base case is that without it, one has to think about "Hey, what's the default output for any([]) and all([]), again??", while it's totally straightforward if you put the actual (obvious) base case in the code.

hein?