Ad
  • Custom User Avatar

    Note to self:

    Investigate later for pattern.

  • Custom User Avatar

    Nice kata but unfortunately some Elixir test cases are broken, for example:

    Testing input: "38691?+-198280=18863?"
    1) test Fixed tests More tests (TestSuite)
         test/solution_test.exs:51
         Assertion with == failed
         code:  assert Kata.solve_runes(s) == sol
         left:  0
         right: 8
         stacktrace:
           (elixir 1.11.4) lib/enum.ex:798: Enum."-each/2-lists^foreach/1-0-"/2
           test/solution_test.exs:64: (test)
    

    Proper solution is 4 in this case, which also works on my local machine:

    assert(4 = CodeWars.Numbers.solve_runes("38691?+-198280=18863?"))
    
  • Custom User Avatar

    I agree, there is no good balance in performance constraints between languages.

  • Custom User Avatar

    47848+-?39008=-5911?0
    47,848+-(100,000x + 39,008) = -(591,100 + 10x)
    47,848 - 100,000x - 39,008 = -591,100 - 10x
    -99,990x = -599,940
    x = 6

  • Custom User Avatar

    -1 is the output for when there is no valid solution.

  • Custom User Avatar

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

  • Custom User Avatar

    In Elixir, some test cases seem broken. All sample tests pass, but some later test in the full suite always fails, expecting a result of 0 when there is no correct result (-1).

    Example:

    1) test Fixed tests More tests (TestSuite)
         test/solution_test.exs:51
         Assertion with == failed
         code:  assert Kata.solve_runes(s) == sol
         left:  -1
         right: 0
         stacktrace:
           (elixir) lib/enum.ex:783: Enum."-each/2-lists^foreach/1-0-"/2
           (elixir) lib/enum.ex:783: Enum.each/2
           test/solution_test.exs:64: (test)
           
    Testing input: "47848+-?39008=-5911?0"
    

    In this case, not only does 0 not solve the equation, but it also goes against the rule that no number will start with a zero.

  • Custom User Avatar

    I don't like how the tests push the input size too high for many implementations. Some languages are more efficient with this and others will not pass even with decent algorithms.

  • Custom User Avatar

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

  • Default User Avatar

    Why is it not an issue ? The result is not the good one since D is not as small as possible.

  • Default User Avatar

    Not an issue with the kata.

  • Default User Avatar

    Why [[69, 130], [87, 1310], [3, 4]] should return [[18078, 34060], [2262, 34060], [25545, 34060]] and not [[3588, 6812], [435, 6812], [5109, 6812]] since Fraction(69,130)+Fraction(87,1310)+Fraction(3,4) --> Fraction(9177, 6812)?

    Can someone give me a hint on this one ?

  • Custom User Avatar

    Just like the description says, inconsistent tests between languages. It's a whole different problem from one language to the next. My language happens to be one of the PITA ones, so I'll pass on this one. Hope this question can get an update for consistency and a better description as well!