Hi eleven,
eleven wrote:I only could see this:
(9278=1)r8c6789 - (17=8)r9c39 - (8=9)r3c9|r7c1
On second thought: maybe we just have to get more familiar with (fixed digits and) or'ed cells (as we are in the meantime with fixed cells and or'ed digits).
Problem is, that notation is ambiguous. You'll see why if you reverse it. What you mean is this:
(9278=1)r8c6789 - (17=8)r9c39 -
(8)r7c1&r3c9 = (9)r7c1|r3c9 => -9 r7c9
Thus, when the blue part is replaced with
(8=9)r3c9|r7c1, the fact that the 8s are ANDed gets lost. It doesn't seem like a problem when read from left to right, but it becomes obvious the other way. So, as per current rules, that shortcut is incorrect, and I can't see a good way to make it work if the integrity and reversibility of the AIC are to be maintained.
I do agree that it's short and nice and perfectly understandable when read from left to right, but it also has a big downside. We've discussed this before with Steve and agreed that, while tempting, such an exception is not a good idea. I'm all ears if someone has opposite arguments.
Btw, here's another (ugly) possibility:
(9=8,87)r3c9,b7p19 - (8|7=1)r9c9 - (1=2789)r8c6789 => -9 r7c9
I followed your lead
here for that first term. At first it seemed weird to reuse a digit within a bracketed node, but I don't think there's anything logically incorrect.
But in this case (and probably many others) i would prefer the DB ...
Me too, for any practical purposes. Cenoman's DB was very nice. That said, writing complex AICs is always fun. In fact, it's often more fun than reading them