Ad
  • Default User Avatar

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

  • Default User Avatar

    I would advise against Object.freeze(Math) since that doesnt prevent just deleteing Math and redefining a new Math object.

  • Default User Avatar

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

  • Default User Avatar

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

  • Default User Avatar

    Codewars test framework already has a method for determining if floating point numbers are within a margin, use test.assert_approx_equals(actual, expected, margin=margin) instead of measuring the delta yourself.

  • Default User Avatar

    Random is not seeded with srand(time(NULL)), so the random tests generate the same output each time.

  • Default User Avatar

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

  • Default User Avatar

    The BigInt primitive is in stage 3/4 of the ECMAScript specification, and not all browsers/engines support it. The latest version of node to support it is 10.4.0 and since this kata doesn't support 10.4.0, the BigInt primitive does not apply.

  • Default User Avatar

    More accurately, it seems replaceSpacess is the name of the function that the test code uses to generate the expected solution, and that it was simply not included in the test cases. Thus, random cases can be bypassed by just making sure replaceSpaces and replaceSpacess return the same thing.

  • Default User Avatar

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

  • Default User Avatar

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

  • Default User Avatar

    If I am understanding the description properly, the test cases seem to be incorrect. If percentile = participants_you_are_better_against / all_participants * 100, then for each percentile, (percentile / 100) * min_participants should be an integer, as people cannot be fractional. However, both the fixed and random cases don't reflect this.

    In the fixed cases,

    50000 should equal 166667 given [93.234, 49.89]
    50000 * .93234 == 46617
    50000 * .4989 == 24945
    

    50000 works and is smaller than 166667. In addition, 166667 does not work

    166667 * .93234 == 155390.31078
    166667 * .4989 == 83150.1663
    

    166666.6 repeating works, but that would imply that non-integer participant counts are allowed.

    Some examples in the random cases:

    Tested on list [34.0, 87.694, 10.7]: 50000 should equal 1000.0
    1000 * .87694 == 876.94
    50000 * .87694 == 43847
    
    Tested on list [39.062]: 50000 should equal 500000.0
    500000 * .39062 == 195310
    50000 * .39062 == 19531
    
    Tested on list [21.0, 99.0, 22.0, 25.0]: 100 should equal 4.0
    

    Either the test cases are incorrect, or the description is incorrect

  • Default User Avatar

    Test #4's description is a bit off. Numbers 1-3 say lowerCaseLetters should be {expected}, but #4 says lowerCaseLetters should be {input}. If you would liked to show the input in the test description, maybe have something like lowerCaseLetters({input}) should be {expected} Also, #4 is not very good as a random test. The input is a template filled with numbers and the output is fixed, which allows for hardcoding. True random tests would be the best, but if you must use template based tests, then thrown in some spaces or capitals rather than just having the alphabet with two digits between each letter.

  • Default User Avatar

    Random tests could be implemented; although, it will not be an easy task to do.

    One-word search queries would be pretty easy. Generate a random word string for the text, and randomly pick or not pick one word from the string. However, multi-word random tests would be harder to accomplish.

    One way could be to use a fixed boolean search pattern, such as '({} AND {}) OR {}', and fill it with randomly generated words. You could then check using your own algorithm, and compare to the user's.

    There are probably multiple other better ways for implementing random tests. Anyone else have any ideas?

  • Default User Avatar

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

  • Loading more items...