RSW wrote:When I have time, I'll add some additional diagnostic code to my program so that it will give better details of what it considers to be the BUG candidates and the +N candidates.
Good idea. I would have started with that before coding anything else. How did you expect to verify the results of your code in the first place?
The program now produces grid diagrams as shown in my previous post, but without any annotations. So it's currently of limited value. It shouldn't be too difficult to have it add annotations, and I'll do that when I find the time.
You can add those manually too, you know. It's an excellent idea to have your program eventually produce that stuff in a presentable form, but in the meantime you could just edit it yourself. It's probably quicker. (Or do you have a principle that you can't manually touch anything your program outputs? This is related to the discussion in the Puzzles section as well.)
SpAce wrote:Are you sure you know the definition of a BUG?
Good question. Obviously, a BUG+1 is easy to ID and to solve. ...
I must guess the answer is no, then. Fixing that is where you need to start with BUGs. How you actually use them for solving has meaning only after you know for sure when you have a valid BUG+N situation and when you don't.
However, the reason why I started this thread in the first place is because in any of the explanations that I've come across, things start to become very vague for N>1.
You only had a vague understanding, yet you thought it was a good idea to code a generic solver for BUG+N of any size N and confidently post its results? You're much braver than I am, that's for sure
Did you read the BUG+3 thread I linked at the very beginning of this discussion? Not sure what you consider vague, but there should be pretty detailed answers to your questions. You just probably lack some prerequisites to understand it all. I'd recommend you started gathering those by studying basic chaining, i.e. AICs, first. They're easy because they only have two end-points to worry about. If you understand them, then you can easily understand how BUG+2 (and some special cases of larger BUGs) work. Bigger than that and you need Kraken (i.e. Forcing Chain; verity type) logic, which is more complicated but also pretty easy to understand if you know your AICs (the same idea but with multiple end-points).
If you don't have that stuff under your belt, you really can't expect to understand how larger BUGs are actually used, and if you don't understand it, you can't expect to be able to code it correctly either. It's probably not trivial to code even if you do.
Again, I think that in the case of a BUG+2 or +3 it's clear that at least one of the +N candidates must be true to prevent a deadly pattern.
You got that exactly right. It's the same for any BUG+N, and that's all there is to it. Really. You just have to know how to use that knowledge, but for that, read the previous paragraph. There are plenty of good sources that explain those prerequisites in detail.
The question then is how do you determine which of the +N candidates is the correct one. This is where the descriptions seem to get very vague.
Because it's the wrong question. Read (again) what I wrote
here. Yogi had very similar problems with the BUG stuff but he eventually got it, I think. I'm not about to repeat myself, so read it again until you get it too, or find better sources if you can. More than anything, study those mentioned prerequisites, because I'm pretty sure that's where the real problem is. It's also a must for understanding and posting one-stepper solutions in the Puzzles section. Once you master those, then this stuff should be self-explanatory.
From what I've seen, these candidates are just tested with some simple chain technique, which is really just a restricted T&E. If there's some more direct logic involved, then I haven't found any explanation of it. Certainly not in general terms.
Dunno what you mean by "general terms", but otherwise you've certainly found it. You just either haven't read or understood it. It's got nothing to do with T&E, but because you thought it did, that's how you implemented it. As a result, your BUG logic now has everything to do with T&E (which looks for contradictions) and little to do with BUGs (which are typically used to produce verities). AICs and Krakens produce verities, not contradictions. A very important distinction.
It's also worth asking whether my solver program knows the definition of a BUG.
How could it if you don't?
I didn't back check them. I just quickly ran them and posted the results.
So it seems. You have surprising confidence in the results of untested software implementing poorly understood concepts.
It is interesting that it was able to take these detected patterns and then solve the puzzle. Even though these may not be true BUGs, it appears that the solve logic is still valid.
Yes, the solve logic for your contradiction chains/nets seems to be fine (probably), but it has little to do with BUGs or other solving methods typically preferred by humans. Still, you can certainly build on that foundation once you understand other types of chains better. (Edit: I just took a closer look at your chains which turned out to be mostly nets, actually. That's something else to think about, as linear chains are preferred whenever possible.)
Added. I can see one possibility of using your approach to solve BUGs in multiple steps, but it's not very elegant or efficient. It's also explained in the BUG+3 thread
here as the two-stepper solution. In other words, if you can't form a single AIC or Kraken to use a BUG+N with a large N directly, then you can first eliminate some of those plus-candidates to make the N smaller. Your T&E contradiction chains/nets would surely do the trick, but they're not very elegant, especially for presentation purposes. Also, unless you can reduce it all the way to BUG+1 (which is not always possible, of course, because the +N may contain several true candidates and you can obviously only eliminate false ones), you still need to know how to do the actual BUG-solving at the end (the principles are the same no matter the size of the +N).
For example, if you wanted to try that approach with the BUG+22 of Jan 24, you would need to eliminate 20 candidates to get to BUG+2 (it has two true +N, which you of course can't know beforehand) which is much simpler to solve but might still need an AIC (and does, but a very short one -- see next post). Of course that elimination process may solve the puzzle earlier by other means, but you get the idea. You also see that in the worst case scenario that kind of BUG-solving process would mean 20+1 steps, which obviously isn't very efficient for a puzzle that can be solved in one short non-BUG step. Thus it makes no practical sense to use such huge BUGs, no matter how you do it. The single-step Kraken approach (my way) may be more elegant, but not really more efficient except in the step-count department -- that's why my BUG+23 was certainly not meant as a practical solving example.
Note: From the previous observations one can conclude that a much more efficient way to use a BUG+N with a big N is to target
anything but its plus-candidates. So, once you get your algorithm to recognize BUGs and their plus-candidates reliably, you should probably do the exact opposite of what you've been trying to get to a solution quickly. Instead of using the set of plus-candidates for T&E, use its complement. That should break the puzzle in no time.
