• number % a == 0 and number % b == 0 evaluates to True if both are True
    number % a == 0 and number % b == 0 evaluates to False if either or both are False

    So there is actually a boolean being returned :P

  • Perl: Input is reference(\@array) rather than an array(@array).

  • Ruby 3.0 should be enabled, read this to learn how to do it

    Please organize the structure of test fixture as following (although it has been mentioned in the attached link, I'm repeated here again)

    describe "<This message should describe the categories of test groups inside this block>" do
      it "<A short message describing this test group>" do
        expect(...).to eq(...) #Assertions
        #Or Test.assert_equals(user_response, reference_response)
  • Approved ~~

  • Please don't force users to round values, it is a bad practice.
    Use proper testing of floating point numbers instead.
    In this case there is even some ambiguity on where to use rounding (taking the square root can produce non-rational numbers)

    I think a good rule for rounding is to use it only to display values with a reasonable number of digits.

  • Return a number, not a string.

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

  • I fiddle with everything, not just rank-appropriate kata. I can't even solve many high level kata. :P

    You can't assume order of operations, and that's what makes the difference. I used reduceRight for sum on purpose.

    I can't approve that fork; someone who's already a contributor will have to do that, because it's an approved kata. And it's not unique to the JS translation, it's just kata design with .. room for improvement.

  • Here's a fork for JavaScript

    All the other languages have floating point accuracy issues too. I tried messing with Factor a bit (and will probably try again) but there's an "approximate" test hook that should be added to the test suite and I don't know how to do some things with parsers in that language yet. It's compounded a bit by the number of layers that need either shims or alterations to get an epsilon ~ into a unit test. (A hacky way could be to sprintf a message and have many it#{ ... -> t } blocks)

    As a side note, I contributed to this kata expecting that most people at a 7 kyu kata are probably going to be using simplistic (* 100, builtin round, / 100) and/or standard solutions (Number.toFixed) and be highly likely to arrive at the same precision errors.

    That said, it's a lazy assumption. I've worked half a decade in/around financial systems and I agree it's not really acceptable to be so willy nilly with rounding and precision.

  • This happens because of floating point representation inaccuracy, and it's the kata's fault, not yours. Testing should have been done by comparing with a margin for error instead of rounding the result.

    Note that the order of operations when calculating the sum is not specified, so any order should be acceptable.

  • ( JS, probably others )

    This fork shows why you have to compare floating point values with a margin for error instead of comparing them with strictEqual. In this case, that margin should have been 0.01. Without rounding, it could have been much smaller.

    Rounding is not the correct way to address floating point representation inaccuracy.

  • Please see above Issue

  • Loading more items...