Create a function that will tell how many sentences are in a paragraph

 !!.undefined!.?undefinedundefined. 
 expected : 7

What kind of "sentences" are counted here ? ! ?

It seems the expected values are wrong.
EDIT:
Please clarify the following questions:
[[1,1]] intervals = what? === -1 or 0 or 1?
[[1,2]] intervals = what? === 0 or 1?
[[1,1]] add: [2,2] should became to what? [[1,1],[2,2]] or [[1,2]]?
[[1,2]] add: [3,4] should became to what? [[1,2],[3,4]] or [[1,4]]?

some more example test cases would be good.

Is this the same as this kata?

It seems familiar.

more example fixed tests would be nice and less random tests I'd recommend around 40.

Needs random test cases

Good to see random test cases being implemented this time but I just want to make sure that the description for this Kata is intentionally vague? Not that it's an Issue but if that was not your intention, I would suggest fixing the description to make it a little clearer what exactly is expected in the Task.

@ericswenson15,

Before I proceed to report the issue at hand, I would like to say this: good job on the random tests, I am very impressed! :D That being said, there is another Issue on this Kata that you may not be aware.

When dealing with floating point values in JavaScript, since floating point arithmetic is not commutative (e.g. 10 / 3 * 7 may not yield the exact same result as 10 * 7 / 3), when a user employs a solution (on this Kata or any other Kata involving floats) that uses a different order of operations than your reference solution, even if the two formulae/methods used are equivalent in real life, the float returned may differ just a tiny little bit (I'm talking about differences as small as .000000001 or smaller) due to the nature of JavaScript itself. Therefore, if you directly use Test.assertEquals to compare the two values, chances are that tests will unexpectedly fail all because of tiny rounding errors caused by JavaScript itself.

Instead, when comparing floats (i.e. decimals), you should adopt the following method / assertion:

Test.expect(expected === 0 ? Math.abs(actual) <= 1e-9 : Math.abs((expected - actual) / expected) <= 1e-9, "Actual value " + actual + " is not sufficiently close to expected value " + expected + " (accepted relative error: 1e-9)");

... where expected is the expected return value and actual is the actual value returned by the user function. Of course, since the code above looks cumbersome, you may want to define your own assertion method, like such:

function assertFuzzyEquals(actual, expected) {
  Test.expect(expected === 0 ? Math.abs(actual) <= 1e-9 : Math.abs((expected - actual) / expected) <= 1e-9, "Actual value " + actual + " is not sufficiently close to expected value " + expected + " (accepted relative error: 1e-9)");
}

... and then call it like any other test method, e.g.

Test.describe("Blah blah blah ... ", function () {
  Test.it("blah blah blah ... ", function () {
    assertFuzzyEquals(areaOfCircleRadius(5), Math.PI * 5 * 5);
  });
});

Looking forward to your other Katas, keep up the good work :D

Cheers,
donaldsebleung

You really shouldn't use Test.assertEquals to compare floating point values. (Test.assertSimilar compares on JSON.stringified values, so that's essentially the same thing.)

Floating point values are not exact, they simply can't ever be because of representation issues, so inaccuracy will at some point bite you.

You should either specify a precision (which is an unsatisfying kludge - it does not really address the inaccuracy of the representation) or use fuzzy comparing, where the absolute value of the difference between actual and expected values is smaller than some epsilon.

In this specific kata, you might get away with it. But if there's more ways than one to calculate floating point values, or order intermediate calculations even, different methods may yield slightly different results, within a margin of error (which is inherent to floating point representation. there just is no way around it). And the tests should not rely on the user solution using the exact same (order of) calculation as the reference solution; they should allow for that margin of error. So it's a very bad habit to get into.

Note that Math.round( i * 1e3 ) / 1e3 may yield results different from Math.round( i * 1e3 ) * 1e-3.

I did not expect to be able to Google for "react", but that actually worked. (I had no clue what React is. Yes, I'm under a stone.)

Not that that helped me much. I still did not know what to do.

Description was unhelpful, no examples, no example tests, so do something and submit and figure it out from there. Disappointment. Not with getting the necessary examples from the tests, they were there, but with the exceedingly trivial task. And with the inclusion of spaces around the parameter (why?).

So the takeaway is: please specify better just what to do, please include an example in the description, and please provide example tests.

The only reason I'm not including providing random tests is Donald has already done that. And he's right.

But, even if all these things were addressed, just what is the value of this kata? Do you really think there's anybody who doesn't already know how to wrap a string in a couple of string constants? Are you really just in it for the easy points? Is this what CodeWars has to spend resources on?

You probably know my mantra by now - your Kata needs randomly generated test cases at runtime. As long as you don't add those before you publish your Kata you're bound to receive these Issue reports which deducts your honor.

@ericswenson15,

I've just read the Gitter Codewars channel and learned of your objective here on Codewars. I'm totally fine with your objective of gaining as much honor points or ranking as possible within a reasonable amount of time but this is not the way to do it! As you may know now you gain 3 Honor Points every time you publish a new Kata. So according to your logic, if you just keep publishing simple, low-quality Kata at a fast rate then you'll eventually climb to the top of the CW leaderboard, right?

Let me tell you why your plan won't work. While you may have gained 3 Honor for every Kata you publish, you fail to realise that Honor Points are deducted for every Downvote (i.e. "Not Satisfied" votes) and every Issue you receive on your Kata, so if you publish a really poor Kata, you actually lose Honor Points instead of gaining them.

So, my advice: Unpublish these low-quality Kata of yours, try completing at the very least 10 more Kata from reputed Kata authors like @g964 and @matt-c and then try to mimic the way in which these authors author their Kata in the next Kata you author so by the time your Kata is published and goes into Beta no one raises a single issue. Cool?

Cheers,
donaldsebleung

P.S. By "mimic" I do not mean copy the exact idea from these authors. Duplicate Kata is another major issue that Moderators absolutely hate.

Test is synchronous and pointless because it's simply comparing the result of Test.inspect() with Test.assertEquals().
A solution that passes all tests without returning Promise.

const a = n => ({[require('util').inspect.custom]: () => `Promise { ${n} }`});

we were just having a conversation on gitter about quality kata and you come out with this.. Your solution doesn't even follow your kata. Please take time to create your future katas this as it stands does not contribute anything to the community other than free points.