Current description is indecipherable and there are too much missing information:
Input list have at most depth 3
1st level is always a list; 2nd level can be a int or a list of ints
Find all lists resulting from exploding 2nd level of each list; for every list of ints in 2nd level, they should be exploded as set product; then list all by order of appearance in the result
Result should be a list of lists; sub-lists should be right-padded with 0 to the longest sub-list in the result
Test cases would have a better shape and would be more readable and maintainable if they were factorized. I suggest to create a function dotest that handles all test cases. Then all the fixed tests could be grouped in a list [(input, expected)], without repeating test.assert_equals x times.
First part is a nice puzzle. As for the second one, it's pretty easy to come around with a fixed array of bad integers. This array can either be hardcoded or calculated outside of the function. Both these ways feel like cheating to me.
So it's kinda weird: you have some performance problems to deal with, but they can be solved with the same computational complexity (linear) as the dumb algorithm, just changing the order a little bit.
IHMO, you should either remove the performance part from this kata (so that the stupid solutions like sum(1 if is_bad(i) else 0 for i in range(a, b+1)) work), or require a solution of logarithmic complexity.
Or maybe you can split this kata in two: the first one will be very simple allowing the most obvious solution, but the second one should pose the performance problem to its full.
fork to close below issue.
Current description is indecipherable and there are too much missing information:
3
int
or alist
ofint
slist
ofint
s in 2nd level, they should be exploded as set product; then list all by order of appearance in the result0
to the longest sub-list in the result1
Test cases would have a better shape and would be more readable and maintainable if they were factorized. I suggest to create a function
dotest
that handles all test cases. Then all the fixed tests could be grouped in a list[(input, expected)]
, without repeatingtest.assert_equals
x times.This kata definitely consists of two tasks:
First part is a nice puzzle. As for the second one, it's pretty easy to come around with a fixed array of bad integers. This array can either be hardcoded or calculated outside of the function. Both these ways feel like cheating to me.
So it's kinda weird: you have some performance problems to deal with, but they can be solved with the same computational complexity (linear) as the dumb algorithm, just changing the order a little bit.
IHMO, you should either remove the performance part from this kata (so that the stupid solutions like
sum(1 if is_bad(i) else 0 for i in range(a, b+1))
work), or require a solution of logarithmic complexity.Or maybe you can split this kata in two: the first one will be very simple allowing the most obvious solution, but the second one should pose the performance problem to its full.
It should be stated whether all options should be taken or only one (and which one exactly), e.g. what's the result of these: