Ad
  • Default User Avatar

    Me too number=6462745976994925
    f(k,b)=6462745976994924

    Expected: 186268, instead got: 6462745976994924

  • Default User Avatar

    With n = 15705261201683973613 Expected 15705261201683973612 but got 83
    83 is the correct answer. The random tests seem to break when the base is near 80. (I got another error where I got 84 for the base on a large number, but I did not write it down).

    #[test]
    fn fail12() {
    dotest( 15705261201683973613, 15705261201683973612 )
    }

  • Custom User Avatar

    This is an existing problem documented (much better) by iago.passos. Marking as resolved to avoid duplicated issues.

  • Custom User Avatar

    I may be mistaken, but it appears the rust solution has some issues.
    A portion of the tricky tests return the following error:
    With n = 17700847248605297701
    Expected 17700847248605297700 but got 84 at src/lib.rs:50:9

    I believe 17700847248605297701 in base 84 is correct:
    1:1:1:1:1:1:1:1:1:1:1_84 (11 digits), meaning the accepted solution (perhaps sometimes) returns n-1 in cases which it should not.

  • Default User Avatar

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

  • Custom User Avatar

    It's not a kata issue, but maybe not sufficiently explicit error message.

    If all tests are green, it means that your solution returns correct answers. If tests time out, it means your solution is too slow, and not all tests are executed.
    It's not that "all tests pass". It means that until timeout all tests return expected answer, but not all of them are executed.

    Your solution being too slow is not a kata issue.

  • Custom User Avatar

    I get timeout but its say all the tests is pass (in python)

  • Custom User Avatar

    it gets timed out in JavaScript with numbers that have basesuch as 1000000001
    any help?

  • Custom User Avatar

    What 1000000002: 90909091 should equal 1000000001??

  • Custom User Avatar

    So, in the rust version, I think I've found an issue.

    In the tricky_tests, sometimes I get errors like:

    With n = 18283961446061854279
    Expected 18283961446061854278 but got 138 at src/lib.rs:57:9
    

    The problem is that, as far as I've tested, in Rust and Python, 18283961446061854279 in base-138 is 1111111111.
    I've collected a few of these. They were:

    17126426820319058418 base-137
    15705261201683973613 base-83
    17393337673075145131 base-254
    18412318490320479416 base-565
    17948489581465697281 base-255
    18283961446061854279 base-138
    

    I have managed to submit my answer, because sometimes the tests don't use any number that breaks.

  • Custom User Avatar

    Any suggestion how to make it more correct?

  • Custom User Avatar

    The description should specify a range for n even in languages where all numbers are safe.

  • Custom User Avatar

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

  • Custom User Avatar

    no, 1 is in base 2. In base one, you'd only have zeroes (first an unique digit).

  • Custom User Avatar

    approved

  • Loading more items...