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 )
}

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

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.

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.

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

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

What 1000000002: 90909091 should equal 1000000001??

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.

Any suggestion how to make it more correct?

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

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

approved

approved