6 kyu
Polynomial Evaluation - Binomial Form
55 of 80abiessu
Loading description...
Mathematics
Fundamentals
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.
python new test framework is required. updated in this fork
This comment has been hidden.
I'm still having difficulty with rounding errors. Best policy for katas is not to round results before comparison, but to use a proper fuzzy comparison with an appropriate margin of tolerance, such as with the test framework routine named
assertApproxEquals
or something similar. Rounding has the potential to magnify an error if it happens to be close to the split between rounding up and rounding down and the reference solution goes one direction while the user's solution goes the other way even though their absolute difference may be very small. See https://docs.codewars.com/authoring/recipes/floating-point/ for more information about best practices when dealing with floating point numbers.The rounding requirements are horrible. We have to guess the author's algorithm and intermediate steps where rounding is expected. This takes away all the fun and quality of the kata. Big thumbs down from me.
Python 3 should be enabled.
Done.
Thanks for the constant feed and improvement: kata definitely upvoted and, while at it, also translated into both Python and Ruby, if you want to approve them :)
Let me know (also posting down below here, but no problem in giving you my personal email) if you are going to produce more than one such kata :)!
Slight modifications and approved.
The only other kata I have authored so far is here: http://www.codewars.com/kata/5674788cadb5889b69000045 and it uses the same math to create the polynomial representation that this kata uses for evaluation.
Thank you for your help in improving this one!
My pleasure and, if you wish, also consider increasing the number of tests, particularly the random ones :)
This kata could definitely benefit from a more guided, step-by-step explanation.
Please help me understand what you mean. In the description, I include an example call, the expected return value, and the math of the expected return value. Are you saying that I should include more such examples in the description, or that the math needs more explanation, or something else?
Thank you for your feedback.
I had a long day and that could be it, but I am not getting clearly how you end up with the value of 16; plus some link to wiki or other sources to better understand the concept (googling "Binomial form" wasn't much help in my case) would be appreciated.
I have included some links and an expanded section on the example calculation. Please let me know what you think. Thank you again for your feedback. :-)
Oh, now seems much, MUCH better; as soon as tomorrow, I will have another shot at it, but in the meantime, thanks for your hard work and for considering my feed :)
Mh, possible rounding error due to the sequence of operations I do or something which is considered just wrong?
Test failed. - Expected: 4.2383999999999995, instead got: 4.2384
Maybe telling to round up to the 3/4 decimal digit would be better?
I think I'll put a +(Number.toFixed(2)) in place in the official solution to avoid further difficulty with this, and explicitly state this in the description. The main point is not getting high-precision results for non-integers, but rather to expand awareness of an alternate internal representation of polynomials.