Ad
  • Default User Avatar

    You are right. It did work once I applied Euclidean division (//). However, why should one spend so much time on figuring it out by running all those manual checks and numerous try-outs?
    The code itself takes 5 minutes, but grasping the task takes forever. A bit frustrating, but I'm glad it finally worked out.

    @Monadius, thanks a ton for the hint. Appreciate it.

  • Custom User Avatar

    I assume that you tried to solve this kata in Python. Use the standard integer division in Python (//): -57 // 36 == -2 and 62 // 71 == 0 because the integer division in Python is Euclidean.

    I agree with you that the kata description should be improved because there are several possible definitions for the integer division operation.

  • Default User Avatar

    it acctually should result in 0. Here is the step-wise calculation:

    Step 1: 4//9 = 0 (since, as per the specs, we are supposed to apply integer division to stay on a "happy path", so 0.444 would become 0)
    Step 2: 3*0 = 0 Voila!

    However, any which way you would get stuck with some other errors, since the evaluation logic sometimes applies rounding instead of the expected integer division (see my comment above).

  • Default User Avatar

    I agree with many aforementioned comments: the evaluation program is sometimes incorrect. Otherwise, I can't explain why it shows that my function returns correct values in 90%+ of the cases, but in the other few it's incorrect. For instance, here is one of the error messages I received: With expr = "-29 -1 74 -57 36 / + - *": 2146 should equal 2117 (I purposefully took a short test case to run a quick manual check).
    Let's do the calculations: step 1: -57/36 = -1.x, so given the condition the outcome should always be integer, dropping the decimal part. Hence, -1 is the result of step 1; step 2: 74 - 1 = 73; step 3: -1 - 73 = -74; step 4: -29 * -74 = 2146. To get the expected result, the division -57/36 should be rounded to -2, but that contradicts the kata condition (it doesn't say anything about rounding, just integer result). And that was just one example of mismatch. Ok, let's assume we should round the division results. I tried it that way, and ran into another error: With expr = "67 -34 62 71 / * *": -2278 should equal 0. There are no + nor - in the operators list, and the last step is multiplication. So the only way to get 0 is to get 0 as a result of steps 1 or 2. Clearly, it is expected to arrive at 0 at the step with division (step 1), when we divide 62 by 71. Which is how it should be (based on the kata specification). But it contradicts with the previous paragraph that the division should be rounded, not integer division! So either you run into one set of issues if you apply integer division or another, if you round the division results. Catch 22.

    Another uncertainty is the test cases when the divisor is equal to 0. What are we supposed to do about it? It should have been covered in the specs. Should we then leave the divident AS IS and move ahead to the next step or what?

    As an add-on: my code worked perfectly fine for "Reverse polish notation calculator" kata. The only change I made was to deal with floating-point numbers. Clearly there is an issue with the evaluation logic in this kata. It might have worked well sometime back, but not anymore.

  • Default User Avatar

    I think the evaluation program has an issue. I keep having the same error with my code: "With expr = "3 4 9 / *": 2 should equal 0". This expression should not equal 0. Same thing happens when I atempt to pass the kata...

  • Default User Avatar

    Ah my bad @hobovsky - I did a simple ctrl-F on both lists but the kata appear with the kata ID rather than name, facepalm. I blame 1 month of work on the farm, my brain needs a restart ;)

  • Custom User Avatar

    Interesting this is that both: this kata, and the kata you link, are listed on both lists :D Together with two other kata.
    Time to start a discussion on this group, it seems.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Approved

  • Custom User Avatar
  • Custom User Avatar

    Rust: Random tests never generate complex expressions (with consecutive operators) nor negative numeric tokens. I think this is feasible and not too hard (see the tests I implemented in Go and Python).

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Reopened with language details.

  • Custom User Avatar
  • Custom User Avatar

    Duplicate issue below

  • Loading more items...