I am studying programming and not math. This is obviously a math problem and requires little programming skill. I have no idea why it's posted as a programming challenge.

Not at all. It's just relies on proportionality.

I think this problem should be ranked harder. It has a level of mathematical analysis that would probably be almost impossible for people who don't have a good understanding of calculus. It probably wouldn't be solvable by the average calculus student either (i.e. maybe the top third or quarter)

Although my first solution works, it does a lot of unnecessary work.

My fork shows one way to simplify this: we can match just what we need and avoid using capture groups at all.

This solution captures the first character in a sentence in the first capture group (p1). This single character is what gets capitalized.

Then I capture the rest of the first word, if any, and all characters upto and including the next literal period character followed by optional whitespace (p2).

This was captured to make sure that the next match for the beginning of the sentence starts in the right place. We don't actually change the p2 text, but we need to replace it unchanged since we matched it.

Fun kata ;) I agree with ranking this kata lower than 6, not for the final code but the analysis and test case debugging.

This filter-based solution is satisfyingly concise and clear but not efficient in space or time.

Consider if the array is massive, say one million elements.

Even if the outlier is near the beginning, this code iterates twice thru the entire array and makes a full copy of the input array partitioned between the even and odd arrays.

We then throw away almost all of the filter results because we only use the first element of one of the arrays.

If the outlier were near the beginning, this would be a tremendous amount of wasted effort and memory.

There is no need to use O(n) memory. The problem can be solved with O(1) constant memory.

The spec allows us to bail out of further processing once we find the outlier (i.e. assume correct input): e.g. if we find the answer on element 15 of one million, we can return it without traversing all of the remaining elements.

This is an excellent solution for discussing different trade-offs in developing a solution: e.g. concise code, readable code, time performance, space performance, etc

And also for raising awareness about which Array methods allow early bail out, like find, findIndex, indexOf, lastIndexOf, some, and every in contrast to methods that traverse the entire array like filter, map, reduce, etc, (unless you throw an error to a surrounding try-catch block).

This kata is unusual in that it requires using "bad practice" programming of relying on the implementation details that vary between JavaScript engines.

Probably, this kata is only available for JavaScript because of this.

As of 2020.09 it works on Firefox, but not Chrome, Safari or Node 12. It does work with the older version of Node used by the kata.

SEE: (MDN page for Array.prototype.sort)[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort]

compareFunction(a, b) must always return the same value when given a specific pair of elements a and b as its two arguments. If inconsistent results are returned, then the sort order is undefined.

By always returning 1 from the sort comparator regardless of the (a,b) arguments, we are returning inconsistent results which means the sort order is undefined (i.e. implementation dependent).

This is true for ES6 and ES2020. ES2019 made the big change to Array.prototype.sort to be a stable sort and it looks like some implmementations changed that broke previous behavior around the undefined sort order.

This is the first kata I've encountered that explicitly disavows correct, reliable code within spec.

I think it makes sense to annotate katas that depend on such unstable, bad practices to better inform learners that the kata should not to be used as a role model of good problem solving or coding practices.

This has a logic hole that apparently didn't show up with the test data.

If the target string to be reversed shows up earlier in the string, it will
be replaced rather than the one positioned in the desired index range from a to b

Consider this test case:

describe('extra', () => {
    it(`"ababababab",7,8 returns "abababaabb"`, () => {
        expect(solve("ababababab",7,8)).toBe("abababaabb");
    });
});

Expected: "abababaabb"
Received: "aabbababab"

This filter-based solution is satisfyingly concise and clear but not efficient in space or time.

Consider if the array is massive, say 100 million elements.

Even if the outlier is near the beginning, this code iterates twice thru the entire array and makes a full copy of the input array partitioned between the even and odd arrays.

If the outlier were near the beginning, this would be a tremendous amount of wasted effort and memory.

There is no need to use O(n) memory. The problem can be solved with O(1) constant memory.

The spec allows us to bail out of further processing once we find the outlier (i.e. assume correct input): e.g. if we find the answer on element 15 of ten million, we can return it without traversing the millions of remaining elements.

This is an excellent solution for discussing different trade-offs in developing a solution: e.g. concise code, readable code, time performance, space performance, etc

This filter-based solution is satisfyingly concise and clear but not efficient in space or time.

Consider if the array is massive, say 100 million elements.

Even if the outlier is near the beginning, this code iterates twice thru the entire array and makes a full copy of the input array partitioned between the even and odd arrays.

If the outlier were near the beginning, this would be a tremendous amount of wasted effort and memory.

There is no need to use O(n) memory. The problem can be solved with O(1) constant memory.

The spec allows us to bail out of further processing once we find the outlier (i.e. assume correct input): e.g. if we find the answer on element 15 of ten million, we can return it without traversing the millions of remaining elements.

This is an excellent solution for discussing different trade-offs in developing a solution: e.g. concise code, readable code, time performance, space performance, etc