5 kyu
Rule 30
406 of 899MircoT
Loading description...
Lists
Arrays
Binary
Puzzles
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.
C# Translation
Lua translation!
python new test frameworks
Approved
The description declares
n
to be the number of iterations, then goes on describing how then
th cell should be processed. It seems this is however not intended, but all indices must be considered.Furthermore, although it's alluded to, there's no explicit rule stating that the array needs to have a 0 added to the front and the back.
Please adapt description.
Requirements should be changed tbh, it's pretty stupid that you're expected to pad when unneccessary.
D translation
Nice kata, but the handling of all-zero sequences seems overly strict. Since sequences are bounded by implicit 0s, any sequence consisting only of 0s is equivalent to any other (and all of them are equivalent to the empty sequence). One of the sample tests insists on the returned answer being {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, even though any other all-zero sequence would be just as correct. Maybe leading and trailing 0s should be disregarded when checking solutions?
The examples should be an image or ascii/unicode visualisation instead, so that the solver does not need to wonder whether it contains hidden information in its text, and to make it easier to parse in general.
All the rest of the instructions below the rules table should be replaced with an explanation of what part of the data to return, that current text is difficult to read and says nothing.
The wikipedia mention should instead be a hyperlink for the first two words "Rule 30" so as to not make the solver question whether there is required information there that the instructions leave out. Also improves signal-to-noise ratio.
for anyone solving this currently and confused by this edgecase: The solver appears to expect the output array to grow by at least 2 on each iteration, so if your result is an empty array after trimming leading and trailing zeroes you can create a new array of list.length + 2 and fill it with zeroes.
Fork removing one fixed test where
n
had a negative value in JS: https://www.codewars.com/kumite/6263ee4c9eeaac004ba2541e?sel=6263ee4c9eeaac004ba2541eApproved
"a non-negative integer n" n can be a negative number!
The kata has been updated recently, all the negative values have been removed from all languages versions, but one has been omitted in Javascript. Sorry for the inconvenience, I've just published a new fork but it needs to be approved.
Nice, a starting zero doesn't have a left neighbour. Now what?
It is in the description.
No, it's not. Description is vague. Borders are always 0 you can interpret as "put a zero when a border isn't 0", border being the beginning or end of the resulting sequence. In fact, you ALWAYS have to append 0's before calculating the next state. To calculate the next state, you have to check the borders as well, assuming that there are ghost neighbours with value 0 before and after the actual sequence. With these assumptions I managed to solve this kata. With a clearer description this would be a level 6 or 7 kata.
In my opinion, I understood it best when I looked at the wiki article and realised that you just treat the initial state as an infinite array of
0
s, with a single1
somewhere. Then iterate on that, and only produce the "interesting" slice of that infinite array as your output.I don't know if that kind of explanation would help or make the description more confusing though...
From the description:
COBOL translation updated according to current description.
Needs a week ..
( same for the Haskell update )
approved
LC translation
This translation removes input validation from the description.
C translation
If you can get someone to approve it, I can update Haskell and add LC. But I want to change the description ( and the specs themselves ), so I'll wait to prevent the merge conflict.
please do them now, i dont care. i can still fork afterwards anyways
Approved
These rules are inconsistent. Worst part is that you have to return the original input unlaundered for negative iterations but you do have to launder for
0
iterations. And all of that contradicts "positive integer."Please just skip the input validation already.
COBOL translation.
Approved by author.
Please update testing for no input validation. Description has been updated already.
Fork published.
Values other than 0 and 1 are not tested in Python, JS and Ruby. Currently only Haskell actually tests it.
Maybe haskell should be "downgraded" and the description updated.
That's what we are considering with Johan. I'd like to have an explicit consent from the author. COBOL would need to be changed too.
Haskell fork available here.
This is now fixed.
Tests in Haskell are unusable:
We should be given the input, or we cannot do anything with it.
That actually gives you the input.
[2]
is the initial list ( which can apparently contain1
or anything else, which counts as0
), andPositive { getPositive = 1 }
( aPositive Int
, in this case1
), is the number of iterations.Using the default
Show
instance for the number of iterations is unfortunate, and the whole input validation thing should be taken out and shot, but it is actually doing what you're asking of it.This can be fixed without much effort with a custom
shouldBe
( that'd be a oneliner ) and adjusting the random generator to generate normal inputs.Indeed, sorry.
About the validation stuff, don't you think it's better to remove from the description and from Haskell's design? I could remove it from the COBOL translation and update the description.
I'll readily admit it's not very readable.
Input validation has been a ++UnGood idea for years. The Haskell version is not even the original one, Python is; I don't know how it got in. K!ll it.
Please ping me on the
Suggestion
up top when you've updated the description ( I don't get notifications for this thread. or@mention
me on Discord somewhere, that'll work as well ); I'll do a Haskell fork.Actually, see here: it was meant to be taken out seven years ago, by the author. :O !!
COBOL translation has been approved before I could update the description and the fork. I'm going to see with the author if he agrees to change that.
Author has gone silent again?
He said his agreement with the changes we're proposing there: https://www.codewars.com/kumite/62179c1f67623b001fbe085e?sel=62179c1f67623b001fbe085e
Ruby 3.0 should be enabled.
duplicate suggestion
Ruby 3.0 should be enabled.
fixed
This took at least twice as long to figure out the correct way to handle leading and trailing zeros as it did to figure out the main logic of the challenge!
Would it be possible to remove leading and trailing zeroes from the test cases? My solution is producing correct answers, but the random tests keep failing due random leading and trailing zeroes. (seemingly random. spent the last hour or two trying to figure out workaround for the tests without luck.)
Done... If you have any troubles write again. Now the random tests are without leading and trailing zeroes.
Thanks!
Hello! Great kata.
Just a remark: in random test, inputs that have leading or ending 0 (like [0, 1, 0 xxx 0, 0], I think this kind of input makes no sense and break the Rule 30. Tell me if I'm wrong but row of cells should always have leading 1 or ending 1 (by only counting existing cells which make sense).
I say that because I was upset to have coded something that fit the rules but failed at something unexpected (I don't think it's mentionned in the instructions). And manage to fix it.
Cheers !
Yes, this is a good point. The random function can be optimized to produce a consistent state, so it will be better. If I have time I will change it, thank you for your suggestion!
Inputs are not guaranteed to be output of rule 30 themselves. Closing.
This comment has been hidden.
This comment has been hidden.
Optimising your solution may be possible, but this is not a kata issue. Closing.
Hello!
During submission, my method (ruby kata) seems to pass the tests but fail anyway? the error I get is:
*': negative argument (ArgumentError) from
rule30' fromblock in ' from
block in describe' frommeasure' from
describe' from ` ' 10 Passed 0 FailedCould anyone confirm whether ths is my mistake or a problem with the testing?
thanks in advance
Can you submit also with that error? It's strange because if there were some errors the tests have to stop. Did you try to change your function?
Just read the instructions again, sorry!
Hi all, I believe I found a some sort of a pattern in these random tests.
For example:
Random tests Testing for [1, 1] and 2
It should work for random inputs too: [1, 1, 0, 0, 1, 1] should equal [1, 1, 0, 0, 1, 0, 0, 0, 1, 1]
The correct result is my result because it has correct number (6) of elements (each iteration causes creation of 2 new elements; there are 2 elements initially and then 2 iterations). Of course, one can check the correctness even by hand on a piece of paper. The test answer is the list of 10 elements. Funny thing is, that the result suggested by the test is exactly the result of:
rule30([1, 1, 0, 0, 1, 1], 2)
So the testing routine seems to take the correct result as the first argument of tested function. I ran my function several times and it always was stopped by the very first random test.
Thank you so much for the suggestion!!! I think that now the problem is fixed.
Hey all, In JS: I'm passing almost all of the tests except for several in which I get a random 'null' value that appears within my result, otherwise the result is correct. Through my own testing I cannot reproduce these null values. I'm wondering if there are any edge-cases I might be missing that are interfering with my code, but I have read through the spec and cannot see any. Has anyone experienced similar?
This comment has been hidden.
I am also having this problem. Random tests have one extra zero in the beginnig and end of result array.
Since I wanted to get through this one before waiting for a bug fix, I added the following to the top of my function to flag the random tests. Then before returning the output, I add the leading and trailing zeros if it's a random test. The arrays in "not in" are the unique starting arrays and unique iteration counts in standard tests.
rand = False if o not in [[1],[1,0,0,0,1,1],[1,1,1],[0],[1,0,-1,0,1,1],[-3],[1,0,987,0,1,1],[1,1,0,1,0,1,1,1,1,1,0,1]] or n not in [1,2,21,3,5,0,-3,75]: rand = True
<-----CODE------>
if rand == True: o.append(0),o.append(0) o.insert(0,0),o.insert(0,0)
Same problem here in Ruby. It's returning extra zero at the beginning and end of the resulting array. Any fix/hack to get this work?
I tried to change some steps in the tests, do you still have the same problem?
Hi MircoT,
Still in the same problem using Ruby.
With the last suggestion I think the problem is solved, I haven't the error right now.
Standart tests passed, but random tests for JS are failed because it expected addition zeros at the begin and the end. From start array [0,0] with 36 iteration my script returns 74 zeros (36 in both direcitons plus initial two), but expecting array is 76 zeros. Is it correct?
The correct answer is 74 zeros, so your script is ok. I tried to recreate your problem with the random function generator but I didn't have the same result, I have to investigate more about that...
Here another example: Testing for [1, 1, 1, 1, 1] and 20 It should work for random inputs too - Expected: [0,1,1,0,1,1,1,1,0,0,1,1,0,1,0,0,1,1,1,1,1,1,0,1,0,0,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,0,1,1,1,1,0], instead got: [1,1,0,1,1,1,1,0,0,1,1,0,1,0,0,1,1,1,1,1,1,0,1,0,0,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,0,1,1,1,1] Just in case: it's javascript that I'm trying to solve on.
I didn't figure out the reason of the error because I never had it in CodeWars and also in my PC, but I rearranged the code to be similar in all the tree language available for now. Do you still have the same problem?
Seems to be solved right now... sorry for the inconvenient!
Yes, thank you.
I don't see how with 1 iteration the rule goes from [1] to [1, 1, 1]. I understand that since 1 is next to both borders of the list that we add in 0 to both sides of the 1 which gives us [0, 1, 0], but how do we then get [1, 1, 1] from that? Do we change all cells under consideration to the value in the new cell row? That is, since was have [0, 1, 0] and the rule says 1, both left neighbor, current cell, and right neighbor all become one? The way its worded it sounds like only the current cell changes, which in the case of [0, 1, 0] its already a one so we should just stay [0, 1, 0] not become [1, 1, 1].
This kata (unhelpfully) omits leading and trailing zeros from the input array. It makes more sense if you consider that [1] as provided, is actually [0,1,0]
The tests for "invalid" input add nothing to the kata and just pollute the solution. They should be removed, and we should always receive valid input.
This comment has been hidden.
The input array should only contain 0,1
n should always be >= 1
Done! Thank you for the suggestion!
This test still exists in the Ruby version:
Sorry, I left one...
Fixed now, Thanks.
I have a solution which passes all the standard tests, but fails all the ruby random tests. The random tests seem to be padding the results with [0,0] which does not happen in the standard tests.
The tests seem to have magically fixed themselves.
Description needs to be more clear how the initial state grows in size.
Added a more detailed explanation in the description, I hope it will be enough, without removing the curiosity of the puzzle...
This two sentences look unclear and contradictionary, could you please clarify them?
the list must be considered circular
the border of the list are always 0
Probably it would be enough to formulate when and how the array should grow.
Yes, you're right. I deleted the first one because is not useful...
I think there's no necessity of new informations, no?
Thanks! Good to go!
This comment has been hidden.
Just in case you may want to improve this one too:
Oh, btw: table with conversion from the wikipedia page added; provided Mirco is ok with it, I can't seem to make the right alignment for the second row work; any edit in that sense is welcome.
Tante grazie dottore ! ; )) That's what I like in CodeWars: you may learn more thant code.
The table is ok, but I thought is better put it after the presentation and not in the end. :D
Feel free to copy&paste it wherever you see fit: you are the author, your taste is certainly an important factor here.
This comment has been hidden.
I'm so sorry, I made a mistake in that kind of test, it should be solved now.
It's cool we all make mistakes! It's what the beta process is for! :)
Dai Mirco: prometto che se fixi i test cases ti traduco il kata in JS e Ruby, faccio revisione generale e te l'approvo appena possibile :D
Per farlo in Haskell invece non saprei se riesco, ma ci posso pensare, visto che si presta assai a una bella trasposizione funzionale, mh...
[Trying the fellow-countrymenship card here, but I will do it for real :D]
Sto cercando di capire se ho sbagliato, ma anche su carta mi sembra torni. L'ho riverificato velocemente, ora cerco di approfondire.
Per la parte in JS penso di farla, non ho avuto tempo di implementarla, ma per Ruby mi serve una mano che non ho molta pratica. Spero che piaccia e che presto arrivino altre implementazioni! :D
If you are ok with it, I would switch back to English, so that other users like Abbe-senpai can follow us and contribute, otherwise I fear that this could be a 2 or 3 people (if Zozo-senpai wanders around here) conversation.
I think that the problem could be about managing the -1 in the starting list: did you convert it immediately in your code or left it to some other part?
Consider the Ruby part done already, while for the JS part, if you wish, I could translate it and then leave it to you for some fine tuning: as you see fit.
Once this kata will be fixed and ported into the main popular languages, I expect it to become popular enough to be greenlit in a matter of few days.
Oh, and btw: thanks for your work so far - really cool kata and I learned something new already :)
This comment has been hidden.
By tomorrow I hope I'll deliver the Ruby version of this neat kata; let me know if you may appreciate random tests on JS and Python too.
Uh, apparently until now I am the only one that took all those 1s and 0s, considered them binary and then converted them back into decimals... Well, it seemed easier to remember that way to me, but it is fun seeing the other solutions so far.
Random test will be a good improvement...
By the way the binary approach is the best thing. These are automaton refer to a binary environment... :D
Ruby translation submitted, if you want to approve it :)
Well, the binary approach may be the best thing in terms of efficiency maybe "natively", but using integer variable, then turned into strings, concatenated and converted again may not be the best thing so far :D
Let me know how you would like the test for this kata (a bit lax or a bit more demanding) and I'll implement them for JS and Python too; feel free to do some test run on Ruby (you should get my code for it) to see how they work and if it ok with you :)
Edit: oh, I hope you don't mind, but I took the liberty to rewrite your JS test cases with assertSimilar (always use this when comparing arrays!), because it gives more informative messages and we all prefer it rather than blind debugging.
I didn't know assertSimilar... :D
About the tests, I think is better a way bit more demanding, because after reached the goal of the rule you have to figure out the problems relative the data in the array. Do you have some example yet?
I don't know if some random example can be useful...
By the way the binary approach is the best solution, it can be another step for a similar kata that I have in mind... :)
And there you got it: 40 tests on random lists of 1-50 elements that can be iterated 0-100 times seem fair enough?
I did some test run and I saw that even on JS there is no problem; feel free to do some check on your own and let me know if everything is fine with you :)
I think is enough, thank you for the support! :)
If I didn't do a mistakes I also added your ruby solution...
My pleasure, man; and you can count on me on your next katas :)
I was thinking of some inverse-rule30, but for now I am not inspired on how to get it, mh...
Well, for what little help I can offer, feel free to ask some more: I was helped a great deal by other fellow codewarriors here and I would like to at least get even with my karma ;)
For the moment is ok... thanks again :D
Mh, could you check about the 9th test case? I don't get how comes I pass previous and much longer trials, but fail on this one.
Plus, apparently checking step-by-step doesn't help me in finding the error, mh... Well, I'll give it a further shot after lunch anyway. And thanks for this interesting kata :)
Same with me. I get the same result doing the steps manually as my code produces. And it differs from the expected result.
This comment has been hidden.
Not so sloppy for a first kata; in case Abbe-senpai didn't get notified with the edited version of your reply, I can confirm that it is now fully fixed :)
Thanks. It works like a charm now.
Interesting kata! :-)