7 kyu
Noisy Cell Counts
498 of 1,100amiller.phys
Loading description...
Arrays
Logic
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.
nice kata
Python tests are not functional. Some of the "correct" answers involve lists that have lower values at a greater index that some of the previous values.
These tests are checking whether the input list was modified. The kata requires that the original data remains intact and you create a new list.
somebody can help me? so i try mi code in google colab and the answer its okay, but in my test the program says me "the function give [2,2,1,2,2] and should be equal to [2,2,2,2,2] but when a run in colab this same example the program its right.
this tests check that you haven't changed the input data. are you returning a new array?
LC translation
this translation modifies the description
does your addition change the description on Python, C, Haskell, etc.? or does it appear only on the LC description?
Other languages see no change, it's just that LC needs some additional info. It's in an
if-block. ( If you go to the translationDifftab, you can see the changes. )Already been approved by someone.
This comment has been hidden.
With the lines :
You are mutating the original array...
Also, it's not an issue with the kata but with your code. So it's a question.
Either I didn't understand the assignment, or I'm doing something wrong, Help please Here's what the random test gives out: input array was modified: [2, 2, 2, 2, 2, 2, 2, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 6, 6, 7, 7, 7, 7, 7, 7, 8, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 11, 11, 11] should equal [2, 2, 2, 2, 2, 2, 2, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 3, 5, 6, 6, 7, 7, 7, 7, 7, 7, 8, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 9, 11, 11, 11, 11, 11, 11, 11, 11]
should equal [2, 2, 2, 2, 2, 2, 2, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 3, 5, 6, 6, 7, 7, 7, 7, 7, 7, 8, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 9, 11, 11, 11, 11, 11, 11, 11, 11] goes away from the logic of the task...
how is it?????(python)
Skip all the numbers. What does the text say?
Also, what do you think this
means?
00000000000000input array was modified:00000000000000
Guys, thank you for pointing out my mistake, I didn't read the assignment carefully. In the function, I worked with the incoming array, but I had to copy and then work with the new array
Every other test //random errors (18 of 36 Assertions)// fails in error: //input array was modified: [10, 11, 11] should equal [10, 11, 10]// in Python
Not a kata issue. Do not modify the input array.
Thank you! Reading comprehension must be hard..
JS translation
Approved by someone
input array should be
const-qualified in C. Also why not use the array notation ?set-up solution has been adjusted for both.
what's your explaination about the notation difference?
thanks
At a language level:
(1)
(2)
(3)
(4) (if the compiler supports Variable-Modified types)
compile to the same code. The first dimension of an array decays into a pointer when passed to a function, so
* arrayandarray[]are equivalent. And the length in (3) and (4) is not used (but it helps the compiler diagnose some cases of out-of-bounds access, for example GCC detects this:However, it is good practice to use the
*notation for pointers to a single variable, and the[]notation for arrays; it makes the code more self documenting. Same remark for thelengthhint, it makes its purpose immediately obvious.(the only downside of (4) is that VM types are an optional feature for now. They will be made mandatory in C23, but currently they are not available on Microsoft's compiler. This means (4) would not compile on MSVC).
thank you for that very clear, detailed explaination!
Haskell includes empty input, other languages do not.
( I consider this a problem with the other languages )
sure, either way it should be aligned across all languages :)
"The first entry of the array is correct, and does not require an adjustment." This sentence implies that there is at least one element in the input array. Haskell should be fixed.
There is no real reason why the input can't be empty; valid logic is possible if you do not assume the input is non-empty.
I'll change it, but I think it should also be explicitly specified.
Update available. This also patches the description.
The kata can be republished now.
C++ ref sol incorrect:
Fixed.
Please review: C++ Translation
approved by someone
Haskell translation
approved by someone
I'm not familiar with Python kata, but should the example tests have an
import solutionand anitheader like the submit test suite does?yes, good call. i've added these.
Test suite has wrong indents, rendering with errors in the editor.
That is a maintainability issue.
ah, i was wondering what the highlighting meant.
thank you, ready to review
Yep, looks good. ( though the missing space on line 58 is killing me :)
fixed :)
I told you not to resolve that issue until changes had been reviewed.
That assertion needs a failure message. You are not testing what solver may expect. "But
[10,11,10]is not the correct answer according to the description!" is a very logical reaction when the assertion failure message isand solver has not read or does not understand the
itheader.ah, my apologies for prematurely resolving. thanks for working with me and giving great feedback on my first submitted kata.
i added a clear feedback message for this test.
will not resolve until you validate
I'd make that message even more direct: "Input array was modified" Because that's exactly what you are testing. And I'd put that in the
itheader: "Input must not be modified" or something."New array" is a means to an end. Not mutating the input is that end; that's what really counts.
changed
And even now, people won't read ..
solver is not getting a copy of the input in random tests.
this becomes important when order of arguments to
assertis fixed.ETA: to be sure to be sure, ( also ) calculate
expectedbefore calculatingactual.i added a second test for each sample in the random section.
should i add checking for a non-mutated array for all tests?
no, this should do it
Right, that's it from me; republish and see if anybody else still sees anything wrong. Thank you for working with me.
Arguments to
assert_equalsare in wrong order in random testsgood catch, fixed now
C Translation
Little typo in preloaded section
// do not allocate memory for the reulting arrayapproved by someone
Issueto prevent approval while the kata is being modified for input non-mutation.Please resolve when this has been implemented and reviewed ( and not before ).
changed description language to:
Your task is to create a new non-decreasing array that is minimally different from the
dataarray. For example, if thedata = [1, 1, 2, 2, 1, 2, 2, 2, 2]then the returned array should be[1, 1, 2, 2, 2, 2, 2, 2, 2]becausedata[4] < data[3]is clearly an error.i'm still not sure how to modify the tests to check that the user returned a new array. do you mean to include a test like the following?
No. Something like
I'm not a Python guy, so don't take my word for the assertion ( you might need deep_equals ). But that's the idea.
The idea is not to test the user returned a new array ( if the input is already compliant, s/he could return the input unmodified ), it is to test that the input is not modified.
Shouldn't that be
assert_equals?Yes, it should. Maybe this is rocket surgery .. :S
added this test case
i also checked that this test catches a mutated list
Reviewer says no. ( Actually, "yes, and .." )
Also, one test is not all that much. You can test against input mutation every test, practically for free. Remember to give a clarifying failure message.
I think it's a worthy consideration to at least comment on whether the input should or should not be mutated, or whether it matters. Given that it is generally considered a bad practice, I suggest that the user NOT be allowed to do so.
Thanks for your suggestion. I agree with you, but I'm not sure how to impose that the returned array is not mutated in the submission test. Would you please advise?
Copy the input to give to user. Afterwards, compare original input to copy user had his hands on.
The current description implies the input should be mutated ( "Your task is to correct the data .." ). That should be rewritten.