How would you program this?

[engsol]

On Thu, 3 Mar 2005 15:32:36 -0500, Bill Mill <bill.mill at gmail.com> wrote:

>On Thu, 03 Mar 2005 10:52:23 -0800, engsol <engsolnorm at peak.org> wrote:
>> 
>> The diagonal constraint is interesting....it seems to affect the number of
>> solutions. One surprise, (not being a math major), was that when I let the
>> brute force run (forever, it seemed), but without the diagonal qualification(s),
>> there was maybe 100 solutions. The reson it was a surprise it that years
>> ago a programmer used the row-sum, col-sum method to detect and correct
>> data errors. He swore it was robust, and 100% reliable. Seems that that
>> isn't the case.
>
>I think that it probably is a decent gut-check for data errors, for
>the simple reason that changing one number requires, at a minimum,
>three other changes in order to maintain both the row and column sums.
>If you have at least a decent data fidelity rate, that is unlikely to
>happen, and even if it does, very very unlikely to happen in such a
>way that the row and column sums are maintained; especially as the
>number of rows and columns grows.
>
>Better to just do a crc or a hash of the data though.
>
>Peace
>Bill Mill
>bill.mill at gmail.com

You make a good point Bill, and are entirely correct. 
I never liked that programmer, and was too hasty in 
condeming his work...shame on me....I was unfair.

BTW, I ran the code you suggested, (I like your approach), after
correcting the A cell value (should have 5 vice 3 as I posted). There seems
to be 16 solutions, one of which agrees with the puzzle author.

I don't fully understand this line of your code:
return [(a,b,c) for a in ns for b in ns for c in ns if a + b + c == limit]
If  the "if" part is true, does it  'trigger' the return?
Norm B