Beta
Histograms For All The World
Loading description...
Algorithms
Mathematics
Statistics
Data Science
Performance
View
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.
The last interval isn't clear how to get. if the idea is to get the upper - 1, this doesn't work for all the cases. I don't know how you get the last interval
I have no clue how these intervals work. I guessed how to handle
99
and100
as upper limit. I can't approve this kata in its current form. But then again, this kata has been in beta for 10 years, so you probably don't care anymore ;)add links (to wikipedia) in the description for things like Sturges' rule
This issue is still not fixed!
fixed now.
Python 3 should be enabled ;-)
Done
The issue below is not resolved yet:
Seems fixed
k = 1 + 3.32 * log (n)
Log base is not specified. Apparently it's base 10 and not natural log, which is not what typical
log
means and so it should be clarified.Added in description.
Sample test is missing a closing parenthesis at the end.
Fixed
I think I'm right in thinking that the upper bound on the final interval should be "lowest value + intervals * amplitude", and yet I'm seeing odd errors relating to the final interval's upper bound being out by a small amount when the tests are run.
I' ll solve it as soon as possible. Thanks for the feedback Christian.
corrected now.
Getting this error on random tests.
I believe my solution is correct because the cumulative frequency expected is wrong (97 instead of 100). Could you look into it? Probably some floating point error somewhere.
I' ll check it. If we have 100 elements the cumulative frequency should be 100. Right!
It's easy to see what happened. The upper bound of the last class can't be less than the max value of the variable. I'll correct this bug
Thanks a lot for your observation. It should be solved this part. I'll be waiting your answer.
There is another problem. Look at this.
Note only the last interval is wrong (107, 100) the second last (100, 106) is also wrong. What is the correct value to be returned in cases where the last two intervals are greater than 100?
The problem is at the end. I'll solve this.