Ad
  • Default User Avatar

    0112 is the same as 112

    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 form

    And 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:

    func descendingOrder(of number: Int) -> Int {
      print(number)
      return number
    }
    

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    There is no test with that input in javascript and the expected order is descending, so, no idea what you're talking about.

  • Custom User Avatar

    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.

  • Default User Avatar

    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.

    So one test doesn't work: 0112 -> 2110

    That test does not exist. It cannot exist. However you came up with that, you mis-measured.
    Re-measure.

  • Custom User Avatar

    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

  • Default User Avatar

    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.

  • Custom User Avatar

    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)