Ad
  • Default User Avatar

    For input {3,2,2,3,2,1,1,2,3,3,2,2,5,1,2,2,4,3,3,2,1,2,2,4} my algorithm produces valid solution
    [ [ 2, 4, 1, 3, 5, 6 ], [ 1, 6, 3, 2, 4, 5 ], [ 4, 1, 6, 5, 2, 3 ], [ 6, 5, 2, 1, 3, 4 ], [ 5, 3, 4, 6, 1, 2 ], [ 3, 2, 5, 4, 6, 1 ] ]
    yet the test expect
    [ [ 2, 1, 4, 3, 5, 6 ], [ 1, 6, 3, 2, 4, 5 ], [ 4, 3, 6, 5, 1, 2 ], [ 6, 5, 2, 1, 3, 4 ], [ 5, 4, 1, 6, 2, 3 ], [ 3, 2, 5, 4, 6, 1 ] ]
    and thus fails.
    Problem with the tests is that there might be more than valid solution!

  • Default User Avatar

    C++: For input {2,2,1,3,2,2,3,1,1,2,2,3,3,2,1,3} my algorithm produces (valid) solution {{1,3,4,2},{4,2,1,3},{3,4,2,1},{2,1,3,4}} yet the test says it's wrong.

  • Default User Avatar

    for input {2,2,1,3,2,2,3,1,1,2,2,3,3,2,1,3} my algorithm produces valid solution {{1,3,4,2},{4,2,1,3},{3,4,2,1},{2,1,3,4}}
    yet the test says it's wrong.

  • Custom User Avatar

    Enjoyable coding challenge, congratulations.

  • Custom User Avatar

    For what it's worth, from my perspective I thought it was pretty clear. I wonder what you think is poorly explained?

  • Custom User Avatar

    Had to make a web app so that I could visualize & interact with the problem, but after that I was able to find a solution. Very fun kata, not like any I had done before, +1

  • Custom User Avatar
  • Custom User Avatar

    I don't think the problem is well explained at all.

  • Default User Avatar

    it is very likely that one hand get used multiple times

    So, that's it! Thanks, now totally explained.

    In all of the initial tests Hands are created, tested once and then freed. That let me to the assumption that it would always be that way. My mistake. Thanks again.

  • Default User Avatar

    yes, but what is the issue here ? you modify tracker yourself, so you mutate the state of your Hand object. then at the next call with the same object, of course the mutations will persist. take a look at how the random tests work, all of the hands are built beforehand and are played against each other at random, it is very likely that one hand get used multiple times, hence why the changes persist

  • Default User Avatar

    Thanks, but that result would be expected - buildTracker() should indeed set values into the tracker field.

    Let's use your test approach, but before any calls to buildTracker:

    Result compare(Hand *pl, Hand *op) {
      int checksum = (pl->tracker == 0) + (op->tracker == 0);
      // Both tracker values were set to 0 by PokerHand, so they should still be 0 now.
      assert(checksum == 0);
    
      // tracker fields will be updated by buildTracker().
      pl->type = buildTracker(pl, pl->cards);
      op->type = buildTracker(op, op->cards);
      Result retval = _compare(pl, op);
      return retval;
    }
    

    Output includes:

    boxfort-worker: solution.c:199: Result compare(Hand *, Hand *): Assertion `checksum == 0' failed.
    
  • Default User Avatar

    it seems to be your own code that modifies the tracker field though, I slightly modified your test in compare():

    Result compare(Hand *pl, Hand *op) {
      int checksum = (pl->tracker == 0) + (op->tracker == 0);
      pl->type = buildTracker(pl, pl->cards);
      op->type = buildTracker(op, op->cards);
      Result retval = _compare(pl, op);
      int new_checksum = (pl->tracker == 0) + (op->tracker == 0);
      assert(checksum == new_checksum);
      return retval;
    }
    

    the assertion fails.

  • Custom User Avatar
  • Default User Avatar

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

  • Custom User Avatar

    This code does not really confirm anything because we do not know how your real code, the one which breaks things, looks like.

  • Loading more items...