![]() StartingPoints Referenced by
|
Lost Board Edge
Robert Pauli: I'd like to see if the diagram edge is the board edge or not, even in case the diagram edge happens to be filled with stones. If the problem (October 1, 2003) isn't yet clear, please take a look at this diagram from EndgameConnectOrNot:
Alain Wettach spotted a seki above, but Charles spoiled the joke by pointing him to assumptions of yose problems. If you enter the edit mode, you note that the stones on the top and the right side aren't on the board edge, so Charles is right, but of course Alain is right too if what is shown is a complete (10x5) board, and there's absolutely no visual clue that this isn't the case - and that's the problem. I suggest the following solution:
Note that I don't suggest to always show some fraction of the hidden "tiles". Even if this would give positive information also in the no-board-edge case, it would force us to additionally specify what's directly beyond the cutting line - not what we want I guess. To be totally explicit (I just don't trust programers ;-), here are the tiles (each a grid point or intersection) and where (***) they are to be extended: ********* ********* ********* --------- --------- --------- *| | | | | |* *| | | | | |* *| .----| |----.----| |----. |* *| | | | | | | | |* *| | | | | | | | |* --------- --------- --------- --------- --------- --------- *| | | | | | | | |* *| | | | | | | | |* *| .----| |----.----| |----. |* *| | | | | | | | |* *| | | | | | | | |* --------- --------- --------- --------- --------- --------- *| | | | | | | | |* *| | | | | | | | |* *| .----| |----.----| |----. |* *| | | | | |* *| | | | | |* --------- --------- --------- ********* ********* ********* Please don't forget ********* ********* ********* --------- --------- --------- *| | | | | |* *| | | | | |* *| .----| |----.----| |----. |* *| | | | | |* *| | | | | |* --------- --------- --------- ********* ********* ********* nor their vertical variants, nor: ********* --------- *| |* *| |* *| . |* *| |* *| |* --------- ********* So, this also is a call for linear boards - look at this trash:
Sebastian: Robert, I challenge you to play on either of these boards (as long as I get black and we do area counting.) :-)) Karl Knechtel: At 6.5 or heck, even 5.5 komi, I'll take you up on that offer :) Sebastian: ROFL - looks like a d'ohsuji! Robert Pauli: Don't be so darn pragmatic, boys. It's a matter of perfection, not of need. (And, by the way, Sebastian, isn't the color of no importance in the 1x1 case, with no komi and whatever scoring method? Another proof that no-pass go just isn't it.)
Bill: My fix, which I have applied in several places here on SL:
'_' makes a blank space. The idea is that stones adjacent to blank spaces are alive. (And, OC, they are not at the edge of the board. :-))
Linear boards are another question.
Sebastian: Isn't Bill's solution just the opposite of Robert's? Robert wants the bord to be blank at its edge, and Bill uses blank to denote a field with anything on it. I would prefer Robert's interpretation, but since Bill already contributed several such diagrams it would not be practical to change all of them now.
How about this? "x" stands for "anything". -- 2003-10-06
RafaelCaetano: There are some problems with your solution. First, it's ugly. :-) Sebastian: Well, de gustibus non est dispuntandum. The x is admittedly more obtrusive than just leaving it blank, but that's precisely why you start thinking about its meaning. But I misunderstood Bill's intention.
If you just want to express that the black stones are alive, why not just draw it like this? This does all we need for an example. Even I as a beginner wouldn't be mislead into believing that this wouldn't apply if some of these fields were actually not empty. If there is any doubt then you need a textual explanation anyway, regardless whether the diagram shows xs, empty or blank fields. Bill: I admit that I do not like the looks of my "solution". Go books tend to use diagrams such a Sebastian's. But from time to time that leads to ambiguity and confusion. One advantage of my diagrams is that all possible points to play on are shown, and only those. Some of the theoretical go literature, such as ''Mathematical Go'', use partial stones as immortal stones framing a diagram. IMO, that looks even worse. Robert Pauli: I fully agree, Bill. I don't like partial stones either, and I neither like your solution: I rather show nothing in the no-edge case. So, in the end, it's not my solution, it's just one I was forced by logic. Here's the relevant part of the Bug Report to understand why the whole case is on ice: Robert Pauli: I'd like to see if the diagram edge is the board edge or not, even in case the diagram edge happens to be filled with stones. dnerra: Thanks for adding images sizes to the diagrams Arno -- it also makes rendering much smoother and faster (for me with konqueror). Robert Pauli: Just not to get lost, I wasn't talking about some browser failure, I was/am pointing to a logical problem, creating ambiguity: Arno: I understand the problem, but the fix (slightly larger images to show the "rim") would mean recreating all >11000 images, as otherwise I would have to drop the image size attributes again and the clickable image maps would be slightly off the mark too. The work/benefit ratio makes this a low priority todo item. Robert Pauli: Intimidating, indeed, Arno, but couldn't at least freshly generated images benefit? Arno: no. The new images would have a different size (larger, to show what's beyond the border). Quote: ''Otherwise I would have to drop the image size attributes again and the clickable image maps would be slightly off the mark too.'' Robert Pauli: Sorry if I don't understand it, Arno. Doesn't every image have its own size attributes? How does adjusting one image and its attributes influence another? Arno: the image size is calculated on the fly from the wiki source - it is not stored in the database. I don't want to examine the stored image files before generating the page as each additional file access is expensive in terms of the server's workload. So either all images are alike and thus the size can be calculcated (current status) or the size is stored in the database - then images can differ. That would require more change than I'm willing to put in at the moment to fix this minor (to me) problem. Robert Pauli: Thanks for making me understand, Arno, and of course you're right: it's just a minor problem. Robert Pauli: Arno rimmed the board. Let me try it:
This is a copy of the living page "Lost Board Edge" at Sensei's Library. ![]() |