The test cases need to be expanded -- multi-character markers, things that need to be Regexp escaped, etc.

BTW, using ints.size like that is maybe not a very good idea.. ints.size > maximum index of the array. Use ints[i..-1] works great.

Note: this is a really lazy way to do it. It's effectively O(N^2), where an optimal solution is O(N).

FYI, you could shorten your first 6 lines in a variety of ways:

bits = bits[bits.index('1')..bits.rindex('1')] #take the range of characters from first 1 to last 1

or

bits = bits[/1.+1/] #the same, but a simple regex

You could also do what I did, which was to convert zeros to spaces and then just do a String#strip

I just wanted some test data -- see my comments on the kata. My solution worked fine, but some unexpected data caused an issue, and the error messages/data weren't very specific.

Great challenge! It shows you how hard option parsing really is -- something I didn't even think about =)

1. Let me explain it to you:

"Five hundred and twenty-one"
"Five hundred twenty one"
"Five hundred twenty-one"
"Five hundred and twenty one"

Why should it be the last one and not any of the first three? The tests expect rigid conformity to a standard you don't lay out explicitly. That is to say, the first three are "not allowed" but the final one is "allowed" -- and it requires an AND to be placed just so. It gets even more hairy when you realize that one could have, for example, beliefs like this: "one hundred and five" is correct, but "one hundred five thousand one hundred and five" is also correct -- you could be placing "and" ONLY in the final hundreds group. In fact, that's how most people speak: "the house costs two hundred thirty thousand, four hundred and ninety-nine dollars."

2. I am fine with difficulty, but if you're unable to debug and there's no good REASON why the test is failing... and no message on the test... if I tested 0.0 and got "zero point zero" there is NO way I could tell that it was causing my failure. There's no rule about it, no way to understand that you might have done it wrong at all. To solve it, you'd have to be like me and cheat to look at the tests. Putting something like "0.0 should yield 0" in your test message would solve issues like this.

The problem is fine, it just has three main issues: unspecific rules, ambiguous test cases with unhelpful error messages, and a lot of grunt work to tackle the meat of the problem. Those, to my view, are all solvable, but they require some work.

Fun kata, not quite sure why 0 wouldn't evaluate to 0th... that seems counter-intuitive to me, and isn't listed as a requirement either in the directions or in Wikipedia.

Yeah, cbean, that's a bug that I also came across -- it strips out anything that looks like an XML tag. That sucks, because assigning matched groups to variables is one of my favorite Ruby regex features!

Interesting -- that's a bug. Codewars strips out things that look like xml tags from answers? I am using the sweet ability in Ruby to assign matches variable names -- in this case, :domain.

FYI -- this won't fit all of the criteria. For example, get_hashtags 'this is not a legit hashtag: #123'

\w matches digits, too. Furthermore, it's not specified whether digits or other characters are allowed AFTER the first char after the hashtag. I assumed it would be twitter-like.

The problem is fine, but without data to test against, it's really annoying. I cheated and monkey patched Array the first time around -- it turns out that my bug was because I wasn't clearing out a variable that got re-used. But there's no way to tell without looking at some actual result! Using some of the data, I was able to easily see what I did wrong, and fix it in about 5 characters =(.

Doesn't this rely on the order of roman? I thought the whole point of hashes is that the order can be unpredictable...

Haha, now that's really clever. I modified Float, but this is better!