On Tuesday, 21 August 2012 at 15:55:08 UTC, maarten van damme
wrote:
Thank you very much, this makes everything more clearer. I'm
not very familiar with binary operators so the comments help
out a lot. Would you mind it if I shamelessly copy your
solution of using shorts to store possibilities in?
Binary operators are fun :) Once you get the hang of it you know
exactly what you're doing. Think of AND = Keep only, OR = Set,
Xor = switch state. so.
AND &
source 0 0 1 1
data 0 1 0 1
result 0 0 0 1
OR |
source 0 0 1 1
data 0 1 0 1
result 0 1 1 1
Xor ^
source 0 0 1 1
data 0 1 0 1
result 0 1 1 0
Was that sarcasm? My own code only uses copying when it's
working in the next section of brute force, otherwise it's all
referenced.
No, that wasn't sarastic. If you look at my last code you see
that I "compose" the squares using something like [....] ~
[.....] ~ [.....] Using a foreach loop and copying the values
was 10 times faster...
Curious. With fixed array sizes it should do a bulk memory copy,
unless you are going from static/fixed to dynamic. Also curious
is in my code it allowed me to do a forced struct copy (move?)
when I found a success and just copied the result to the current
structure. I'll post my two revisions up later.
I only use exceptions twice and both when it would be unable
to find a solution; I suppose I can try putting nothrow on
everything and return a bool if it had an error for solving,
or when it had to, inside a structure. Mmmm... I'll give it a
try.
Yes but when your solver reaches a solution that is wrong, you
get a whole "branch" of numbers falling of, all throwing a
"broken sudoku" exception. It will rarely be called once.
True. I already tried removing it, and curiously enough the code
performs 10x-200x faster. Except all my debugging statements now
fail since they aren't nothrow :P
Not normal but it can be arranged. :p
But I used it in my getRegion code where I do simple
calculations on the contents of that array. It is slower
there...
