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.
Got it, thanks!
I'm gonna list only the skip steps, in the middle fill them with a step of 1:
15350, 15355, 15365, 15375, 15385, 15395, 15500.
The change is, instead of going from 3 to 4, it changes from 3 to 5, but only when it should be 4. You're thinking it should change 3 for 5.
Thanks for explanation, but I still don't get it. It is writen " This defect shows up in all positions (ones, tens, hundreds, etc)." So, in my example, for 15350 3 in hundreds changes to 5 and we get 15500. Aga, seems like I miss something here.
I'm sorry, I don't understand why this is happening. The generator has been fixed. I can publish a new fork (but there will be no difference with the currenc tests), someone needs to approve it first: https://www.codewars.com/kumite/627ffdc0a2670b003d770406?sel=6282288017c6bf8c839675dd
Rust implementation, random test:
I run the test 2 minutes ago. The random test cases were:
104, 6093, 2070, 5069, 4039, 90392, 80318, 6092, 604 ...
Like in the Go random tests (see issue above) the fix in the Rust random test is not yet active.
I fixed the translation directly, but for some reason the tests still use the old number generator. I published this new fork (where one cannot see any difference, since the generator is ok): https://www.codewars.com/kumite/6280e8bff1b9edb55bb7dc6a?sel=6281ae9817c6bf0024967483
Go: Inputs in random tests may contain the digit
4
. This should not be possible (the odometer is faulty).The real miles number can contain 4. Let's see 55: it skips 4, 14, 24, 34, 40 and 54, so 55 - 15 = 40.
Javascript implementation:
"For n = 2003 the output should be 1461." how can the answer be 1461 if it always skips 4?
The same goes for the following test situations, all of these answers contain a 4... or am I missing something?
Test.assertEquals(faultyOdometer(55),40)
Test.assertEquals(faultyOdometer(2005),1462)
Test.assertEquals(faultyOdometer(999999),531440)
Test.assertEquals(faultyOdometer(2005),1462)
Fixed, thanks.
No, you got it wrong, instead of changing from 3 to 4, it changes from 3 to 5. It means when you see 15350 after 15339 in reality you only travelled 1 mile.
Care to explain how do you think that'll be the case? From 15229, it'll go to 15230, 31, 32, 33, 35 (skipped a 4 here), 36, 37, 38, 39 and 15250.
Rust implementation: The random test generates odometer values including the digit 4. E.g. 60416, 30454, 40, 40124234.
According the kata description no digit 4 could be in the odometer value, because digit 4 is faulty.
The random value generation in the test should be fixed.
Hi, I don't quite get how the odometer shows 15339 if it skips 4s. According to the description the odometer should go from 15229 immediatly to 15500. What do I miss?
It is not clear from the description when to throw an exception from undo and when just to return? For example:
1.Throw an exception after undo, get, undo:
unRe.undo();
Test.assertEquals(unRe.get('y'), 2, 'The undo method restores the previous state')
try {
unRe.undo();
Test.expect(false, 'It should have thrown an exception');
2.Shoud retun after undo, get,get, undo:
For "Random true multidimetional tests" in 99.9% I get "Expected: true, instead got: false", but when I write console.log(arr) in 100% of cases I get
arrays with numbers that are not squares. Seems like something wrong is here.
Loading more items...