Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Me too number=6462745976994925
f(k,b)=6462745976994924
Expected: 186268, instead got: 6462745976994924
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.
This comment is hidden because it contains spoiler information about the solution
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:
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:
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.This comment is hidden because it contains spoiler information about the solution
no,
1
is in base 2. In base one, you'd only have zeroes (first an unique digit).approved
Loading more items...