Ad
  • Default User Avatar

    It does indeed work now. Many thanks.

  • Default User Avatar

    Some test-cases for the julia translation might be broken:

    I need to catch calls to diag_2_symSE and rot_90_counterSE by hand and replace them with my own non-SE functions in oper, otherwise some tests throw an

    ERROR: LoadError: LoadError: MethodError: no method matching split(::Array{String,1}, ::String)
    ...
    

    in those two functions.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    Well it did somewhat, but only after submitting.

    On further thought I don't think there is really that much difference between this kata and the kata for the next bigger grid size and I actually did not expect this solution to be fast enough. And for the multisize kata this solution does not work (because apparently I've overlooked bugs for non-quadratic grids and because it is still too slow)

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    Creating the list is still O(N)

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    In the python tests the number '0' is not neutral as told in the description but counted as even.

  • Default User Avatar

    It seems weird at first glance, but think about what happens for example in your check for evenness if i is a string.

  • Default User Avatar

    I don't think that the runtime can be significantly improved. The algorithm is already linear with respect to the size of the input string and unless there are restrictions on the nesting, number of brackets, ... every char needs to be processed.

    So the only room for improvement would be to minimize the number of operations needed for each char. As far as I know python lists are optimized for fast append() and pop(), so no possible improvement for the stack. The remaining code seems pretty optimal. Looking at your solution the only 'obvious' improvement (since this is a python2 kata) would be to replace range with xrange, but in my tests range, xrange and enumerate all have a similar runtime. The differences are much smaller than the differences due to the load on the codewars servers. So for compatibility with python3 I would stick with range.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    For the first issue, can you try and put the flush before sys.stdout.buffer.... It seems that there are two different buffers for stdout at work here, that have to be flushed in the correct order.

    The second issue I don't understand at all. I've seen it during some tests exactly once yesterday and once today, but so far I can't reproduce it. Usually I get the correct unicode symbols.

  • Default User Avatar

    OK, next try:-)

    The following part for python3 seems to be working for me as intended:

    sys.stdout.buffer.write(uni_str.encode('utf-8', 'surrogatepass'))
    sys.stdout.buffer.write(b"\n")
    sys.stdout.flush()
    
  • Default User Avatar

    @zebulan,

    since the print-statement does that automatically, did you try to add a linebreak ('\n') at the end of each string?

  • Loading more items...