Tarinaa ei kerrota vain sanoilla, vaan se jatkuu tavoissa, liikkeissä, musiikissa, artefakteissa, perspektiivien jäävuorten vedenpäälisinä huippuina - siinä, kuinka valo heijastuu kuunylisinä kaarina taulun maalipinnasta.
I am going to get my weekly dose of sushi now. As they say, appetite grows by eating, so there needs to be always a bigger fish. Chef is the big fish in a small pond, especially when preparing something like Fugu. I don't know if you can actually buy it in Helsinki, but eating without danger of poisoning is.. like a fish without a bicycle. And this ain't no fish story, but nonetheless, there is something fishy going on here.
(Running Wild - Marilyn Monroe (Some like it hot))
absolutely forced moves (anything which is obviously urgent)
thick plays (if there's a weakness)
influence
oba (for the purposes of this list, an oba is defined as any move which is mutually big)
large territorial plays (this can include invasions and keshi)
others (e.g., gote-no-sente, kikashi)
I think you should use higher priority for kikashi.
I suggest following procedure after you have decided your move: Now you have more information about the future of the game than your opponent. Think if there are some plays in other parts of the board that your opponent would answer your moves differently if he knew your next move. Then play all "non-harmful" sente-enough kikashi plays of this type before your actual move.
Also I would suggest that always try to visualize a couple of moves ahead after decision and before placing the stone to avoid rash mistakes we amateurs do so often.
Use your opponent's time for life&death considerations, calculate territories etc.
Also in the late endgame forget the rule reverse-sente is twice the value of gote. It is not accurate enough if you just have a couple of minutes for thinking. Quite simple and as far as I understand better algorithm for simple endgame is to put gote plays in descending order g1,(g2),g3,(g4),g5, .. and calculate the difference of sum of odd and even indexed lists of gote plays and compare this to the size of biggest reverse-sente. Now you can see that the value of gote is something between 0-1 times the actual value of the move (and reverse-sente is its actual "gote" size). But more importantly: Most mistakes in the endgame of amateurs at my level (2k*) are misreadings of size of the move, not the actual order of moves, I think.
If you want to apply this algorithm to the beginning or the middlegame, maybe you could just pick the couple of biggest gote looking moves, evaluate their approximate size and do the subtraction to these moves (like above) and approximate the end of the gote-move list as 0.5*biggest remaining gote (0.5 is the average size of the gote play - My guess is that this approximation of gote size will be much more accurate in "slow" territory contest games than in fighting/mojo games). It is also nice to see how the concept of miai comes from this algorithm.
sfnet.harrastus.pelit.go: Ryhmän sfnet.harrastus.pelit.shakki epävirallinen kuvaus
5.3.2000
Pekka Karjalainen kirjoitti:
Tosin shakki 19x19 ruudun laudalla ja vastaavalla nappulamäärällä olisi myös helskutin vaikeaa tietokoneille, tai ainakin minusta tuntuu siltä.
Tietääkö joku, onko tätä kokeiltu?
Oma arvaukseni on, että tietokoneet pärjäisivät ihmiselle myös 19x19 shakissa melko hyvin vastaavilla algoritmeilla mitä nykyään käytetään. En ole perehtynyt mihinkään kehittyneisiin shakkiohjelmiin, mutta käsittääkseni ne ovat silti pääpiirteittäin "raaka voima"-tyyppisiä ratkaisuja siten, että lauta evaluoidaan suhteellisen yksinkertaisilla funktioilla kuten materiaali ja liikkuvuus sekä laajat alkupelikirjastot. Eikö tämä osoita, että ihminen ei kykene luomaan kovin korkeatasoisia malleja shakin muuttuvasta ja kaoottisesta alku/keskipelistä? Jos shakin luonne muuttuu siirryttäessä isommille laudoille, täytyy taktiikasta "modularisoitua" runsaasti selkeitä kokonaisuuksia, jotta ihminen pystyy hallitsemaan tuon kompleksisuuden.
rec.games.go: Everything is comparable (was: chess versus go)
12.4.2000 9:00
Fu, Ren-Li wrote:
Because Go is a vastly more complex game than Chess, especially in the middle game, it is therefore more interesting to the kinds of people who like go and chess as strategy/thinking games (which is about everyone who likes go and chess).
What do you mean by complex? If you say that go is better game than chess to those people because the number of legal games is greater, it is very easy to invent more complex (and better?) games. From a certain perspective chess is more complex than go because the middle game tactics are so "global" and chaotic that human cannot create efficient enough mental model of the strategy to win comparatively brute force computer algorithm. Deep Blue is still far from solving chess completely. In go, (because of many symmetries) we can create a structure of modular concepts that efficiently simplifies the game and therefore it is even possible to good players to calculate some long tactical sequences correctly. This is what makes go a more interesting game for me than chess - because it is "simpler" to a human being and allows us to use our ability to handle abstractions of different levels. I think that this "understanding" of the game makes it more "meaningful" to me.
(Hardest Geometry Problem in the World- Mark Mothersbaugh)
So now you admit that the design objects can go on their merry "unreal" way, so long as they are traceable to the "real world". Excellent. We have made progress at last.
I think that the "real world" is always our own arbitrary mental map ("design") of the surrounding world and data abstractions in OO reflect the way human brain organizes information. Objects are only some discrete entities or concepts with some interpretation attached to them. Because most of our concepts are some way connected to the physical world and they exist in time, we need state information in most of our objects. Also we can think that interactive software connects some computer objects with real world "objects" (users, peripherals). We want to organize the digital world the same way we do the real world.
I won't disagree with you here. I will emphasize the "start with". Your real-world key domain entities help us get *started*. Finishing is another matter. That has been my point all along.
I think that there isn't any human conceivable algorithm for converting a software specification to a modular design ( I would concider that algorithm to be intelligent). Of course it is possible to develop rules and heuristics but in the end its a question of "understanding" (having efficient model of the problem domain, that is design) the problem domain. This applies to all programming paradigms but because of OO we can map our previous understanding more directly to programming concepts. This is why OO gurus start with real world entities: they are familiar and we already have some "mental designs" for them.
comp.object: Is a Design good?
13.10.1999 9:00
Robert C. Martin wrote:
2. The analysis and design are not the "hard" problems. The hard problems are *proving* that the analysis and design work, by coding it; and refitting the analysis and design when the inevitable problems happen. The "hard" problem is to *preserve* the design as the code and environment put pressure upon it.
I think that coding isn't efficient way of proving that the analysis and design work because of the low abstraction level. Of course this doesn't mean that algorithms are allowed to be slow. Often an experienced programmer can instantly "see" that an implementation behind an interface doesn't affect design and it is possible to implement efficiently.
At least we should aim for software development where we need few very good designers and lots of coding power so that we can transfer the knowledge of the few to the whole system even if it is a large project.
18.10.1999 9:00
Michael C. Feathers wrote:
The interesting thing that I see about modeling is that it is not much different from coding except that you leave out the meat. In other words, if you say that a method will do something it is taken on faith. Once you add a complete specification of the method's behavior, you might as well have written the code. Models often aren't at a truly different level of abstraction than code. If they were, the models would deal primarily with abstractions larger than classes. The way modeling is done today, classes in models often correspond directly to classes in code. You identify your methods and fill in their bodies later, as if you were coloring in a coloring book.
Classes in models correspond directly to classes in code because classes in code are the general programming mechanism in most OO-languages. That doesn't mean that classes could not use other classes abstractly. If you think an OO-program having only one abstraction level - the code - I think you are missing the point of OO.
The sad fact is, that the internals of methods are paramount in design. Without them, you have no way of demonstrating correctness or evaluating performance. You start specifying things in models without any correctness feedback. It is too easy to believe it works rather than know that it does.
It is always a matter of belief but the point is to what extent.
IMHO you are simplifying too much. I think that the main reason we encapsulate methods and data in OO is that we want to create new concepts, that is to construct more abstract entities compared to the basic programming structures (in a way C++ is already a more "abstract" Turing machine). Of course we can apply this recursively. By abstract I mean here that we can understand the object more easily from some other context with some default interpretations attached to it (its methods). It is also "easier" to have faith on C++'s while-loops than some assembler code.
It is very important to hide the implementation in modelling. For example, if we are developing a banking system and want to model an user, the power of abstaction comes from the fact that we don't need to think the colour of the user's eyes. If we have 3 organizational hierarchies in our design (A,B and C), usually A uses B's interpretations and B C's but A doesn't need to understand anything about C. So, if we demand that the whole program should be coded just to prove that A's relationship with B works, then we need to code also C. At the top of this abstraction hierarchy is the end-user and her context.
My view of the OO is just that we build a ladder of abstraction levels or contexts until it matches with end-user's reality. But when we expect the end-user to provide us with the specification of the program (the whole program is after all one huge object in itself) we don't demand that she could program it by herself. In many large projects it is important to create many layers of abstaction to reveal the hidden structures of the real world if we want to extend or modify our system later. Very often our end-user isn't aware of these "hidden" mid-level abstraction levels. That is because the layers are more general than her own context (for example in banking system the user of ATM system doesn't need to know about money transfers between banks, even if banks and users have some common properties) or the abstractions are so low-level that they interest only programmers (for example the need to code a modular implementation of a data structure that the programming environment doesn't support very efficiently). When we build these new mid-level contexts, we are analysing and designing. It is important to understand, that it is NOT necessary to code the lower contexts entirely that we can say it doesn't make the system slower by an order of magnitude.
I once told someone that if there is a person on the team that you don't trust enough to design, then one of you has to go. Everyone who can understand the design can participate in the design, otherwise they are being wasted. The design has to be simple enough for everyone to understand, and everyone has to be smart enough to evolve the design.
Again, there isn't just one level of design. I can trust some hacker to design a fast data structure or algorith for me, but I wouldn't let her to design the user interface or the overall structure of the system. It may even be waste of resources to teach OO-method to everyone in the project.
("Weird Al" Yankovic - It's All About The Pentiums)
