7 kyu
Area of a Circle
3,850 of 12,307austinc
Loading description...
Fundamentals
Algorithms
Geometry
Mathematics
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.
Lua translation!
Sample and fixed tests such as 0.23 and 0.785 should be added across all languages to invalidate such solutions
Description should be language-agnostic
Error messages are confusing, at least in javascript:
This comment has been hidden.
I noticed this but I have no good idea how to prevent this. The crappy message comes from Chai :( I will try to figure something out, maybe craft my own assertion.
Not a lot better but, what about this?
That shows this error:
@hobovsky did you see this?
Uh sorry for not answering, but yes, I've seen your proposal. I wanted to create a fork to test it out but got busy and never got back to the topic.
It would be cool if oyu could at leat create a fork to test the approach, or even fix the issue right away. If you can't then I will, but I do not know exactly when. I have the issue in my backlog nonetheless.
This comment has been hidden.
I am facing the same ppl bro did the author fixed it ?
Was really confused by "raise ValueError" part. Tried to do it as usual in try: except: blocks. The code worked fine locally, but not here in Codewars. This kata tests should either include tests for another methods of raising ValueError or change description. For codders to come: do not use try/except here. You'll find the right way quicker to get through this kata.
but... what are the "another methods of raising ValueError"? You confused "raising an error" with "handling an error" -
try:/except:is used to handle errors raised by someone, somewhere, and not to raise errors. The description asks users to raise an error and not to handle an error, and this should be enough of an explanation thattry/exceptin your solution is not needed. How would I have to change the tests or description to help with such confusion?(solved)hi! i ve same problem, i cant raise ValueError, try- except block for not raising error, i hope it does not ask we write something for error. anyone solved this issue?
OK. Not everyone (1 dan) yet here. Searching for 'raising ValueError' and code skills previously learned lead people to try:/except: solutions. None of which, obviously, works. And these katas are for codders who are not expert-super-duper pros. They are for novices. That is why a helpful hint in description of the kata, or a hint in test evaluation would be much appreciated by them. To that, I admit, that I confused "raising an error" with "handling an error". Now will remember the difference. Thanks.
There's the official documentation you know...
Thanks. I do know about documentation. Please, take trouble and read it (your link). From the first page you've got try:/except: examples of raising ValueError. What I suggested, might improve this kata and Codewars in general. If there would be less trouble with single instances (katas), the better resourse it would be. Yours (1 kyu rating) is not for being toxic, right? :-)
Well, the docs are very clear when it comes to explaining the
raisekeyword. This is the standard, most acceptable way of reporting that something went wrong in the code. What would you suggest instead?I'm not trying to sound condescending (and I hope I'm not being toxic here!), but I don't understand how you could possibly use
tryhere.Should this maybe be 8 kyu?
Ruby: strict equality assertions should be changed to fuzzy equality.
Fixed.
TypeScript translation (literal translation of JavaScript; author inactive)
Approved.
It is not described what value should "pi". "should test for something" error, isn't that testmakers job? Overall badly made kata.
What else the value of pi be than, uh, pi?
With a precision sufficient to fulfill requirements regarding accuracy of returned result.
Both 3.14 and actual pi return results that wildly differ from test results.
3.14 is not precise enough and will cause inaccurracies.
I am not sure what you call 'actual value of pi' though.
What else the value of pi be than, uh, pi?
Yes, obviously. What I meant is that it's not clear to me what value exactly you use in your code when you mention "actual value of pi'.
Additional thing to notice: I changed tets a bit, added sample tests, and changed some other things. You might want to back up your current solution, refresh the trainer, click "reset", and see what kind of errors you are getting now. Also please read the description again, because it changed too. If you still cant get your code to work, just show what you try (remember about code formatting and spoiler flag).
Kata is underspecified for C#:
ArgumentExceptionwhen argument is invalid, and not return a boolean;Should be fixed.
Floating point comparison should be enforced in all languages
Done for Java. I will try to modify all remaining languages too.
Done for C#.
Haskell already uses approx equality.
Done for Python.
Done for JS.
Done for CoffeeScript.
I'm going to close this one and re-raise explicitly for Ruby because it's the only language using strict equality now.
Agreed
[Node v18.x translation] (https://www.codewars.com/kumite/644b81234bdc9a00415da444?sel=644b81234bdc9a00415da444)
Test is broken since there's no actual test - someone may want to fix that?
There's no sample tests, but there are actual tests when you hit "attempt". Sample tests didn't used to be required, and this is a pretty old kata (2014).
Added sample tests to JS version.
PHP translation
rejected by someone, and the author closed their account
Some tests in Python have a wrong error message, if you need to calculate the area, and you calculate it wrong, why would you get "Incorrect radius" instead of "Incorrect area"?
Fixed.
pleaze help, i got the result: "Incorrect radius: 28010755666909.71 should equal 452.39", but why?
You're not using the right formula to calculate the area?
Thanks, i checked my formula, it was incorrect
I forgot to rounded and my solution passed succesfully...
For Python 3.6 the test option is buggy, only the attemp option can be used.
fixed
The same is true for Javascript.
Description is not correct for Java when comparing to test cases.
Fixed.
Python version should use snake_case.
In Java you need to throw new IllegalArgumentException if radius <=0 .
Good luck :)
Issues with Java version:
false" while tests expect anIllegalArgumentExceptionFixed.
it says return 'false' if the radius is not a number but c# wants a double being returned and 'false' isnt a double so gives an error
I've just raised a more specific issue about this.
some thing about round() in Kata?? Noooo
This comment has been hidden.
C#:
This should really be part of the description and not come as a surprise last minute test case.
Inputs are not strings anymore.
✘ Returned string - Expected: 23440.86, instead got: 23440.86...LOL what is this question :D
This comment has been hidden.
How i must return false in Java?
You can't. But you can throw Exception. Check test's code.
CoffeeScript translation kumited! Please accept :D
approved some time ago
This comment has been hidden.
toFixed returns a string not a number.
The description is completely wrong for languages as Java or C#. It doesn't work for numbers between 0 and 1, also doesn't say anything about throwing exceptions.
+1
We should definitely update the instructions to say that the C# exercise requires you to throw an exception. This has caused lots of confusion.
This comment has been hidden.
what value for pi should we use?
How do I get it to throw an Argument Exception? Seems like everything works with my code but I'm not getting the proper error codes that the kata wants. I'm using try, catch, and throw but I can't seem to get the ArgumentException that it stupidly needs. Pretty annoying actually, this is not a helpful problem.
you should write throw new ArgumentException() ; to throw it.Check your code-maybe you wrote throw new ArgumentException; without paretheses or throw ArgumentException();
The description says "fuction circleArea" while the test case uses "area".
You can't return a boolean in a function that is supposed to return a double...?
Hey, I see that the results for this kata was as expected but the test results indicate as failed. What am I missing here ?
Returned string - Expected: 13592.24, instead got: 13592.24 0 Passed 1 Failed 0 Errors Process took 56ms to complete
Check to see if there's a space at the end of your returned string. This was an issue on a previous KATA, could be your issue as well. Also maybe you're supposed to return a float or int? Are you sure its supposed to be a string?
I missed the float , yes. Sorted it out later. Thanks for the response !
Would recommend updating discription to say throw IllegalArgumentException instead of return false.
Maybe it's a silly question but how can i return a double when the output type of the method "area" is a boolean?
There should be test case for max number of long range ...
Incorrect! For input string: "14,604.049492"
Are you bloody kidding me?????? Where is my error message, what is the expected value? What is going wrong at all. This kata is a TERRIBLE fit for java. Improve!
Shouldn't the provided solution check for "radius <= 0" instead of "radius < 1"? Somebody might go ahead and offer a radius of "0.223" which is per se not a negative number?
Which language?
CSharp
Ah, you're talking about this solution? It's better to comment on the solution directly in this case. This kata doesn't check numbers in (0,1), so that solution passes the tests. But yeah, it would fail on
0 < r < 1.This is actually an issue, raised 8 years later :-)
nice.....thanks....awesome.....yes....nicee..
I would also add some test with "r" being Fraction and Decimal.
This comment has been hidden.
getting this error, /CircleTest.java:19: error: no suitable method found for assertEquals(String,double,String,double) assertEquals("Wrong area for radius: " + x, (new BigDecimal(Math.PI * x * x)).setScale(2, RoundingMode.HALF_UP).doubleValue(), Circle.area(x), 0.01); ^ i have only the default test.
If the string has a ',' throw that argumentException ;)Taking away default functionality doesn't make you clever.
My tests pass, but I get "Unknown Error" when I try to Submit.
The requirement to not support thousands commas should be in the description.
Is it just me, or is anyone else getting "submission time-outs" when trying to test the code? It won't let me test this code for the life of me....
See this page for more information about "Submission timed out". That being said, it's usually a temporary problem. If the problem persists, make sure to notify Jake as mentioned on the page.
By the way, the response time on the status page is currently not available, so there's probably a hiccup.
This kata made my skin crawl. Check your basic math: zero is a perfectly valid positive number. So the description should be "non-zero positive number". If comma notation shouldn't be supported (which is kinda silly, really), that should be in the description too. The "two decimal places" thing is where the skin crawl really begins. Floating point numbers simply don't work like that. Would have made more sense to expect a string result.
I would expect the katas here to promote good coding behavior instead of enforcing that kind of behavior that will come back to bite you at some point. Sad face.
[Python] The tests field was empty. How about you put this there?
Not anymore
The description for this kata talks about returning false when the haskell version should return Nothing - that is obvious from the test, but the description should be updated.
In addition, the C# version should say the requirement is to throw an ArgumentException under these conditions.
Fixed.
If you only support "Dotted Notation Format" then please say that before the test that also gives the annoying smiley.
Another poorly written kata.
"Returned string - Expected: 4258.15, instead got: 4258.15" ??
Please improve the description so we know exactly what's expected.
You're returning a string instead of a float.
Thanks for the tip!
So I'm a bit confused by this error:
like, shouldn't these match. I'm returning a double (or not) with an if statement. Shouldn't the
circleArea :: Double -> Maybe Doubleallow a double or a non-double to be returned?yes-ish... it is not about "a double or a non-double" but about "just one double or nothing".
a
Maybe Doublediffers from aDouble. aMaybe ais like a list ofas with at most one element.let me hoogle that for you... https://www.haskell.org/hoogle/?hoogle=Maybe
Thanks for replying, although I'm not finding that helps. I've tried returning a Double or Nothing, or a list with a single Double or a single Nothing, and I get exactly the same error ... :-(
I guess I'm going back to a Haskell tutorial ...
ah, so it seems that we have to have Just to go with Maybe; which I did not find intuitive, but this post on SO helps ... http://stackoverflow.com/questions/18808258/what-does-the-just-syntax-mean-in-haskell
The OP found an answer to their question.
There is a requirement to round the result yet it is not tested by final test cases. I forgot for a while and submited solution without formating which was accepted. Solutions of other warriors are how we learn stuff here. Therefore we should try not to let "wrong" solutions pass the tests here ... I think :)
Hi,
Is there any explanation why the below error is occuring although my code is working fine in other interpreter & browser JS console:
Returned string - Expected: 1089.46, instead got: 1089.00
I understand it returned string value rather than actual number value; I would appreciate if it can be resolved;
you can use + before your returned value as +(result) that cast it to number, even you can use Number(result)
Mentioning the wanted precision in the problem description would be nice.
Or, even better, having tests that check if the answer is close enough, rather than expecting absolute precision in calculations with floats.
Returned string - Expected: 3440.29, instead got: 3440.29
:(
This comment has been hidden.
The same issue: Expected: 10184.37, instead got: 10184.37 Fixed. Hint : check the type of result. it should be Number, not String
Java version desperately needs clarification in descripton. It asks to return a number or false. I didn't realise before after implementing object returning that its actually asking for IllegalArgumentException.
^This!
This comment has been hidden.
Because
(int or float)will always be true.You probably wanted
isinstance(r, (int, float)), although typechecking is rarely the correct solution in Python.No more mixed types for inputs.
This comment has been hidden.
Have you tried hitting the Submit button rather than Run Tests? My test case was just the function and gave me "Unknown Error." This is due to not using Test.assert_equals(circleArea(1), 3.14) function inside the test case window. But hitting submit uses the test cases of the author instead of your own, thus passing the test if your code works. Which it looks like it does.
Well... that worked! thank you for your suggestion. I would have never guessed that this could be why I got the Unknown Error! Passed all the tests now - Moving on to the next Kata :)
I also can not commit my answer , but I hava a test in Chrome-Console,it pass,here is my code (javascript):
var circleArea = function(radius) { if(typeof radius != 'number' || radius <=0) return false; return (Math.PIradiusradius).toFixed(2); };
This comment has been hidden.
And yet your solution works, I wonder
The description doesn't say whether it should return
falseif the radius is a string containing a number. ShouldcircleArea("5") === circleArea(5), or shouldcircleArea("5") === false?It says that if the radius isn't a number, it should return
false, but due to Javascript's loose typing, it's not clear whether"5"should be treated as a valid radius or not since it's actually a string. Many of the Javascript solutions will treat it like it's a number.The description needs to be updated to add examples showing whether a string should be treated as if it's a number or not, and some test cases should also be added to test that.
Non-numeric inputs have been removed from JS version.
Returned string - Expected: 2253.18, instead got: 2253.18
So broken.
P.S.: JS.
I probably should have worded the error messages more clearly. By "Returned string", it means your function returned a string instead of a number.
It helped, but i don't understand: were test inputs partially strings? Cause if that's true then you probably need to fix instructions, and if it's not then i don't understand, for i only performed mathematical operations on it, no forced type coercion.
(Number).toFixed(2)=> returns a stringYou're not supposed to return a string, so you have to convert that string back into a number if you've used
toFixedto round it.Ah! Thanks for this.
Test cases really suck for this Kata (at least in Java version). There are plenty wrong solutions accepted that don't round up the result.
I found an issue with the java test cases as well. The instructions direct one to return false on zero or negative radius, but the default test cases expect an IllegalAgumentException to be thrown.
This comment has been hidden.
Fixed.
This comment has been hidden.
I didn't round the numbers and it accepted my solution, please fix it :)
It can be done simply by lowering delta:
or by comparing strings:
The task description for Java should mention that an
IllegalArgumentExceptionis expected to be thrown in case the radius is not valid. Instead, it suggests thatfalsebe returned, which is clearly not an option here...Fixed.
Returned string - Expected: 6389.24, instead got: 6389.24 ???
This comment has been hidden.
You must return a number, but toFixed() returns a string.
This comment has been hidden.
toFixed() returns a 'string' and you need to return a number.
Can anyone explain how type checking works here? Top solutions don't check for number's type. They just check for " > 0". Does it cover every possible case? So whatever input we give, if it's value is > 0, then it's a number?
can we check the radius is the number type using "typeof"?if the radius's type is "number",then we can use the if-else again?
I got "Test didn't pass: Unknown error". But i'm doing well using repl.it and my local node server ... Need help!
There are two buttons, Run and Submit:
"Run" is there to run your test cases. Since the default test cases are empty, "run" doesn't work. Instead, use "Submit". If you want to check your code locally, add your own test cases.
If the error persists, add your solution to the discussion, but mark it as spoiler.
You might want to revise the description to specify that the radius must be positive. Currently it says it must be non-negative but then fails if a radius of 0 is calculated and returned.
This comment has been hidden.
Your solution return a
string, not anumber.This comment has been hidden.
A number
.toFixedis rounded not truncated ( see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed : The number is rounded if necessary )The return value (at least for the top two solutions is a
number, not astring.I think you may mark issue resolved.
This comment has been hidden.
All numbers in JavaScript are floating-point -- they are not completely accurate. Try a few different ways to round and you should be fine.
What happens when the given radius is not a number? I expect you get some sort of error, but I'm not sure which error. ;-)
My solution returns the expected value properly, however still receives an incorrect response. Here are two examples: Returned string - Expected: 7248.43, instead got: 7248.43 Returned string - Expected: 11905.95, instead got: 11905.95
It seems that all my tests also pass when using Test.assertSimilar while Test.assertEquals will mark my two place decimal responses as receiving what is not expected. I believe it may have something to do with the way I have truncated the return to two decimal places. Is it part of the challenge to return the expected number in a particular way or is this a bug?
Corrected my solution to return an integer as opposed to a string. If it is part of the challenge to require the return of an integer as opposed to a string, could you also put it in the details? Also, I read below that you updated the error messages to account for returning a string result when it expects a number however it was not working for my submissions. Just FYI.
I got over that error but now at the last test it says:
Expected: false, instead got: NaN
Oh wait ... !
Yeah, be sure you are accouting for all the conditions in the details. The examples in the details helped me get through some missed conditions.
This comment has been hidden.
I've randomized the radii, provided better examples and improved the error messages. They should now tell you if you are submitting a string, NaN, etc.
The examples are good, and so are the error messages. Nice kata!
Maybe add some random test cases, so a hardcoded solution isn't possible.
And perhaps randomise the order of the ones already there.
This comment has been hidden.
I found, it was due to wrong type. Maybe you add more intuitive error message? For example: "Return value is String, expected: Number".
Could you add some edge-case examples in your examples? If someone (like me) skim-reads the instructions (finding the area of a circle isn't usually that involved), the examples should give them pause and push them to investigate further. Also, if we are already handling some edge-cases, you could add value validation (type, non-NaN, non-Infinity, etc.).
This comment has been hidden.