The ToArray() would be a tremendous waste of time here. Just use .Count() after the where (or .Count(x=> n%x == 0) instead of the Where)
Note that when discussing a solution, if you don't mark your post as having spoiler content, it's visible in the homepage.
This comment is hidden because it contains spoiler information about the solution
egads! That's UGLY!
And you seems to know of the existence of Regex, but you don't want to actually use a Regex..
And you call "Regex.Split(lst,", ")" 3 times even though it will return the same thing each time. And on each quote found, it will call 'x.Split()" 15 TIMES even though each of thought call will return the same thing.
Put it all together, you've made this staggeringly slow, just for the sake of making it impossible to read.
I am going through the same thing, and I was wondering if tests keep the board from the previous tests with all of my lower case characters and underscores?
I feel like the board should reset itself.
Should this be fixed or should I amend my code? Thanks.
(C#) Fun fact: If one were to use IEnumerable (and yield return) instead of Stream (which is really just a poor way of emulating IEnumerable for languages which do not have it built-in), this kata becomes trivial .....
(Now, you might say, "Well, if you change the task, of course it'll be easier", but that's not the point. The kata isn't designed to be arbitrarily difficult; it's intended to have to implement a useful design pattern. In some languages, the architecture of the Stream class is the best that can be done. But because that particular design is inappropriate for C#/.NET, it unnecessarally difficult.)
(repeated with pseudo-spoilers in next comment)
Fixed for all three languages.
Hey, you're right, it's not optimal. I was only using the assumption that every test was called as new Boggle(...).Check(). (which turns out to be true even for random tests)
If I wanted to refactor it, I'd put all the logic in other methods.
Looks like this is also in the Java and Python versions. The kata description says we will be provided with "strings up to 150 uppercase letters", so these languages are going against that.
I'm too tired to fix it safely at the moment, but if nobody else has fixed this, then I'll get it resolved on the weekend.
In the C# random test (and maybe others), some of the "words" being tested contain underscores and lower case characters. This is not mentioned in the instructions (and, as I was using an underscore to replace used characters, it was driving me crazy)
An elegant solution, but I have one quibble. I wouldn't do the entire search in the ctor. Basically, it's poor usage of time. You hadn't been asked to find the word yet, and if no one calls Check(), you will never need to. So, why waste the time doing it before you have to?
You cannot have a flush and a pair. Your example has two deuces of diamonds. That would be an illegal desk.
This is an interesting technique, and would probably be best -- if there were new types of hands being created. However, since we've had the standard hands for over 100 years, that seems unlikely.