perhaps a 3 random edge cases such as

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

could avoid this issue

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

Unpublished this kata.

@rickansen, check the comments in my solution :D

@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.

@Kacarott,

Thanks for responding, I think I need to made the concept of this kata clear first.

From the start, this kata is designed as a puzzle kata that can be perfectly completed by the means that the output should be reliably tested, easy to prove theoretically, and the process to obtain the output be technically implementable.

This kata does not specify explicitly on how Warriors (Users) should handle the problem, but provide clues (which should be interpreted as a suggestion).

This kata does explicitly tell Warriors what the expected output is and require the output of their solution to be logically same (in this case "whole number") and also providing examples of how the output should be structured or arranged conceptually/logically.

In my opinion, I admit that the story backing this case is not good, but I think it is decent to illustrate the case.

Any suggestion by anyone is welcome to alter this.

To add additional notes, this kata is inspired by

ACM-ICPC Indonesia National Contest 2012 | Problem C | Laser-Based Mosquito Killer

Edit: Using this comment to point out a typo in description: He have a task should be He has a task.

@Kacarott, updated this, thank you very much for correcting.

... calling it "opinion" is a massive insult to everyone involved in the beta process.

I believe both of the discussion below held responsible for this issue:

1. Issue

What's the purpose of w and h as input? They're irrelevant to anything, so they might as well be removed from the input parameters.

1. Response

The way you solve the case made them irrelevant.

Other people with different way may require it.

I will mark this issue as resolved, since this opinion-based issue.

Now, referencing to the reference in the case description, there's more than 1 way to create part of the solution and one of them required a boundary, that's where w and h will be useful.

So, when you say "might as well" (which I believe it should be raised as a suggestion rather as an issue), can I safely say "in your opinion they are not required to solve the case" without massively insulting everyone in this beta process?

If it's not safe, maybe you could propose a better or more proper/polite words I should choose and we can refer this issue as issue-5 in further discussion.

2. Issue

Random test quality is really bad: it's just scattering a bunch of circles randomly so in almost all cases the maximum range will be very narrow, often down to a single angle value. They really should be generated related to the angular span.

2. Response

Bad or good is relative.

A random test is there just to make sure that people doesn't cheat by copy pasting the expected answers and putting them into their code.

I will mark this issue as resolved, since this is opinion-based issue.

Referencing to The Codewars Docs > Authoring > Guidelines > Writing Submission Tests - Random Tests, where:

The goal of random tests is to make the expected return values and their order unpredictable so that only solutions that are actually solving the task may pass.

I believe I have created a random tests according to the community documentation.

But in this case, after thinking carefully, I do realize that my random cases does not reflect most of the possible scenario in the fixed tests, and I apologize for assuming that this is an opinion-based issue.

This issue is open and we can refer this issue as issue-6 in further discussion.

3. There are already 2 solutions that rounds numbers willy nilly to work around this issue, while some solutions do not. So essentially the same logic will cause different result to be returned just from the difference of the exact expression used for the calculations, which some are approved and some are rejected. This is, obviously, unacceptable (unless the kata is specifically testing for operations, which this kata isn't)

My apologize for not understanding this issue as a whole, I will try to respond partially.

The issue where same logic will resulting in a different output caused by difference of expression is a programming language issue, for example I have try in NodeJS v16.15.1 where:

1.1 + 1.1 + 1.1 + 1.1 + 1.1 + 1.1 which output 6.6

And then I compare it with:

1.1 * 6 which output 6.6000000000000005

Both of them are logically the same with difference expression, for this kind of issue I don't think there's something I can do.

If you would further elaborate on giving explanation or solution to this, we can refer this issue as issue-4 in further discussion.

2. At some point there will be a trigo or inverse trigo function invoked (in fact also a square root), and trigo functions are transcendental, so the result will introduce floating point errors. This is how I get the [0.00000000000001, 89.99999999999999]

Where the expected issue above is a continuation from the below expected issue:

Testing boundaries landing exactly on integral values like assert.deepEqual(solution(50, 50, [[25, 25, 25]]), [[0, 90]]); is a bad idea when lots of trigonometric operations with irrational numbers are involved. Floating point errors will push the calculated calculated boundary just below the integral value (I get [0.00000000000001, 89.99999999999999] here) and then the result would be different.

First, you can test assert.deepEqual([[0.00000000000000, 90.00000000000000]], [[0, 90]]) in codewars JS test framework and the result is a pass, you can even try 90.0 === 90 or 90 === 90.0 on JS and they would resulting in true, despite both of them is a different data type but in JS they are implicit, also they are the same conceptually.

Second, the output of your solution have fraction where the expected output from this problem is explicitly saying it must be a whole number.

Third, since your output [0.00000000000001, 89.99999999999999] does not include 0 or 90, I will gladly comply to the output of your solution, by changing the expected output to [1, 89] if and only if you can prove it to me that a circle with center of point located at x: 25, y: 25 and have a radius of r: 25 will not intersect or touch with a line that goes through point x: 0, y: 0 with an angle of 0° or 90°.

Because I can prove that a line that goes through point x: 0, y: 0 with an angle of 0° or 90° will intersect or touch with the circle at x: 25, y: 0 or x: 0, y: 25 respectively.

If this is still an issue, we can refer this issue as issue-3 in further discussion.

1. JS trigo functions use radians and not angles as input, so the input is already a floating point number

Yes, but this doesn't limit you to input a radian value that is converted from a degree.

The section "Notes" in the description "suggest" (by using the word of "should") you to check an angle that is whole number and does not refer to any specific technical details.

If you happen to have a solution that does not require this suggestion and comply to the expected output, then it would be great and further adding values to this kata for those who were able to see your solution.

If this is still an issue, we can refer this issue as issue-2 in further discussion.

Using integer degrees angle input only is completely unacceptable and irrelevant as an excuse of not handling floating point error

Please point in the description to show me where the case asked you to "only use integer degrees angle as an input".

Because I can only point in the description to show you where the case asked you to "output one or more pairs of minimum and maximum angle that is whole number" which in this case is in degree, the fact that the case itself does not have any inputs related to angle.

If this is still an issue, we can refer this issue as issue-1 in further discussion.