7 kyu
Moving Average
Loading description...
Algorithms
Logic
Mathematics
Lists
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.
Haskell translation
This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/208.
Please join the discussion to help us identify duplicate kata and retire them.
i solved the kata and all the tests are ok. but when i click the 'attempt' button i get this error: Traceback (most recent call last): File "/runner/frameworks/python/cw-2.py", line 111, in wrapper func() File "main.py", line 30, in edge_case_tests assertFloatArrayEqual(moving_average([50,51,52,53,54],5), [52.0]) File "main.py", line 12, in assertFloatArrayEqual raise e File "main.py", line 5, in assertFloatArrayEqual final = [abs(x[0]- x[1]) < epsilon for x in zip(actual,expected)]
You were returning
None
when a list was expected. I've fixed this, and now one will get a message directing the error rather than the apparently meaningless error log.yeah, accidentally i returned None when n and the list size were equal. you were right
Why am I getting dinged for not having enouch decimal places and rounding in my answer?
[212.0, 226.33333333333331, 240.99999999999997, 236.33333333333334, 173.66666666666666] should equal [212.0, 226.33333333333334, 241.0, 236.33333333333334, 173.66666666666666]
Fixing.......
Can you please check again?
this is what i get on another one now. If its me plese let me know.
[407.66666666666663, 388.3333333333333, 328.6666666666667, 324.0, 392.0] should equal [407.6666666666667, 388.3333333333333, 328.6666666666667, 324.0, 392.0]
disregard, i think you fixed it
Click on
RESET
Thank you for the quick reply and fix
Updated the description to make it more readable, and approved as 7 kyu despite of average rank of 6 kyu.
I have a question about the test cases. I have solved all of the cases except one. The list of values is [35.57142857142857, 29.857142857142858, 25.571428571428573, 18.428571428571427, 11.857142857142858, 6.285714285714286, 0.0]. I was wondering why this list should return None. Could someone explain this to me?
What's the value of
n
there?Because window's size is greater than length of the list.
Why doesn't the system let me see the solutions by other members? It does show my solution as valid in "My solutions". It's been about 18 hours now since I posted it.
This comment has been hidden.
OK. I can see your comment now. I will refactor the solution. Thanks.
This comment has been hidden.
Now the expected value is computer first, modifying input doesn't affect tests.
Returning
[]
passes the random tests because ofzip
. And given that everything is an integer, I'd just useassert_equals
with lists.Thank you. With people who are way more experienced than I am giving conflicting advice on a test case solution I wasn't sure which one to use.
go for it.
No, no, three time no and even more of that. That's the worst thing to do with your kata. Just build a real assertion for arrays of floating point values, but DO NOT round here.
the very least would be something like that:
Wtf is this? Given the amount of tests and input size are low (which is the case), you can just do:
Also, camelCase in Python :angry:
Thank both of you for the input and framework for the test cases!
Deleted the rounding and implemented below to resolve the issue. Thanks again.
for i, (x, y) in enumerate(zip(actual, expected)): Test.assert_approx_equals(x, y, f"Expected: {expected}, Actual: {actual}")
=> this is the right way to do the things. Especially, it avoids the
assertArrayEquals
bullshit feedback that java Junit provides. And that bullshit feedback is exactly what you're currently suggesting... x/@bradley.mccoy, there should be a length check as suggested by B4B.
@B4B, idk what's wrong with the
assertArrayEquals
formatting -_-@bradley: use my snippet (just change the case in the name to please FArekkusu x) )
@FArekkusu: feedback like
2 should equal 23
while you're comparing arrays is just bullshit to the user. At what index? What actually are those arrays? values? lengths? I dunno why the didn't change that, but that's a completely dumb design.Initially the error message in my example was
f"Wrong value at index {i}"
(which is why thereiswasenumerate
in my snippet) but such error message would be useless too, as the user would be notified of a single mismatch, but wouldn't see whether there're any more wrong values.And this becomes insignificant because
actual
andexpected
arrays are shown together with theX should be approximately equal to Y...
message.you talk about stuff that isn't written in there. I'm supposed to be in your head? How nice of you...
Keep getting error with the exception handeling when trying to implement assertFloatArrayEqual into test cases. I just moved to 3.6 so not sure if it is something I am doing wrong or if I am just missing something.
because there were some typos in the snippet, sorry (I didn't check it before posting x) ).
This one is working in py3.6:
tho, you'll still nee'd to implement the part that will handle the
None
case.your kata is lacking some edge cases:
n<1
?n>len(input_list)
?if you don't wanna test for them, that's ok, but you have to tell it in the description, then.
This comment has been hidden.
no, not a good idea.
-1
could be a valid result too. Prefer to throw an error in case of invalid case or at least, make it return None. But especially not-1
An
int
can't be a valid result when the function's output type is alist
.But this doesn't mean that returning different data types is good :P
Done thanks
woops, forgot about that... x)
@bradley: you should add one invalid case in the sample tests.
iterable
is always alist
. If it's callediterable
, then other iterables (including iterable once and without known length) should be tested.I more specifically stated the kata test cases in the description to ensure there is no confusion that the test is on a list of intigers and the length of the list is > 1. Thanks for the input.
just replace the name of the argument in the solutin setup to
values
orlst
, then.I completed the kata and sent the solution out but the system still says: "Since you have not yet solved this kata we have hidden the solutions from you..."
You need to account for possible floating point errors in the tests.
Or just specify that all input numbers are integers, as they currently are.
That can still cause floating point error though.
It's an integer divided by an integer, so it's always the closest representable result unless a solution is written in some really stupid way.
Thanks for the input. I added some detail in the description to state that the average amounts should be rouded to the 2nd decimal and also added edge cases.