Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
C++ test code is missing declaration of
string
Description issue:
is improper, should be comparable to:
Recursive often beats for-loops, but I didn't expect it which such a long function name, so I didn't bother. Well done.
This tries to solve some of the mentioned issues in the Discussion section, as well as an issue with random functions that are not derivable.
Factor translation random test seem to introduce evaluation of expressions with incorrect results
E.g. input
"(^ 1 (^ (+ (exp -1) (^ (- (* 0 x) x) 1)) 1))"
My code's result (which I already adapted to "simplify"
(- 0 e)
into(* -1 e)
which the kata description already doesn't require):"(^ 1 (+ (exp -1) (* -1 x)))"
random test report:
Apart from the forbidden simplication
(^ 1 e)
into1
, why does the test evaluates(^ 1 (+ (exp -1) (* -1 x)))
to(ln 1)
??Such an introduction of seemingly random appareances of
(ln constant)
occur regularly.Another example:
Factor translation test require optimizations in simplification which are strictly forbidden in the Kata description.
E.g.
The kata description explicitly has:
"In addition to returning the derivative your solution must also do some simplifications of the result but only what is specified below."
Factor translation (sample) tests throw error on resulting expressions that are functional equivalent due to commutative properties.
E.g. "(* 2 x)" passes the test, but "(* x 2)" doesn't, whereas it should.
this fork is slower
C translation does not report actual value on failure for sample tests.
The expression (prime_stream_next(stream)) == (2) is false.
Prototype should not use
const int
, that makes no sense at all.Nope, still same issue
Invalid C solutions that don't take into account stretching of the rubber band incorrectly pass all tests.
Duh! How did I miss that! Good find
Because of the each bit in n part;
11
is not represented as1011
for each bit in n, but rather as0..0001011
(depending on size of int).Thanks for forking! It's shorter, but I just wanted to demonstrate how compilers pool string constants...
Loading more items...