Expression string is formatted in a specific way which makes a specific kind of solution possible: this should be specified.

Random tests need to be improved:

• There are only 30 random tests, which is not sufficient
• Test generation mechanism is flawed: it only has a 50% chance to delve 1 depth deeper, so most expressions are very shallow. It also means all the tests have the same average depth (because the supposed test size is the upper limit of the depth).

Reference solution is incorrect, e.g it expects true iff not true to be True.

TypeScript translation (also added random tests that don't use a reference solution)

If a set of test data fits more than one set of requirements, how do we decide what to return? I found a fixed test for which I was supposed to return bijective, but the data also fit the requirement for injective. Shouldn't the descriptions be mutually exclusive to prevent situations like this?

Needs fixed tests that specifically check 0 and 1 are handled properly.

performance tag is missing

Why does the initial code contain a non-optimized solution? Initial code should only contain a stub.

Description should use code formatting.

Java version expects an optimal solution. Can you specify and properly enforce the performance requirements instead of writing more translations?

IMO, the mods should unpublish the kata for now because the author clearly doesn't understand what he's doing.

Python:

• use tuple instead of array as input
• expected and actual are reversed in the assertion message

Hi,

In python:

• the test.it blocks should be wrapped with describe blocks (one for fixed tests, one for random tests, for example). See documentation if needed.
• there are no perf requirements

Generally:

Honestly, I'd just drop the perf requirements: the reference solution is optimized for one specific situation only, and is far from what's actually needed if you really wanna optimize a problem like that. So I don't see the point to put any perf requirements in the task. Moreover, so far it's not tested properly/appropriately, and some info are lacking (like the length of the queries array and the typical size of the ranges, to show the expected solution isn't something using segment trees).

Cheers

Naive aproach doesnt work, try to find efficient solution

My naive approach worked just fine (well, it's not O(n^3)-naive but still suboptimal).