I just tried again and I still can't republish the kata.

I don't know what's going on. :/

Call it "run length transformation" ?

That sometimes happens. It wouldn't work for me either ( I tried to publish some minor description updates ) - but it'll probably work when you try again later - hopefully.

I have tried to update the Kata however it freezes whenever I hit the Re-Publish button. I have tried on multiple browsers and multiple computers but it never actually publishes the changes. Is this a known bug?

I then thought I could remove this Kata and publish a new one with the updated information however it won't let me remove Un-Publish this Kata either...

Any ideas?

Take your time. It's not a problem if it takes longer; I just didn't know if you were still interested. People have just disappeared before.

On Project Euler problems: they have been made into kata before; I shouldn't think it's a problem ( giving credit would be nice I guess ), as long as it's not a duplicate of an existing kata on here.

I very much apologize for not updating the Kata in a timely fashion; work is eating up a majority of my time (Our company writes drivers for optical disc drives (the FAA still uses SCSI drives, who knew?), it's a ton of fun I promise :p). I'm about to head to bed for the night, however I will make the edits to the Kata tomorrow during lunch or when I get home. In hindsight, I probably shouldn't have submitted the Kata until I had time to work on the issues but I will resolve them tomorrow.

As to your question about the return value of possiblyKolakoski([1,3,3]), it would return false as [1, 2] is different than [1, 3]. However, that is not how I explained the function in the description and that is obviously a problem. Thank you for pointing this out.

I would very much like to read how you would describe the kata, as well as what changes you would make to it. I'm not sure about the possibly_kolakoski function thinking about it now; maybe it would be better to label it is_currently_kolakoski?

Here is a list of the changes I plan to make tomorrow

• Add random tests + add more static tests
• Update explanation of the RLE used in the kata as to not confuse people
• Update explanation and naming of possiblyKolakoski to better reflect what it should return
• Update explanation and naming of generateKolakoski to avoid confusion

Feel free to add more to that list before I start hacking away tomorrow; I appreciate all the effort you have put in helping me with the kata. I'm sure we will arrive at a kata that everyone is satisfied with; that is my goal (as well as everyone elses I assume).

I look forward to chatting with you tomorrow over the changes!

Also, this is probably not where I should ask this but I just thought I'd take the opportunity since I have your ear (eyes?) at the moment. Is pulling ideas and content for kata's from other sources discouraged? I am a huge Project Euler fan and there are lots of extremely interesting and fun problems that I think would make great kata's. As long as I don't just copy & paste the description of the problem, is it okay for me to translate my project euler solutions?

Anyway, thank you again!

Best Regards,
Kevin

Haxifix, have you found the time to make those adjustments yet? Are you going to, or should I just create a new version for the Javacript and Haskell translations? Or am I running on a different timescale and just being too impatient?

I have JS and Haskell solutions ready for translations; I could redo the description a bit at the same time.

Random tests in the C++ version and an answer to the above question would be welcome though, or the original kata would still have problems the translations do not.

What should possiblyKolakoski([1,3,3]) return, and why? It might still be Kolakoski so far if it were to be extended starting with exactly one more 3; we don't actually know that it is definitely not Kolakoski.

generateKolakoski must generate a sequence that may not be a Kolakoski sequence. This could be explained better; the naming suggests that either the input will always generate a valid sequence ( this is not specified though, and it is not true either ) or we maybe have to throw an error or something ( we don't ), instead we are supposed to blithely return a Non-Kolakoski sequence.

Working on JavaScript and Haskell versions, and it might just be me but I stumble over that.

Random tests needed.

You could say something like "we extract the segment-lengths from RLE and get [ 2, 3, 1, 4, 1 ]", or rephrase the whole thing into "we convert each set of contiguous identical elements into that set's length as if we were doing an RLE encoding". The wording may not be ideal, but at least it will make more sense then.

To be honest, I did not mean to set the level at 3 either. I agree, this is definitely not a 3 kyu level problem; I thought that the rank was determined during the beta stage by the people who solve it (like you said) so I have no issue with it being ranked whatever everyone sees fit. I just thought it was an interesting sequence when I first ran across it and thought others would find it fascinating as well!

Thank you for the link, I will make some adjustments to the kata and see what people think.

Yes, I agree that normally run-length encoding includes the element itself however I do not think that has to be the case. I gave an example of what I meant by run-length encoding as it applies to the problem but I can see how this might cause confusion. Do you think I should change the text to "modified run-length encoding" or should I just make an extra note that the RLE used in this Kata is slightly different than the canonical implementation?