It won't pass anymore.

Added some random edge cases for javascript. Also, random tests could produce arrays with a single number, not anymore.

Ideally, the random tests should generate a certain amount of such cases, to prevent hardcoding. It is not hard to do it.

perhaps a 3 random edge cases such as

case1 = [x, y, y]
case2 = [y, x, y]
case3 = [y, y, x]

could avoid this issue

Correct. Specific tests should be included to make it fail. Though I think this is specific to JavaScript (I have a doubt about Ruby, Julia, PHP and Dart, other languages should not be affected).

my solution should not pass, I have raised an issue about this.

Unpublished this kata.

@rickansen, check the comments in my solution :D

lmao what

why is it supposed to be called condoy numbers? just curious

Regarding issue-3 again, while the inputs and outputs are integers, dealing with floating point math is still required in any solution, which can lead to issues.

Consider for example, two users' code both checking if a line passes through a circle with radius 5. User 1 runs his distance function and gets a result of 4.99999999993, which is smaller than the circle radius, which means that the line probably goes through the circle. User 2 runs her distance function, and gets 5.0000000006. Now the question is, is the actual distance 5? Or maybe the actual distance really is something slightly larger than 5?

What this results in, is essentially both User 1 and 2 have to just run their code and try to make it match the reference solution. Did the reference solution get 5.000000006, or 4.9999999993, or maybe something else? And then, did it notice that it was very close to the radius, and try to round it, or did it leave it at slightly larger? If User 1 or 2's solution does not match the reference solution's way of doing things, then they will be stuck trying to debug a solution which actually works fine (just different from the reference).

To be honest, I am not entirely sure the best way to handle this, but one method might be to explicitely mention some fuzzy threshold, to make the floating point errors obsolete, and then make sure the solution used for the random tests follows this. (For example "Peoples visibility should have a tolerance of 10**-6" or something.) (Edit: thinking more about this, I am not sure this would do anything...)

Also, if you would prefer to chat more directly and perhaps get some opinions/insights from others, come visit the Discord server, there is a channel called #help-author.

@Kacarott, Regarding to the issue-3 on the part where you say:

@mohrizkyk Regarding issue-3, while asking for integer results might work here, the issue is that rounding/truncation can cause errors, which are often unexpected.

Correct me if I'm wrong, but I believe the need to round/truncate is caused by the unnecessary floating point numbers being used in the proposed solution to solve this problem, therefore it is an issue caused by the solution not the case requirements.

There is nothing wrong to try, but when the output of the solution does not logically/theoretically same as the expected output because of technical issue and there's no workaround for it, in my humble opinion I assume that solution is technically un-implementable.

And also (correct me again if I'm wrong), but I believe this issue (the need to round/truncate) is started from my response, which is:

In case of yours, where you get [0.00000000000001, 89.99999999999999] as a result, simply rounding them to the nearest whole number as described in the expected output would solve the issue.

So Warriors continue to assume that this kata require a rounding/truncating to solve, which in the first place this kata does not require them.

That response is solely used to suggest a solution to a problem where [0.00000000000001, 89.99999999999999] does not pass the test when it being checked with [0, 90] using assert.deepEqual without further knowing the complete solution is.

I also add further proof on issue-3 that it doesn't matter whether a float being tested with integer or vice versa as long as the value is same, if that was not enough proof I also try with assert.deepEqual([[Math.round(0.00000000000001), Math.round(89.99999999999999)]], [[0, 90]]); which is also pass.

If that happen to not solve the problem (or even causing more problem) when is integrated to their solution, it is better to ignore it and find another workaround or change the solution completely that comply to the expected output.

The standard for tests on Codewars is to rather use test assertions designed for floats, rather than having users truncate or round. I believe in JS there is something like assertApproxEquals (?). Have a read here.

Thank you for pointing me that.

But after I show all of my concept and the reason (possibly) of why this rounding/truncating issue arises, I do hope that my choice (with all proofs that I have shown) to use assert.deepEqual is clear to all beta reviewers.

I hope this response does not insult/offend anyone.