News for hackers. Stuff that matters.
Re:From hours to 360ms: over-engineering a puzzle solution by toast0 on Saturday February 08, 2025 @05:26PM (#42986716)
I don't think it would make a large difference in runtime, but the bounds aren't quite right.

The largest possible value isn't 999,999,999, because that's not a legal value. The largest value is 987,654,321

Dividing that by 9, you get 109,739,369, but that's not a legal value either, you'd want to start with 109,738,365 for the gcd as it's a valid possible row. I don't know that all gcds would need to be a valid row, but any gcd larger than 98,765,432 would need to be used at multiples from 1-9; with that gcd or smaller, multiple 10 becomes viable and the gcd doesn't need to be valid with multiple of 1.

Re:From hours to 360ms: over-engineering a puzzle solution by Someone on Sunday February 09, 2025 @08:15AM (#42990475)
[delayed]
Re:From hours to 360ms: over-engineering a puzzle solution by toast0 on Sunday February 09, 2025 @11:52AM (#42991792)
Yes, I think you're right!
Re:From hours to 360ms: over-engineering a puzzle solution by amyres on Sunday February 09, 2025 @11:01AM (#42991455)
One more nitpick on the upper bound of the GCD: since we know that 0 is going to be in every column, one of the row numbers must start with a 0 and will be an 8-digit number (0 in the first cell). The GCD can't be larger than the smallest row number.

The GCD search should start at 098,765,432 and then go down from there.