[computer-go] MyungWan vs MoGo
Hello, on September 21, there was a new exhibition match between MyungWan (8p) and MoGo (on massive hardware). They played two 19x19 games with 7 stones handicap, first a short warm-up with 15 min per side, and then a long one with 90 min per side. The short one turned into a loose-ladder catastrophy for MoGo, the longer one ran more or less normal, with the pro winning clearly in the end. sgf of both games may be found at http://www.gokgs.com/gameArchives.jsp?user=mogotitan Some interesting analysis on the second (long) game has been done by Thomas Redecker with the help of the analysis/score- functions of Many Faces of Go 11 and SmartGo 2.8. He condensed the result into scoresheets, which you can see at http://www.althofer.de/thomas-redecker-on-myungwan-vs-mogo.gif The diagram in the top is by MFgG, the lower one by SmartGo. The fat red bars have been included by Thomas Redecker. Ingo. PS: Thx to Thomas for allowing me to hang in the gif on my homepage. Originally, it was posted in the (German language) forum of the DGoB, but is a bit difficult to find there. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
Quoting Mark Boon [EMAIL PROTECTED]: Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? The interesting question is if there is a silly bug or something more sophisticated. I have struggled with ladders in Valkyria and it is often really hard to tell what causes these problems. In Leksand most games on 19x19 where lost in a ways similar to the recent mogo game. I could not find an obvious problem with the playouts at least not in terms of an easily fixable bug. Note that Valkyria reads out 99% of all ladders correctly both in the tree and in the playouts. What I realized was that AMAF in combination with heavy playouts causes some serious biases, for some kinds of very bad moves such that AMAF completely misevaluate them. In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
I'm curious about a couple of things in particular. Is this a bug and how much time would be required for Mogo to have played the correct move if it wasn't. Of course I'm also interested in ways to solve this with less deep searches or better play-outs. - Don On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon [EMAIL PROTECTED]: Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? The interesting question is if there is a silly bug or something more sophisticated. I have struggled with ladders in Valkyria and it is often really hard to tell what causes these problems. In Leksand most games on 19x19 where lost in a ways similar to the recent mogo game. I could not find an obvious problem with the playouts at least not in terms of an easily fixable bug. Note that Valkyria reads out 99% of all ladders correctly both in the tree and in the playouts. What I realized was that AMAF in combination with heavy playouts causes some serious biases, for some kinds of very bad moves such that AMAF completely misevaluate them. In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
I think AMAF is a feature not a bug. It's only a matter of how judiciously it's applied. Also, almost any evaluation feature in a game playing program is a bug - meaning it is an imperfect approximation of what you really want. Of course it could turn out that AMAF got them in trouble in this game. The Mogo team will probably analyze the reason for the problem.But as long as they are playing strong professional players they are going to have something to debug and analyze! - Don On Mon, 2008-09-22 at 06:06 -0700, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] MFG 12 and Cotsen Tournament
David Fotland graciously permitted me to enter a development version of Many Faces of Go in the Cotsen Tournament. It played five games, losing the first three to 3 kyu players, and winning the last two against 4 and 5 kyu players. I also played a 9x9 game, where I was able to create a seki, robbing MFG of a few points of territory, thereby defeating it. This 9x9 game is attached. I'd be interested to see programs which correctly handle such situations. David, many thanks! I am looking forward to the new improved version of MFG, and hope these games help. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan make_seki.sgf Description: application/go-sgf ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Analysis of 6x6 Go
Stefan Reisz is the author of the website http://www.reisz.de/gohome.htm There he claims to have a solution for 6x6-Go with Japanese rules. The outcome of his handmade analysis is that komi=3 would be fair. The analysis may be downloaded from the site, as sgf file. Does someone here know of other (documented) attempts to solve 6x6 Go? Ingo Althofer. PS: After some hours of interactive analysis with Leela my impression is that in case of Chinese rules the value of 6x6-Go might be +2. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] MFG 12 and Cotsen Tournament
Thanks Terry. Let people know what hardware you were running on. This version is a little weaker than the ManyFaces on KGS that has a strong 3 Kyu KGS rating. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of terry mcintyre Sent: Monday, September 22, 2008 6:43 AM To: computer go Subject: [computer-go] MFG 12 and Cotsen Tournament David Fotland graciously permitted me to enter a development version of Many Faces of Go in the Cotsen Tournament. It played five games, losing the first three to 3 kyu players, and winning the last two against 4 and 5 kyu players. I also played a 9x9 game, where I was able to create a seki, robbing MFG of a few points of territory, thereby defeating it. This 9x9 game is attached. I'd be interested to see programs which correctly handle such situations. David, many thanks! I am looking forward to the new improved version of MFG, and hope these games help. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] MoGo v.s. Kim rematch
AMAF certainly helps to do move ordering when there is little other information. With good prior heuristics or enough actual playouts, it should not be weighted very highly. AMAF finds good moves, but it often bias heavily for or against moves. In ManyFaces, AMAF (actually RAVE) is worth between 5% and 10% wins against gnugo. I've seen similar ladder problems, and it is not AMAF, it's caused by the playouts, when they can't read ladders. It's easy to add various hacks to prevent playing out simple ladders, but the one in this game had an extra liberty (if I remember correctly). A general solution is a little tricky. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Monday, September 22, 2008 6:23 AM To: computer-go Subject: Re: [computer-go] MoGo v.s. Kim rematch I think AMAF is a feature not a bug. It's only a matter of how judiciously it's applied. Also, almost any evaluation feature in a game playing program is a bug - meaning it is an imperfect approximation of what you really want. Of course it could turn out that AMAF got them in trouble in this game. The Mogo team will probably analyze the reason for the problem.But as long as they are playing strong professional players they are going to have something to debug and analyze! - Don On Mon, 2008-09-22 at 06:06 -0700, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MFG 12 and Cotsen Tournament
I was runing on an Athlon 64x2 laptop. Unfortunately, I could not get MFG to work under Wine on my quad Intel; would love to see how well it does with better hardware. Regrettably, I have no Windows installation media for the quadcore. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan - Original Message From: David Fotland [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Monday, September 22, 2008 8:02:20 AM Subject: RE: [computer-go] MFG 12 and Cotsen Tournament Thanks Terry. Let people know what hardware you were running on. This version is a little weaker than the ManyFaces on KGS that has a strong 3 Kyu KGS rating. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of terry mcintyre Sent: Monday, September 22, 2008 6:43 AM To: computer go Subject: [computer-go] MFG 12 and Cotsen Tournament David Fotland graciously permitted me to enter a development version of Many Faces of Go in the Cotsen Tournament. It played five games, losing the first three to 3 kyu players, and winning the last two against 4 and 5 kyu players. I also played a 9x9 game, where I was able to create a seki, robbing MFG of a few points of territory, thereby defeating it. This 9x9 game is attached. I'd be interested to see programs which correctly handle such situations. David, many thanks! I am looking forward to the new improved version of MFG, and hope these games help. Terry McIntyre Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
On Sep 22, 2008, at 7:59 AM, Magnus Persson [EMAIL PROTECTED] wrote: In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? My RAVE formulation includes a per-move parameter for RAVE confidence. This allows heuristics to fix situations like above. Sadly, my bot isn't mature enough to take advantage yet :( The concept I used for the derivation is simple. I treat everything as gaussian estimators. It's easy to find the max of the distribution. I then use the same trick as bayeselo to estimate variance. I then add a Gaussian noise term to represent RAVE bias. The results of the math are most easilly expressed in terms of inverse variance (iv=1/variance) Combined mean = sum( mean * iv ) Combined iv = sum( iv ) I'll try to do a real write-up if anyone is interested. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Cheers, David On 22, Sep 2008, at 6:06 AM, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: sgf format for non-quadratic board sizes?
every point having 4 liberties would seem to make the opening much more about influence. my guess is that it's an easier game. (but that's just wild speculation). s. On Fri, Sep 19, 2008 at 2:30 PM, David Doshay [EMAIL PROTECTED] wrote: First move is easy, but depending upon ratio of diameter to length of torus, ladders can get complicated. Cheers, David On 19, Sep 2008, at 10:48 AM, Álvaro Begué wrote: On Fri, Sep 19, 2008 at 1:29 PM, Don Dailey [EMAIL PROTECTED] wrote: Would go on a torus be interesting? There are not corners or edges, the sides of the board simply wrap around. - Don Yes, it's probably similar in spirit to regular go, except everything feels like the center of the board. It would also make the first move easy. :) Álvaro. On Fri, 2008-09-19 at 09:52 -0700, Ross Werner wrote: Urban Hafner wrote: Ah, right. I thought you were talking about implementing this feature for your own program. Personally I don't know of any program that supports rectangular boards. There was a recent thread on GoDiscussions about this topic: http://www.godiscussions.com/forum/showthread.php?t=6960 Not much information there, but maybe enough to be useful. ~ Ross ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Analysis of 6x6 Go
Ingo Althöfer wrote: Stefan Reisz is the author of the website http://www.reisz.de/gohome.htm There he claims to have a solution for 6x6-Go with Japanese rules. This is not a solution in a mathematical sense because - it is not specified which Japanese rules are used - during the scoring, the rules are applied without showing exactly that - during the scoring, the number of studied hypothetical-sequences is zero instead of huge or infinite - in every move-sequence, the game is not ended by successive passes properly - MANY other possible moves are missing (and my manual study of some simplistic (but arcane) positions under some particular Japanese rulesets has convinced me that there are more unexpected but correct plays or passes than one fears) Too often the word solution is abused. preliminary study is more appropriate. The largest board for that I could solve Go under Japanese 2003 Rules manually was 1x1. Already 1x2 was too tough: While it is still possible to denote all hypothetical-sequences, listing all hypothetical-strategies is clearly no fun. Possible if one spends several days or weeks. But if somebody or a program claims to have solved under some Japanese ruleset, I am more than sceptical and want to see mathematical proofs. Although I have done preliminary studies of how to formulate and prove useful propositions, this is work for months. It doesn't matter whether proving scoring propositions is done manually or by algorithm. Only those board sizes that allow killing all are simpler because all you have to do is to prove just that. There are exceptional tiny board sizes that allow other types of elegant proofs, but they won't help much for bigger boards. Solving(!) Go under whichever Japanese ruleset is for the rules experts rather than for computer go. Does someone here know of other (documented) attempts to solve 6x6 Go? Didn't Erik van der Werf do it under his rules? -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Analysis of 6x6 Go
Hello Robert, thx for the feedback. Does someone here know of other (documented) attempts to solve 6x6 Go? Didn't Erik van der Werf do it under his rules? He did it for 5x5-Go, see at http://erikvanderwerf.tengen.nl/5x5/5x5solved.html Ingo. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] semeai
terry mcintyre wrote: On Thu, 2008-09-04 at 18:07 +0200, Rémi Coulom wrote: When the playouts evaluate a critical semeai the wrong way, then no supercomputer can help, even at long time control. Semeais require a better algorithm, because no computing power can search them out with a tree, and playouts have to be extremely intelligent in order to evaluate them correctly. Has anyone tried implementing the ideas in Richard Hunter's Counting Liberties in a manner which can be used to guide the playouts? Static analysis is hopeless. Local search may work with some level of precision but you will have to read much further ahead than in Richard Hunter's model positions before you can even reliably recognize them. In particular I wouldn't advise trying to cancel outside liberties without playing out the moves in some order, otherwise detecting the need for approach moves is extremely difficult. GNU Go makes an attempt at reading semeais but has trouble already differentiating between outside liberties, inside liberties, and eyespace, not to speak about weird interactions with the tactical reading (which mostly doesn't understand semeai) in low liberty situations. If you think this should be simple, have a look at e.g. page 53, diagram 17, in Hunter's book or try to do a static evaluation of the semeai in upper left corner at http://trac.gnugo.org/regression/regress.plx?nngs2:150 Things to think about for the latter position: * How big eye does black have around F19? * What can white do around E9? * How to handle white sacrificing the C11 tail? * Is there a liberty to be gained by playing A14? * Does white need an approach move at M18? * Does black need an approach move at B10? * What is A16? Eyespace, some other kind of liberty, or neither? For some more semeai fun I can recommend http://trac.gnugo.org/regression/regress.plx?semeai:133 (which has an incorrect solution in GNU Go's test suite). /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
David Doshay: [EMAIL PROTECTED]: It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Really previous Huygens used Ethernet? It's hard to believe... Hideki Cheers, David On 22, Sep 2008, at 6:06 AM, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
