2

Your recsolve method changes a value in the grid, then validates the entire puzzle, recursing if it's valid or aborting if that change broke the puzzle. However, changing one number only impacts three things. The column/row for the value that's been changed and the box that contains it. A change to the top left box isn't going to impact if the bottom ...


2

Note, I don't think about performance, only about kotlin. Iluminate branch in your when, you check if the rightIndex >= string.length+1. this means in the next branches the size is maximal string.length. Substring is exclusive, so it allows str.length. this means the second and third branches are identical. Use Set It would make more sense to me to ...


1

First of all, this is a very nicely written code. Before writing about the cur implementation, a few notes: I do not think n and m should be in main. It creates shadowing in the function. I added type annotation to the return value of the function. Since it's a generator it should be: Iterator[List[int]]. So you said you do not like the way cur is ...


1

Why are these two so different in speed? Casting as String was much faster: The cast is just a type check (1 or 2 JVM instructions), as iter.next()'s type should be String. The toString() call just does return this;, so it should be fast too. Actually, you can just write: String current = iter.next(); Correction: you could if you change the line to: ...


Only top voted, non community-wiki answers of a minimum length are eligible