:D

Actually [+] is faster for values in range [129, 255] and [-] is faster for values in range [1, 127].
0 and 128 are indifferent. So you can prefer one over the other only if you have an idea of your values' distribution. In real cases, [-] seems better in most cases, as all ASCII characters are in range [0, 127].

Yup. Did the same but replacing the "-" by a "+", as I had thought in this particular case, going "upwards" would be "slightly faster" (like "254 max length instead of 255")...
...But now I'm thinking of it, it isn't, as the first bit we start at is not yet incremented; so still 255 max length in both cases...
...I guess I should have stayed with "-" as this version looks "cleaner"/"more explicit" ^^
OH re-wait; in fact, the "+" version might indeed be slightly "faster" after all: like 32386 increments instead of 32640 decrements...
...I guess... (Unless I'm wrong?.. I think I need some sleep)

I liked the economy in this, and it builds the row of Pascal's triangle faster than using Lucas's method (which was my first solution). So I wrote my own version of this method which is a bit more annotated.

.

From the description : "Attempting to invoke an infinitely recursive pattern of any form" is what should throw an error. In this particular case, only p0 ever gets invoked, so no error should be thrown.

The commands 'anda', 'or' and 'xor' are not actually tested (although 'and', 'ora' and 'xora' are) (in Java).

O_O

Going to replace all V with E and all E with V when the servers stop timing out.

You state in the description that a vertex is the line between 2 edges, but it's the other way around. An edge is the line between vertices, which are the points.

I completed the Kata in python and fixed the problematic line in JS. It should work now

I run into the same problem in js, too :<

Can confirm. It's been in this state for a while. Please fix :>

There seems to be an issue in js. Submitting any code whatsoever throws the error 'Unexpected eval or arguments in strict mode'