7 kyu
Same Birthday Probability
406 of 831user5467385
Loading description...
Algorithms
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.
JavaScript fork (author gone)
Description is incorrect for JavaScript. The tests always require two decimals, even for 0 and 1, which directly contradicts the description. In addition, the tests expect strings instead of numbers.
python new test framework is required. updated in this fork
Approved for test framework update
What rounding are you using? I got an error for 18 people where the reference solution expect 0.35 but I return 0.34
The calculation comes out at 0.34279 when rounded to 5 places, which is 0.34 rounded to 2 places.
You need to allow for differences in round and an error of +/- 0.01 or specify round UP or DOWN to 2 places...
Duplicate issue. This kata has rounding issues, it has already pointed out in the next message, no use to raise more issues about that.
wish I saw this before I spent an hour trying to decide if my math was wrong
The values have to be compared for approximate equality, especially when the difference between the result of an
O(1)formula and the value returned by the reference solution (without rounding) can be as high as0.01- have fun dealing with numerous off by one errors.The author is long gone, so someone else will have to fix it.
O(1) formulas are only approximations for this problem. I don't see why solutions with an inaccuracy as high as
0.01should be allowed.When the kata is not about programming but a mere math formula coding it is better to give the formula. It took me 25 minutes to find the formula and 1 to code it.
This comment has been hidden.
Can someone please tell me how to round this because I am only out about by 0.01 on an average of 4 out of 23 test cases:
✔ Test Passed: Value == 1 ✔ Test Passed: Value == 0.97 ✔ Test Passed: Value == 1 ✘ calculateProbability(15) - Expected: 0.25, instead got: 0.26 ✔ Test Passed: Value == 1 ✔ Test Passed: Value == 1 ✔ Test Passed: Value == 0.92 ✘ calculateProbability(15) - Expected: 0.25, instead got: 0.26 ✔ Test Passed: Value == 0.81 ✔ Test Passed: Value == 0.75 ✔ Test Passed: Value == 0.73
etc.
Thanks for this kata @Et2rn1ty! I would suggest to rephrase your description to clarify that you are asking for the probability of at least (and not any) two people having their birthday on the same day. This is actually the probability we are calculating in this kata. Other than that, very good idea.
I am getting the right answers but still the test is being failed, any idea what could be wrong? Thanks in advance! calculateProbability(81) - Expected: 1, instead got: 1.00 calculateProbability(78) - Expected: 1, instead got: 1.00 calculateProbability(40) - Expected: 0.89, instead got: 0.89 calculateProbability(42) - Expected: 0.91, instead got: 0.91 calculateProbability(12) - Expected: 0.17, instead got: 0.17 calculateProbability(100) - Expected: 1, instead got: 1.00
are you returning a string?
This comment has been hidden.
Also getting these errors (although also an occassional "expected 0.17, instead get 0.19" - which surprised me because I can remember this from a stats lecture, but anyway)
Solved the 'rounding to 2' problems by turning my 2-d.p. answer into an int and back again - ie 0.01 * integerOf( 100 * answer). This cut the errors down to 1 or 2 and I eventually lucked out with a set of random tests that didn't trigger an error.
Bit of a pain though ...
Nice kata: Python and Ruby translations submitted, if you want to approve them :)
I like this kata, but have a few suggestions. It might be better to frame the problem better and to specify that we should expect the birthdays to be distributed uniformly. It might also be better to specify that we are looking for a number between 0 and 1 and not something like 0-100.
The description is silghtly terse. I might recommend framing the problem a bit, mentioning that it is a very famous problem from probability, and giving the coder a little motivation. Also, I will say that kata live and die by the number of default tests provided. Good problem!!
There needs to be more than one test case. The test you have is fine, it just needs to run a few more times.
The test was in a loop but there was an undeclared variable in the test solution which was stomping on the loop counter. I fixed that so it's a private variable and the loop runs the correct number of times.
You need some example test cases and much better failure messages in your test cases. "Value was not as expected" is completely useless for debugging.
This is a mathmatical problem, so either the value is correct or it is not. I will add an example test case, to assist in reaching the correct answer.
Okay, but important pieces of information include the input and the expected output.
Et3rn1ty, it's true that the value is correct or not, but displaying the expected value is immensely helpful to users in figuring out what is wrong with their solution.
Case in point, in my previous comment I thought my answers were being rejected because they were slightly off due to floating-point rounding, but if I had been able to see the expected answers, I would have known that they should have been rounded to 2 decimal places.
But note that providing the expected output makes it very easy to cheat when there are small, fixed number of tests.
To mitigate the cheating problem, you can embed the solution in a private function in the tests, and randomize the test inputs. Something like:
This way, when a user's solution returns the wrong answer, the test will provide a nicer answer. For instance:
This way, if a user were off by just a percentage point for example, they'd be able to see that they had a rounding problem, instead of getting no feedback at all. And because you're running a hundred tests, it makes it very annoying for a user to "cheat" by embedding all the expected answers in their solution.
Thanks for the tips. I've implemented your suggestions.
I've tried computing this a few different ways and haven't been able to succeed yet. It's going to be difficult to match the expected answers exactly due to accumulated errors from floating-point rounding. Perhaps the tests could just check the first few digits of the answer?
I should have specified. Answers should be two decimals unless whole (0 or 1). eg. 0.05