And I thought I had some unorthodox solution

When operations are able to be chained like this, it's always tempting to reduce the line count of a solution, especially when the potential exists to reduce it to just a single line. When we do that, though, we sacrifice an opportunity to communicate to maintenance developers the significance of intermediate operations.

Here, for example, the significance of the split('') operation is left undisclosed, which is to deduce the "digits" from the original number. Applying the "extract variable" refactor to describe that significance is important in production-quality code.

(I realize "production quality" isn't always the intent of the solutions's author, but my statement is for the benefit of those who might otherwise mistake this solution's "best practice" rating as an indicator of perfection.)

Google how to sum the numbers from 1 to 100

Hmmm. Any guidance to share? Tried another method, same result __

.

You need a more efficient algorithm ;-)

[JavaScript] - The JS tests seem to go extremely high, web Repl's think it's in an infinite loop.. is this just failing because the servers stop executing? I've optimized a lot.

Passed: 19 Failed: 1 Errors: 1
Test Results:
Test Passed: Value == 30
Test Passed: Value == 9
Test Passed: Value == 495
Test Passed: Value == 0
Test Passed: Value == 3025
Test Passed: Value == 3025
Test Passed: Value == 3025
Test Passed: Value == -10
Test Passed: Value == 0
Test Passed: Value == 5
Test Passed: Value == -5
Test Passed: Value == 0
Test Passed: Value == 65650
Test Passed: Value == 66963
Test Passed: Value == 6506500
Test Passed: Value == 650065000
Test Passed: Value == 65000650000
Test Passed: Value == 6500006500000
Test Passed: Value == 650000065000000
Things begin to get really big, try console.log(max) - Expected: 65000000650000000, instead got: 65000000699999980

I've tried both reduce and forEach variants.

Works perfectly now...thank you!

I have re-published the Python version with the arguments in the correct order. This should resolve your issue.

Same issue occurs in the Python version in the random test. Expects a negative value when no negative values are in the test case. Code is successful with all other example cases.

I sent my solution through and edited the kata to fix the issue.

The issue was essentially, that the arguments were given in the wrong order in the random cases.

Thank you! There is definitely something wrong with the Ruby version.

Actually, after calculating your case myself, it should be -3155061.

It does appear there is some sort of issue.

Ruby will automatically control Fixnum vs. Bignum. No need for converting.

Take a look at my first comment again. 78*(29+30+31+...+152) can never be a negative number. There is definitely something wrong with the tests.