6 kyu
Calculate the area of a regular n sides polygon inside a circle of radius r
981 of 4,602Chrono79
Loading description...
Mathematics
Geometry
Fundamentals
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
This kata is an opportunity to raise awareness for the constant Tau, symbolized by T, which is equal to 2π. It's a nice constant. There are T radians in a circle. See? Very elegant.
It might already be handily defined right alongside PI in your programming language of choice. It is in Rust, for example, though sadly almost all the Rust solutions are using
2.0 * PIinstead :(Nice kata.
I believe that katas with "round a float to n'th digit" requirement and then comapring floats by exact values should not pass the review. Comparing floats by exact value, excluding some very specific cases, is always a huge no-no in software engineering, and it's actually a shame I see this nonsense too often on this website. I wish there was not only an advice not to do that, but an actual rule that would forbid such katas from being approved, unless changed in a way it works with floating numbers in a correct way.
Please read the discussion below your post. There are a lot of languages, some that I don't work with, so, if you want something changed, please, create a fork.
Don't round float results, use approximate equality tests.
https://docs.codewars.com/authoring/recipes/floating-point
I'll try to use approximate equality when possible without rendering all solutions invalid.
Python fork with backward compatibility: https://www.codewars.com/kumite/64e9eb3a787eda8d48013386?sel=64e9eb3a787eda8d48013386
Could I still ask for a 3 decimal places answer? Using approximate equality of course.
No, asking for a wrong result with a relative error up to 1e-3 when simple floating point calculations have realtive errors of 1e-15 – 1e-17 doesn't make sense and doesn't respect codewars guidelines.
Well, I don't want answers with a precision greater than 1e-3. And it's not to try to avoid floating point problems so I disagree that doesn't respect the guidelines.
I saw the python fork and approved it without seeing this discussion (sorry). But I also think that asking for 1e-3 precision is effectively exactly the same as rounding to 3 places, with all the same issues. Unless you mean setting the tolerance of approximate equality to be 1e-3? This is probably fine (though I don't really see the benefit), but even then I don't think that you should be asking for 3 decimal places in the description, because that still implies that solvers need to round/truncate.
I'll remove that once all languages have been updated. I didn't like from this translation the huge amount of decimals. I'll replace it with the previous version. About being the same, no, they're not because one allows answers with a lot of decimals and the other don't.
I don't want this:
I want this:
FLOAT RESULTS SHOULD NOT BE ROUNDED
This is a big issue and there are only two solutions:
If you don't like decimals, don't write kata with float values.
AND THEY WONT!!!!!!!!!!! WHO TELL YOU OTHERWISE?
And not, they're not the only options, I am the author and I can do with the kata what I want, not you. I can ask for an answer with a precision of 3 digits and that won't be against any guideline. If you measure the radius with a precision of 3 decimals, more than those decimals have no meaning in real life, that's why I don't want answers with 10 decimals, THEY HAVE NO MEANING IN REAL LIFE. I'll allow answers with more than 3 decimals and they'll work too. So I don't see it as an issue at all.
I don't want this:
I want this:
The issue is that you are still rounding or truncating values, which is what I meant by it being basically the same. Whether you round to 3 decimal places, or 10 decimal places, either way you are actually setting up edge cases which require absolute precision and such a thing is impossible with floats.
As an example, lets assume your solution (before rounding) calculates a result to be
11.5524999999999999999998. You will round it then to 3 decimal places, resulting in11.552. Now lets say someone else does all the right math, but due to a slightly different way of doing it, ends up with11.5525000000000000000001. They too will round the result to 3 decimal places as it says in the description, but they will a result of11.553. So they will fail the test, despite being only3e-18different from the expected solutions (before rounding).Allowing solutions with more than three decimal points also doesn't really work, because you are effectively changing what the expected solution is. For example if your reference solution is reduced by
0.0004during rounding, then it means that solvers solutions can only be0.0001above the "true" solution, or they can be0.0009below it. I also think that having all the tests rounded will strongly lead solvers to believe their solutions need to be rounded anyway.Obviously many decimals have no meaning in real life, and for a real life program you could simply round, however when the purpoes of the tests are to validate the correctness of other code, then it becomes important.
About the rounding requirement (I already answered to that):
If I use an approximate comparison like I posted above, both answers are valid. I'm fine with an approximate answer.
I've done a few tests with the proposed approximate comparison:
It allows answers in the range 3.857 - 3.863. I don't think rounding one way or the other or not rounding at all is a problem there, isn't it?
it might not, akshually. you need to make the tolerance slightly larger:
oh you gave a range of size 0.006 .. I don't see how that works but in that case, sure.
As weird as it seems, with a tolerance of 1e-3 the assertion allowed that. I thought it would allow 0.001 of difference but no. Here is the doc about how it works: https://docs.codewars.com/languages/python/codewars-test/#approximate-equality-tests
It depends on the values because the difference is divided and then compared against the margin value.
This comment has been hidden.
Could you make a fork with the fix? I don't do NASM. Or the fix is simply adding
staticbefore the reference solution? If it is, then it's done.That's all, thanks.
No problem, thanks for reporting it.
Nice!
Can't complete 4th random test, Java.
You could reduce the number of divisions in your formula.
This comment has been hidden.
Description should be language-agnostic
I got a problem with a random test, the exercise, says i should round to 3 decimals, which i do, and pass the basic tests, but a random test #5, with the parameters radius = 2.3921963039767293 sides = 17 Expected: 17.571999999999999d But was: 17.571000000000002d
So my guess is that random test #5 dosn't have the 3 decimals.
Which language are you using? What's your code? Please read this: https://docs.codewars.com/training/troubleshooting#post-discourse
C#
Added some tolerance to the tests but you're truncating and you should be rounding instead.
The tests don't work for this ... anything passes them and there are a few incorrect solutions already submitted. I'm pretty certain the tests should say assertEqual instead of just assert
Which language?
JavaScript ... anything seems to pass atm
Thanks, fixed.
Wow, that was fast! Nice one. Need to fix my solution with the right rounding now!
Not a huge fan of math katas but I enjoyed this one because it was straightforward and well-described. Thanks.
You're welcome.
I like the math katas' on codewars like these, really help brush up my mathematic skills in a very interesting and thinking out-of-the box way!
more like a 7 kyu or 8 kyu kata.
Without googling for formula?
I mean formula should not be part of the coding difficulty. This site is not for testing your math knowledge. Plus, if you have learned basic math, the area formula is easy to induce without googling. (not that you should. you can google it)
Added an NASM translation: https://www.codewars.com/kumite/629e5c2f3bcb990ca1818472?sel=629e5c2f3bcb990ca1818472
Approved.
Created a Golang translation: here
Approved, thanks.
I think for dart have to mention PI equals to 3.14159265359. I tried just 3.14 didn't work, then 3.14159 same didn't work.
Added a note to the description.
This comment has been hidden.
Python, JS, Java, C++, and maybe others: float values for radius are only tested in fixed tests (just once in JS, Python and Java), random tests only give integer values (or double with no decimal part in typed languages). It doesn't make sense.
My code is able to pass all the random tests when I press attempt but it fails the first test case of the basic test (sample test case).
It is shows the error as follows:
Expected: 11.691 Received: 11.691 for area_of_polygon_inside_circle(3, 3)
My program's output and the expected output is the same but this error pops up for no reason.
I guesss there is some bug or some issue with the test-case checking.
Which language?
C
Try again.
It's working now! I'm able to submit. Thanks!
This is a very mathematical kata.
There is a rounding up problem in python.
Post your code using markdown formatting and mark your post as having spoiler content.
You're not doing that.
thanks !
This comment has been hidden.
Try again. I've used
cr_assert_float_eqwith a tolerance of 0.0001 in random tests now to compare your result and the expected one. Copy your code to some other place, click reset and paste it again and then click submit.Seems your code passed now, I'll mark it as resolved.
Yeah, thanks a lot
booooring
Failing on randoms. The issue with that is there's no indication which answer is expected, it only says "The expression (area_of_polygon_inside_circle(r, n)) == (sol(r, n)) is false."
It would really help if you mentioned which of the 18 available languages you're having this problem with.
Very sorry about that :-) This is using C.
I've changed the format of the error messages in C, try now.
Excellent! Thank you.
I got the same problem with java language. My results are ok with the tests, but when I get to Randoom test the value usually varies. Can you help me pleade?
Tanks and Greetings.
That's weird, Java already compares using a tolerance, could you post your code using markdown formatting and marking your post as having spoiler content? I'll take a look then.
Haskell translation
Approved, thanks.
For the Swift version of this Kata (and pretty much all katas that look for floating point results), rather than specifying that the result be rounded to three decimal places (which can still lead to weird floating point equality corner cases), the tests should instead XCTAssertEqualWithAccuracy(::accuracy:) for Swift 3.1 and XCTAssertEqual(::accuracy:) for Swift 4.
Thanks for the suggestion, I'm not sure how to implement the different tests for different versions tho.
Added accuracy to Swift tests.
I've tried doing this in Java but I fail on random tests.
I've searched for most precise methods of doing this and avoided common imprecise rounding methods. I've analysed the values and calculated the areas by hand and I stand with the results my code produces.
Could you please take a look at the Java TC's translation?
The java version seems correct though. What are the assertion messages you got?
It varies because I have several solutions.
Generally speaking I rounded it with several different methods, and at different levels - i.e. in one test I've only rounded the final result, in other tests I've rounded all the multiplied values, in yet another I've rounded only some of them.
The higher the precision* I've kept, the bigger the gaps were. I've received the "consistently closest values" (i.e. difference of 0.05 not 0.5) by doing the "appropriation" and not even the roudning by using the following imprecise formula: Math.round(value * 1000d) / 1000d;
I've verified some of the results manually and for the method that I've thought should give the highest precision I've had same results as on Google's and Microsoft's calculators. If I am wrong, please hint me the right method of how is rounding done in Java.
*"precision" is pretty relative as I am definitely not an expert it this field
Rounding method seems ok, if you get differences that high, the problem isn't in the rounding part. Try pasting your code and marking your post as having spoiler content for us to check it. You should only round the result.
Thanks for clarification, knowing that I am expected to round only the final results and not the partial results will definitely assist me in debugging. I'll try to handle this myself first, thank you for your assistance!
I can't seem to pass the random tests, even though the values returned by my function are exactly as expected. Here are some examples:
Expected: equal to 601.829
Actual: 601.829
Expected: equal to 991.915
Actual: 991.915
Expected: equal to 488.84
Actual: 488.84
What could be the issue?
State which language you're trying and could you be returning a string instead of a number? Paste your code and mark your post as having spoiler content so I can check it.
This comment has been hidden.
I'll look into it, your code seems ok, it's a problem about the rounding method. @MrZizoScream any idea of how to fix it?
It should work now.
Yes, that worked! Thank you!
May I know what the problem was on your end?
This comment has been hidden.
I discovered something weird with Ruby: it will compute (1/2) * 3 and return 0. It has trouble with any fraction expressed as (a/b) where a and b are integers. Why is this?
Integer division
Added java translation.
This comment has been hidden.
Rounding function seems ok, maybe the problem is in the rest of your code. I agree the error message isn't helpful in that case.
If you're printing
doubles in scientific form you should print it to at least 15 digits or something. 6 digits is far from enough to resolve tiny differences.I've lowered the radius values for C++ random tests, could you try again?
It works now. Thanks!
Added CoffeeScript and TypeScript too.
Consider renaming all references of circle with circumcircle (or circumscribed circle). This is the proper name for the unique circle that touches every vertex in the polygon, and in which we are interested. Other than that I enjoyed this kata! :)
Added to the description (thanks for the info), is that ok?
It's perfect now! ;)
Added Crystal translation too.
Added Swift translation, let me know if something is not ok with it.
Looks good, though personally I would have preferred leaving the argument labels in (since it's very hard to tell what's what in
areaOfPolygonInsideCircle(3, 3), but it's obvious inareaOfPolygonInsideCircle(radius: 3, sides: 3)), but changing that now would break existing solutions so oh well.Objective-C Translation Kumited - please carefully review and approve :D
Approved :+1:
Congratulations My Friend For the First Kata .... Waiting For Mooooooooooooooore ... Challanging Yet easy to translate hahhahahaha ... wish you the best bro ..
Thanks.
Should be 7 kyu... :o
Good kata!
Please add the word "regular" to the polygon. Imagine a non-regular polygon, for example a rectangle of 6x8 in a circle of radius 5. It has area 48, but you expect value 50 from a square.
Done.
C++ Translation
Review and Approve ...
DiegoThanks For This honor Translating my hero Katas ..regardsFor PHP, basic tests, but random tests fail.
Random test #29 : radius = 22, sides = 9 Failed asserting that 1399.991 matches expected 1.0.
Could you please look into it?
Yes, I'll look into it.
@Chrono79, Test solution was forked and editted, please review it again. =]
This comment has been hidden.
@accord75 could you try again?
This comment has been hidden.
Thank you. It works fine now.
C# Translation Kumited - please carefully review and approve :D
Congrats for your first kata. In my opinion it's 7 kyu.
I ranked it lower, but that's the result of the average beta ranks. Thanks.
Yes, I know that it doesn`t depend on you.