6 kyu

String Evaluation

238 of 490sataman
Description
Loading description...
Strings
Algorithms
  • Please sign in or sign up to leave a comment.
  • saudiGuy Avatar

    python new test framework is required. updated in this fork

  • farhanaditya Avatar

    The description should mention how to interpret the condition when:

    1. The left character is a digit and right character is non-digit
    2. Both left and right character are digits.
    • Kees de Vreugd Avatar

      Are you creating issues just for fun? The description is chrystal clear. You know how to evaluate a boolean, right?

    • Ciprian Amza Avatar

      You should assume all three cases: a < b (counts of b > counts of a), a < 3 (counts of a < 3) and 2 < 3 (integer comparison, True in this case).

    • Ciprian Amza Avatar

      This is written in the description: "The conditions will be passed in an array and will be formatted like this:

      {symbol or digit}{comparison operator}{symbol or digit}"

      Issue marked resolved by Ciprian Amza 3 years ago
  • dagolinuxoid Avatar

    This comment has been hidden.

  • kingcobra Avatar

    I think the description could be more precise if you also gave an abstract description of the conditions, e.g. "Each condition will be of the form {symbol or digit}{comparison operator}{symbol or digit}".

    Also, I do not think cases like '0==7' should be tested, since they have nothing to do with the string.

  • KenKamau Avatar

    Javascript translation

    Can someone approve?

  • zebulan Avatar

    @sataman,

    I enjoyed this kata, thanks!

    Suggestion:

    I found your example test cases a bit hard to read. It seems like you split the test cases into different lists to give a user more information if there was an error.

    • By default, the error message seems to already take care of informing what the users output was, compared to the expected output
      • "{actual} should be {expected}".format(actual=actual, expected=expected)
    • You added two other lines describing the two input variables, but with only 2 tests (in the example test cases) that information already seems quite obvious to me

    My suggestion would be to re-write the example test cases something like this:

    test.assert_equals(string_evaluation(
        'aab#HcCcc##l#', ['a<b', '#==4', 'c>=C', 'H!=a']),
        [False, True, True, True])
    test.assert_equals(string_evaluation(
        'abc#$%KDAyyaa@@@', ['#>@', 'A==2', 'a>A', '$!=2']),
        [False, False, True, True])
    test.assert_equals(string_evaluation(
        'abb', ['a>b', 'b==a', 'b<=a', 'b>a', 'b!=b', 'a==1', 'b==1']),
        [False, False, False, True, False, True, False])
    

    In my opinion, it seems easier to read and a user can figure out exactly what both inputs are and the expected output. I split them up that way so there weren't any PEP8 warnings for lines longer than 80 characters.

    Thanks!

  • suic Avatar

    Great kata! Thanks, suic