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.
Yes. Which is why, you will never receive 0112 as input. That's why it didn't happen.
That is convincing, right? We can rule that out.
myfunction(0112)
<-- myfunction is going to receive 112, it will not be able to see "0112" in any shape or formAnd if that is ruled out, then, you found 0112 somewhere else.
Additionally, looking at the test code, there is no such case. But the above is sufficient to already know that's not what happened.
So it comes down to re-measuring, because the measurement of 0112 can't be. And yeah you might not successfully do this but ... that's okay.
Typically what you can do to measure input is to print it out as the first thing you do in your function. For example:
Ideally you'd also figure out how you mistakenly found 0112, just because it's good to understand what went wrong.
If on the other hand the tests were based on strings and "0112" was generated, then you would still be receiving 112 and 2110 would have been expected. The test case would be 112 -> 2110. Yes that would be wrong, but that is also not happening and it wouldn't be 0112 -> 2110 which cannot be. It is however plausible that your code does this, that your code creates that string, converts it to int, loses the zero. That'd be something you created and that would mean you're measuring not the input but some intermediary state in your own solution.
natan,
I don't know how this test case worked but... "Attempt" did trigger this issue (0112 -> 2110). So if you ask me to remeasure (I couldn't, because "Attempt" blocked me from submission due to failure).
But as i mentioned... treating an Int in swift or Java, 0112 is the same as 112 (This happens before conversion of string). I would propose if we do find it, we should remove it.
There is no test with that input in javascript and the expected order is descending, so, no idea what you're talking about.
This test DOES exist. JS treats numbers with leading 0 as octal. After researching a bit I have learnt that it would be a bad practice anyway to use numbers with leading 0 in real life code, therefore I would suggest not to waste time to search for a workaround, but rather to remove this example from tests.
It's not that it doesn't matter, it's that it isn't different. It's the same value. The difference would only exist in a string, so when you talk about 0112, you're talking about strings. But you're not receiving a string so this isn't what happened.
Find out what value you did receive. It's not 112, that's something you more or less made up.
That test does not exist. It cannot exist. However you came up with that, you mis-measured.
Re-measure.
http://onlineswiftplayground.run/
It doesn't seem to matter if it's string or not, the simple test here seems to show otherwise.
var test1 = 0122
var test2 = 122
print("Test one values (test1)") < -- "122"
print("Test Two values (test2)") <-- "122"
print(test1 == test2) <-- True
I don't know swift but I'm pretty sure 0112 is not a separate value from 112, you're thinking of strings.
I'm guessing you have not actually made a measurement showing you that input was 112? So it's a guess? Measure.
I just want to check, if my answer is incorrect. It seems that swift Int, removes leading zero by default.. So one test doesn't work:
0112 -> 2110
It seems that leading zero is removed in swift by default, hence 0112 when assigned is changed to 112. I want to know if anyone else dealt with this before (I've even used playground in swift to check)