6 kyu
Collapse Left
135 of 230Uptyler
Loading description...
Arrays
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 fork
snake_case
[issue]pravoozed
In python, the tests log the inputs for some reason (please remove all print functions from tests).
But more importantly, the tests are vulnerable to users mutating the input
In fact, mutating the input causes random tests to consistently throw an error.
Resolved in above fork
Python: function name should be snake_case
Resolved
Haskell translation
Fixed tests should have fixed expected values. Do not rely on a reference solution, as the "with functions" fixed test does.
I have removed the reference solution from the fixed tests.
Really? :/
I'm not incredibly familiar with floating point 'Errors' Do you think applying a round to any dividing functions passed in as an argument would fix the test failing?
This is a known test framework "feature" ( for very loosely defined values of "known" ). It recently came up on Discord:
deepEqual
uses an equality definition that is not===
.The necessary workaround is something like
map( x => x ? x : 0 )
over both operands. It should not be necessary, but it is.Math.round(-0) === -0
:[About floating point errors: https://docs.codewars.com/authoring/recipes/floating-point
However the problem presented by B1ts is probably not related to how floats are handled in tests, but to quirky behaviour of Chai assertions, which decided to make -0 not equal to 0.
Is deep equal a "deep equal" or "deep strict equal" in chai?
Neither. It's really weird, and undocumented ( just says "deeply equal", without specifying equality ).
It's mostly "deep strict equal", but
-0 /= 0
even if0 === -0
and-0 == 0
.It depends what you mean by "equal", and by "strict". Its neither
==
nor===
, it has special handling for some edge/tricky values, like +0 vs -0, and IIRC NaN.so it aims at
====
that's a very nice way of describing it :]
map(x=>x ? x : 0) as been applied to both operands of the test case to prevent floating point issues.
Crikey,
NaN ==== NaN
according tochai
. That goes directly against the IEEE spec forNaN
.I would add
map(x=>x ? x : 0)
after some basic sanity checks, such as assert isArray and assert every element isInteger (I take it all elements are integers)x ? x : 0
will coalesce all falsy values to 0. if you want to handle only the -0 vs 0 quirk, id dox === 0 ? 0 : x
.Number.isInteger
, orNumber.isFinite
if elements can be floatsThe description could be better: more explicit specs and less reliance on examples. Ideally, the description should be correct and complete without any examples; examples can clarify, but must not specify.
I don't have to like variadic functions ( just pass an array? ) and I don't have to like heteregeneous arrays ( and I don't, but the usage here makes it hard to avoid ), but I can get over that.
The task seemed artificial, but once I got to implementing, it actually flowed rather elegantly, which was nice, very nice; I like elegant. :]
I would like to encourage people to subtitle their vote; do all those
Meh
s mean this kata is hopeless, or should the description just be improved a little?This comment has been hidden.
The description usually is the hardest part. Welcome to creating kata. :P
Most solvers don't even use
arguments
, but a rest parameter, thus defeating your purpose. It also makes translating harder, because the description becomes inconsistent between languages. I'd advise against it, but other opinions may be available.For beginners, this might be a fun and challenging kata. I just wonder whether this hasn't been done before ...
"Most solvers don't even use arguments, but a rest parameter, thus defeating your purpose"
That is correct, but either way requires a use of lesser known features of js as opposed to iterating over a given array parameter.
To my best recollection, no, this is novel.
OK, fine.
Please just don't do it. It makes translations harder to create.
I would be ok with switching the input to be a heteregeneous array, but I would like recommendations on how to improve the description's lack of clarity.
I had to guess what to do from the examples, because the description does not say:
Please read https://docs.codewars.com/authoring/guidelines/description.
I'm not complaining about lack of clarity, I'm complaining about specification by example, which in practice is an invitation to solvers to read author's mind, something solvers are notoriously bad at.
ETA: just noticed that you already updated the description. what you have now is not bad at all! it could be more clear that multiple functions working on a single argument result in a single element in the output;
[0,inc,dec]
could also result in[1,-1]
, but that's not the intention. the "collapsing" could be expanded on, or an example could specifically clarify this ( this is what examples are for! ).Having an example of "how not to do it" in the description is not working for me. I'd suggest just taking that out.
Please approve this fork addressing test suite maintainability, futureproofing, and robustness, and description consistency.