Re: [computer-go] is Zen gone commercial?
Darren, If it doesn't work on Wine, you could always load a VM, like Sun's VirtualBox, install a copy of Windows in that and play from there. VirtualBox has very good performance metrics at above 95% of max (non VM) speed. And there's plenty of throw-away copies of XP licenses available all over the place as old systems retire and are replaced with newer hardware upon which Vista is now installed. Jim From: Darren Cook dar...@dcook.org To: computer-go computer-go@computer-go.org Sent: Thursday, September 24, 2009 8:00:03 AM Subject: Re: [computer-go] is Zen gone commercial? It is already shipped in Japan, as Tencho no Igo. http://soft.mycom.co.jp/pcigo/tencho/index.html Looks like Windows only. Anyone know if it will run under wine on linux? They are advertising it as 2-dan (i.e. Japanese 2-dan). A rather pricey 13,400 yen, or 10,752 yen ($120) online. Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/gobet/ (Shodan Go Bet - who will win?) http://dcook.org/mlsn/ (Multilingual open source semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ 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] Git, any other ideas?
Mark, I would figure that given the popularity of both Eclipse and git, the problems connecting the two easily, similar to the way Eclipse and Subversion connect, will be solved sooner rather than later. And once they are, it won't be too difficult to transition from whatever you choose to use in the interim. It's not like the core framework project is going to have a ton of supported branches or even contributors, right? BTW, I don't recall why you were moving off of Subversion. Why not stay there for the interim unless you have lots of coders who will be working on the framework (as opposed to being a client using the framework .jar-s). I figure the JAGS framework would only have a couple of contributors. It's the clients of the framework who want to experiment with the least investment in install, set up and indefinitely tinker who will gain advantage. And they don't need version control at all. Almost all of them will just be consuming the framework .jar-s and likely doing the development alone. And for those who are part of a team (or are just have to work with a one), they will be choosing their own VCS completely decoupled from the choices around the development of the JAGS framework. Jim From: Mark Boon [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Friday, October 24, 2008 3:13:09 PM Subject: Re: [computer-go] Git, any other ideas? On 24-okt-08, at 16:15, Zach Wegner wrote: Use git anyways ;) I don't use an IDE, but git works great for me from the command line. After I realized that git in pkgsrc was actually GNU Interactive Tools and not git, it took me just a few minutes to set up. The basic commands are really easy to learn, especially if you are familiar with CVS/SVN. There are also separate GUI frontends for git, so that might be an option worth looking at. Over my dead body :) If I don't get similar integration in Eclipse as Subversion I'm not interested. Now trying Mercurial. Also problems there, as it complains about some python library. At least the Eclipse plugin installed without a hitch. Mark ___ 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] yet a mogo vs human game
What were the software improvements? Were they related to the code distributing the work, or to the actual game playing/move selection code? Jim - Original Message From: Robert Waite [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Wednesday, August 27, 2008 9:54:14 AM Subject: [computer-go] yet a mogo vs human game * - MoGo was using 5% of Huygens (instead of 25% against Kim); * - there were some software improvements * - MoGo won 2 out of 3 games in 9x9 (even games) * - MoGo won with handicap 5 in 19x19 against the 6D player That is interesting... it used 1/5th of the processing power and got approximately the same rank (about 1 Dan). From what I gather.. Kim believed it was 2 or 3 Dan? I guess this is because a 9 stone handi starts to make the stone per rank estimation get a bit fuzzy. It is mentioned that there was a software improvement. I wonder how much the software improvement made up for the reduction in processing power since it seems to have stayed approximately the same rank. Or could it mean that dividing the computation strength by 5 did not change the relative strength of Mogo by much? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: linux and windows
All, Another option is to use a VM, MS's Virtual PC (free), VMWare's offering (free for non-commercial use) or any of the flavors of the open source Xen. Basically, you can set up an install of whatever target environment you use as a client OS. And then install and configure all you need and want natively within the Client OS without having to worry that the host OS is Windows. And for those of you who will say this is inefficient - I would just reply with, not participating at all is less efficient than at least participating with something inside a VM. There is no need for perfection, as in having every little tiny bit of performance eeked out of a box/processor/memory. If you can get +90% (which is what all the above VM creators claim for each of theirs), then you can participate and gain more experience for your particular computer_go player. Jim - Original Message From: Don Dailey [EMAIL PROTECTED] To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org Sent: Thursday, July 17, 2008 1:31:21 PM Subject: Re: [computer-go] Re: linux and windows terry mcintyre wrote: A cygwin port can't really be considered a windows application since it requires that the windows user install cygwin. This is not for the faint of heart. There are many good reasons why some people develop on Linux. Porting between Linux and Windows is not trivial. A better way to run linux programs on borrowed Windows machines might be to burn a LiveCD with one's program -- something akin to the Hikarunix CD, which tournament organizers could then pop into a computer, boot, and start the program. But you can compile using mingw32 to build native applications.I recently compiled my chess program and it runs fine, at least on recent windows OS versions - of course it is a UCI program which means the GUI is a separate windows program. - Don ___ 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] Mobile phone go player/client/recorder...
All, What's available in terms of a quality Go game player/client/recorder for mobile phones? I have a Windows Mobile 6 phone (ATT Tilt - 8925) and would like to be able to play the occasional casual game, be able to connect and play with someone else on their mobile phone or desktop PC and to be able to use the client to record games in progress and store them as .sgf files. I have already been to http://www.vieka.com/gnugo/ and that is a very nice start. However, it does not have the ability to play someone else except on the same phone. And it does not have a way to save a game or generate an .SGF. Any URLs to existing products would be deeply appreciated. BTW, it is not very useful that the game is named Go. I tried to Google for Windows Mobile Go Game and got lots of useless hits. The word Go is too common and only has a very weak relation to the Asian board game. Thank you, Jim___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] My experience with Linux
I'll second both the original poster (his troubles with Linux mirrored mine) and the reply (I was completely enthralled with Ubuntu...WOW!). Jim - Original Message From: Álvaro Begué [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, April 9, 2008 10:18:11 AM Subject: Re: [computer-go] My experience with Linux Get ubuntu (http://www.ubuntu.com/). You can ask them to send you a free CD. And you should consider getting a decent Internet connection. Álvaro. On Wed, Apr 9, 2008 at 10:54 AM, [EMAIL PROTECTED] wrote: I got excited about the free software sometime ago and bought a copy of Susie Linux. But the installation always hang up at some point and can never complete. I had to kiss my $20 goodbye and so much for the Linux. Recently my job involves embedded Linux. For whatever reason we used the Fedora version 4. It looks like the Windows 3.1. The newest version may be more modernized, which I don't have tme to fnd out. The Linux operatng system is about 600 Mbyte compressed. Since we have a fast internet, it took only 40 min. to download. After downloading we needed to find a software that can write ISO format on CDs. I failed to find such a software on the internet and ended up use the trial version of Nero. Then the Nero I installed highjacked my CD drive and I had to unnstall it later. I also tried the 64-bit version of Linux and the installation never worked. I begin to consder install Linux on my PC at home. With my internet connection speed, downloading 600 MB is just unrealistic. The other option is to order CD's. They cost $45 and up and I'm sure this cost will go up with time. So much for the free software. I keeps asking myself what will happen if the installation fails. I only have one computer and one internet connection. Not that I don't trust other people's opinion, but people pitched other things before which we never hear again. DL Get the MapQuest Toolbar, Maps, Traffic, Directions More! ___ 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] speeding up testing of computer go programs
Heikki, I'm with you. There is no wrong thinking at the present time. There are too many differing agendas, with building the strongest program immediately being only one, to claim any approach is futile, inefficient or erred. Once there are approaches that actually come near playing low dan levels against humans, I can see how narrowing approaches and thinking will become useful. Until then, lots of chaotic and random path experimentation is desirable, including other languages, specialized languages, techniques, etc. Jim Heikki Levanto wrote: On Sun, Nov 25, 2007 at 11:52:14AM -0500, Don Dailey wrote: I know that most go programmers don't concern themselves with small improvements because of the sense that there is bigger fish to fry. But this is wrong thinking. If you can get 10 small improvements it can be equivalent to one very large improvement. This is frong thinking *for you*. Wasn't it yourself who said that people program go for various reasons, only one of them being making the strongest possible program. A person with a more theoretical approach might lament that all that speed optimizing indeed improved the play considerably, but has not produced any new insight or theory on how best to approach the problem. A mere amateur like me could complain about the time invested in those small improvements, that I did not gain any new knowlege for myself, it was just routine programming. I humbly suggest that none of us (including you :-) is guilty of wrong thinking. Regards Heikki ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] speeding up testing of computer go programs
Don, I think we have a semantic problem. Some things don't work as expected but provide the genesis for further creativity. Other things work, but not with sufficient additional value for the disproportionate effort invested. Some things don't end up having any enduring value except as one of the many infinite possible paths eliminated. Maybe we are being too abstract here. If you have the time and motivation, would you please tell me in a couple of sentences what your standard(s) is upon which you can clearly distinguish right thinking from wrong thinking? And how that standard accommodates active random walk experimentation and creativity such that an experimenter can know PRIOR to doing the experiment if he is headed off in a right or wrong path? Jim Don Dailey wrote: Jim O'Flaherty, Jr. wrote: Heikki, I'm with you. There is no wrong thinking at the present time. Of course there is wrong thinking. Why do you think they call it the trial and error approach? - Don There are too many differing agendas, with building the strongest program immediately being only one, to claim any approach is futile, inefficient or erred. Once there are approaches that actually come near playing low dan levels against humans, I can see how narrowing approaches and thinking will become useful. Until then, lots of chaotic and random path experimentation is desirable, including other languages, specialized languages, techniques, etc. Jim Heikki Levanto wrote: On Sun, Nov 25, 2007 at 11:52:14AM -0500, Don Dailey wrote: I know that most go programmers don't concern themselves with small improvements because of the sense that there is bigger fish to fry. But this is wrong thinking. If you can get 10 small improvements it can be equivalent to one very large improvement. This is frong thinking *for you*. Wasn't it yourself who said that people program go for various reasons, only one of them being making the strongest possible program. A person with a more theoretical approach might lament that all that speed optimizing indeed improved the play considerably, but has not produced any new insight or theory on how best to approach the problem. A mere amateur like me could complain about the time invested in those small improvements, that I did not gain any new knowlege for myself, it was just routine programming. I humbly suggest that none of us (including you :-) is guilty of wrong thinking. Regards Heikki ___ 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] Re: The global search myth
Seo, All I described was the scientific method plus simple probability theory combined with using intuition to explore unknown unknowns creatively. For a layman's explanation into this world, see the works by Talib of Fooled by Randomness and The Black Swan. Not sure about your analogy either. If their theory is Extra Terrestrial Intelligence exists, has their been evidence provided to invalidate the theory? I had not heard of any. And our existence certainly supports the speculation within the theory, i.e. We exist. Therefor it is possible other intelligence exists. And I am suspicious any evidence invalidating the core theory (given it is a simple and encompassing as I have summarized above) could be found anyway. It would require searching the entire universe in a very short period of time as longer periods of time, like millions of years allow for possible emergence of evolutionary life forms after the area has been searched. As to your then applying the analogy to computer chess/go - don't see the connection. Jim Sanghyeon Seo wrote: 2007/11/23, Jim O'Flaherty, Jr. [EMAIL PROTECTED]: Don, I think it is tenuous to predict, much less emphatically assert, that just because the evidence is linear at the lower scale, it remains so at higher scales. While it is reasonable to assume, it is not certain. I see your point that at this time, your theory about it applying to larger scales has yet to be invalidated. However, this does not preclude your theory being invalidated in the future. Nor does it make their intuitions about ways others might be able to do so (and keep an open mind about creating attempts) as superstitious. It just means they are yet to be convinced of your position just as you are yet to be convinced of theirs. Remember, the direct evidence used to support a theory that the world was flat. That theory was later invalidated and replaced with a new theory incorporating the old evidence as well as the new evidence. This starts to sound like a SETI advocate. After forty years of sustained failures, the burden of proof is on SETI advocates, not critics. Same goes for computer chess and computer go. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: The global search myth
Don, I think it is tenuous to predict, much less emphatically assert, that just because the evidence is linear at the lower scale, it remains so at higher scales. While it is reasonable to assume, it is not certain. I see your point that at this time, your theory about it applying to larger scales has yet to be invalidated. However, this does not preclude your theory being invalidated in the future. Nor does it make their intuitions about ways others might be able to do so (and keep an open mind about creating attempts) as superstitious. It just means they are yet to be convinced of your position just as you are yet to be convinced of theirs. Remember, the direct evidence used to support a theory that the world was flat. That theory was later invalidated and replaced with a new theory incorporating the old evidence as well as the new evidence. And you want other attempting to disprove your theory. It both educates them on the current theory and challenges and possibly convinces them to share holding your theory. And it also educates you in the event they find some error in your approach/assumptions/context/definitions or are actually able to disprove your conclusion. And it is likely someone will eventually disprove your theory while keeping the evidence upon which your theory rests. I would encourage you to keep your theory (every cycle's sacred, every cycle's great, if cycle's wasted, God gets quite irate) and work making assumptions based upon this being true. That's efficient. I would also encourage others to challenge your theory and work at invalidating your assumptions around low level efficiencies. Both you, they and computer_go will be stronger because of it. Jim Don Dailey wrote: Hi Dave, You are doing it.No matter what evidence is presented, people will find a way to say it doesn't exist.As I mentioned earlier, the argument was that didn't apply to chess except for the first 4 or 5 ply - then when that didn't happen they expanded it to the first 6 or 7 and to this very day people are denying it - although they are looking more and more foolish in the process. We have already seen that this holds in GO, I did a massive study of it month ago on 9x9 boards and showed everyone this beautiful plot with straight lines showing the ELO per TIME curve which was essentially flat. I also remember the response. ok, it applies to a small boards but 19x19 is a completely different game that bears no resemblance. So I must give up on this. I know if I do the plot again someone will say, it only applies to depths we can currently test. Surely it will flatten out next year when the new processors come. I cannot answer to those arguments when no evidence is presented to back it up other than superstition of disbelief or my favorite, the testimony of experts in the field. I can only say that every bit of evidence we have backs up what I am saying. - Don Dave Dyer wrote: I agree with your exposition of search as it applies to chess, but I think there is a qualitative difference in Go. In chess, evaluators can see clear progress, in the form of material balance and statically determined positional factors, so each additional ply gives you more opportunity to see progress. Until Go evaluators give similarly strong and reliable signals, search will be a very much weaker tool. ___ 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] Language
Colin, I would NOT recommend this site. It was last updated in '98. Many of the optimizations listed were great for back then. They are terrible for 2007 and will likely result in SLOWER execution, not faster. For example, the claim is that a synchronized method call is 10 times slower than one which is not synchronized. While true in '98, this has changed considerably and is now patently false. The cost of acquiring/releasing a lock in most modern production available VMs is now measured in parts of a percent. It is rarely worth optimizing this out as the constraint(s)/bottleneck(s) are very likely elsewhere. Completely changing your architecture to attempt to avoid synchronization is now bad for your code (if you have any intentions to make it multi-thread capable). Another claim is marking a method final in an attempt to promote it to be inlined by the compiler. In '98, this could have a substantial impact on performance. Now, it not only does not desirably impact performance, the modern JVMs have sophisticated implementations around inlining including inlining based on probability with exceptions branched out of a default execution flow path (making the exceptions slower, but the default path the fastest), it makes the class(es) less flexibly to future adaptation. If you are writing high performance Java code, it is worth your while to find references that are no more than 4 years old. The JVMs have change so much in the last 10 years, any assumptions from a recent as 4 years ago are likely fallacious. If you want to follow performance trends and very fixated execution performance engineering for Java, I would recommend starting here: http://www.javaperformancetuning.com/ And for a book: http://www.amazon.com/exec/obidos/ASIN/0596003773/javaperforman-20 I have used both the site and the book for my own Java performance tuning. Excellent stuff. Jim Colin Kern wrote: On Nov 20, 2007 1:56 PM, Nick Apperson [EMAIL PROTECTED] wrote: On Nov 20, 2007 12:48 PM, Stefan Nobis [EMAIL PROTECTED] wrote: Colin Kern [EMAIL PROTECTED] writes: I think the reason for Ruby being so much slower is because it is an interpreted language rather than a compiled language. It's not the main problem (interpreted languages are slower than those compiled to native code, but than even Java and C# are interpreted and don't have such big slowdowns). Java and C# are both compiled at some point if the same loop is running repeatedly. Java is usually compiled just in time which is to say as each function is first run. I'm not sure how C# is executed, but I think it gets compiled before execution. I just found this looking around for things about Java's speed. Looks like some useful ways to boost Java's performance. http://www.cs.cmu.edu/~jch/java/speed.html -Colin ___ 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] Language
Nick, When I engage in complex multi-threaded distributed processing, I have found Java to give me the most value for my limited personal time buck. I am not claiming that Java is competitive in performance with hand crafted assembly (or C or C++). I am claiming that I have experienced a many fold increase in my productivity by exploiting the much easier to use the language, libraries, the distributed computing ability and JVMs of Java than attempting to reliably reproduce the same results in hand crafted assembly (or C, or C++, or equivalents in terms of raw machine performance). For me, the primary constraint I am attempting to optimize is my own personal productivity. I am willing to give up small percentages of computation performance in trade for being vastly more productive in generating experiments. And at this point, JVM efficiencies have become so effective, we are talking about small percentages of performance difference. They are close enough for me to easily choose away from the less portable, flexible and shareable implementations of libraries I have seen for pretty much any other implementation system (Java is more than a language, it is also libraries, JVM implementations, standards for inter-system communication, distributed computing, etc.). I still contend that breakthroughs in programming Go are going to come from creative experimental algorithms as opposed to a couple percent optimization around current algorithms. As such, I will remain wanting to favor implementation flexibility over computational efficiency. Once we have breakthroughs worth optimizing (and from what I am reading here, there aren't any yet), I will carefully reconsider my choice of Java. Recall there was a member of this forum who reported as his team went from Java to C/C++ to make things more efficient for his own implementation. He described the resulting loss of coding efficiency was not worth the minimal gain in execution performance. That member has since moved his team back to Java acknowledging there are efficiency benefits in C/C++, but that Java keeps them able to experiment with alternative approaches more rapidly. As to Java taking over the world - that is kind of too late. It's everywhere. Last calculation is that it is running on over 3 billion machines and devices (PCs, mainframes, mobile phones, smart cards, etc.). And now that it is GPLed, it will find many more homes. And I find it difficult to believe that the core reason there are so many machines and devices running Java to be the fact that Java has garbage collection. I will grant you that it is likely an influencer, but not near the magnitude you seem to believe it is. Java garbage collection is just one of many benefits collaborating with other language and library features which also influence the choice to implement in Java. I sense you think that a gain for Java is a loss for C/C++. I don't see it that way. The market continues to expand adding more and more software engineers/developers/programmers. So while C/C++ may not have the same growth rates it had in the '90s, there is still growth. Why does it matter to you that Java is growing? If you are happy with what you have chosen, why is what other people are recommending and choosing important to you? What are you defending? What are you trying to achieve? Jim - Original Message From: Nick Apperson [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, November 13, 2007 12:07:10 AM Subject: Re: [computer-go] Language WARNING: This digresses into a rant by the end... You've been warned. If you like to have your garbage collected for you then use one of the management strategies present in C++. If you like delayed freeing, overload new or use a library that does this. Really, the difference between C++ and most other programming languages (that are strongly typed) is that C++ doesn't make any assumptions about what you are going to do with it because of its most basic principle: you don't pay for what you don't use. If you want garbage collection, you can have it: it's not like C++ prevents this. By the same token, Java and C# don't allow you to make any decision here which might be best in certain circumstances, but it certianly isn't always ideal. If you want the subset of features that say java has, you are welcome to create these restrictions in C++ all while remaining more portable. I personally use garbage collection every once in a while in my C++ code. It is not usually the right tool for me, but there are circumstances where it makes sense. I generally use it when I have data that isn't really owned by any object. It is data that many parts of the program reference and some wish to keep a copy for themselves. This is how the std::string class is implemented in C++. Reference counting and copy on write. But I'll be damned if Java takes over the
Re: [computer-go] Intelligence
All, For reasons similar to those mentioned by others, I have found the phrase artificial intelligence to be less than adequate to convey my interests in this domain. And after considerable time, I came up with a term that I prefer; synthetic awareness. It comes from having interests in several different domains which feed into my interest in fabricating non-homo-sapien memetic propagation. First, synthetic is more inclusive. It means that borrowing and incorporating specialized awareness/knowledge from organic/memetic domains is included and acceptable. It also means that fabrication of new awareness/knowledge from strictly computation domains also works. Secondly, awareness is more expansive than knowledge. Boolean mathematic frames (proof focused rule based systems) and the symbolic efficiencies around linguistics (must be able to be articulated accurately) have most intellectuals fixated on producing idealized knowledge. And while there is significant value in the results produced, the results (to me) are too sequential and fragile to be expected to scale up to extremely high levels of complexity. This is why computer Checkers/Draughts is solved, computer Chess is not solved but beat the highest skilled humans, and computer Go is not even effectively beating low ranking amateurs. Awareness covers much more complex notions like the subtleties implied in intuition and creativity. Here is my reframing of a statement by a psychology author, Nathanial Branden: STATEMENT_REFRAME The need to create synthetic awareness has acquired a new urgency in the computational age. The more rapid then rate of change, the more fragile and dangerous it is to operate computers mechanically, relying on routines of Boolean software and Boolean behavior that may be irrelevant or obsolete. /STATEMENT_REFRAME As has been discussed ad infinitum here on computer_go, I don't see computer Go be solved meaning like Checkers/Draughts has been solved. I do think it is achievable to generate some sort of computational result which can eventually outplay the humans of the highest skill. I also think some significant breakthroughs are required around the move away from booleans (perfect move-vs-imperfect move) and towards scalars (probability of each available move will lead to overall increased value). While the domain of the rules of Go feel very rigid, the complexity is so vast that any idealized solution is going to turn out to be a local optima, i.e. with enough effort and exploration, it will be discovered the idealized solution, too, has weaknesses which can be exploited and eventually cause it's failure. As such, the more dynamic and creative the nature of the resulting entity, the more likely it will be the entity can eventually hop out of the local optima in search of an even higher optima. The more reserved, risk averse and rigid the entity, the more likely it will be unable to move forward and the sooner it will succumb to another entity's discovering it's weaknesses and eventually out-playing it. Go is the perfect game for demonstrating that even with a perfectly rigid foundation, the solution space is vastly more effectively searched via dynamic evolving mechanisms than via static rigid mechanisms. And as can be seen with the recent UCT/MC results, we are still just barely above randomness in terms of discovering and inventing solutions. Jim Erik van der Werf wrote: On 7/21/07, Weimin Xiao [EMAIL PROTECTED] wrote: Intelligence is the ability to adapt or learn. A hypothetical almighty oracle that already knows the correct answer to every question and the right response in every situation would never have to adapt. Hence evidence of intelligence according to your definition would not be observed. IMO the adaptation is just a means to an end. The end (Intelligence, whatever it is) does not necessarily require adaptation. Erik ___ 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] Intelligence
Erik, In perfect theory, I agree with you. In the practicality of attempting to generate more effective computer Go players, I disagree. In theory, there is a perfect girlfriend for me. In practicality, there is my adapting to make the current girlfriend good enough and better, with perfection never really obtainable. Jim Erik van der Werf wrote: On 7/21/07, Weimin Xiao [EMAIL PROTECTED] wrote: Intelligence is the ability to adapt or learn. A hypothetical almighty oracle that already knows the correct answer to every question and the right response in every situation would never have to adapt. Hence evidence of intelligence according to your definition would not be observed. IMO the adaptation is just a means to an end. The end (Intelligence, whatever it is) does not necessarily require adaptation. Erik ___ 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] Intelligence
How do you know this is incorrect? Are you claiming omniscience? [EMAIL PROTECTED] wrote: No. Erik is wrong even in theory. An arguement can fault in two aspects:assumption and logic. His arguement faults on the former, even his logic is iron clad. He assumed the existence of an Oracle, which we all know is incorrect. -Original Message- From: Jim O'Flaherty, Jr. [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Sun, 22 Jul 2007 10:40 am Subject: Re: [computer-go] Intelligence Erik, In perfect theory, I agree with you. In the practicality of attempting to generate more effective computer Go players, I disagree. In theory, there is a perfect girlfriend for me. In practicality, there is my adapting to make the current girlfriend good enough and better, with perfection never really obtainable. Jim Erik van der Werf wrote: On 7/21/07, Weimin Xiao [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Intelligence is the ability to adapt or learn. A hypothetical almighty oracle that already knows the correct answer to every question and the right response in every situation would never have to adapt. Hence evidence of intelligence according to your definition would not be observed. IMO the adaptation is just a means to an end. The end (Intelligence, whatever it is) does not necessarily require adaptation. Erik ___ computer-go mailing list computer-go@computer-go.org mailto:computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org mailto:computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ AOL now offers free email to everyone. Find out more about what's free from AOL at *AOL.com* http://www.aol.com?ncid=AOLAOF0002000437. ___ 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] 9x9 games wanted and the next big challenge
Chrilly, The purpose of investment is to generate a return exceeding the original investment, i.e. a profit. Given the state of Go, I am finding it difficult to imagine why an investor would choose to put any good money into Go. There is absolutely no reliable expectation that Go will achieve even close to strong amateur status (1D) in the next couple of years. It's possible some wealthy person might decide to generously donate money into the computer Go domain so as to forward his own passion, just as many of the people here generously donate their own very valuable personal time. Go is not a reasonable place to put investments. At present and from everything I can see, computer Go development depends upon personal passion and generosity. And sans a huge breakthrough, I am currently unable to see this changing anytime soon. That said, I think once Go AI becomes sufficiently and robustly skilled to reliably start giving strong amateurs (1D) genuinely competitive games, you will start to see investment rise. And given a sufficiently high enough rate of change (objectively measured as increases in playing skill), you will start to see the investments accelerate as competition will spur on more innovation resulting in more successes resulting in more investment resulting in further innovation...and a positive feedback loop will be boot strapped. As the probability of producing profits rise, the risk around insufficient returns on an investment fall. Eventually a threshold is crossed and the system becomes self-generative. Succinctly put - there is no money in computer Go (at least compared to computer Chess) because there is currently no hope (mathematically speaking) of the existing crop of computer Go programs to scale up to anything less than moderate amateur levels. Once this changes from no hope to a remote possibility, the investment around Go will likely follow. No to be too Zen here, but...the sooner you accept things as they are and stop resisting what is, the sooner you become free to move forward. Go investment is working exactly as it ought, in relation to the whole. Finally, thank you for your contribution to computer Go. I get that it is an act of generosity (realistically, what else could it possibly be). And I personally appreciate it. Jim chrilly wrote: Sil wrote: How about http://home.wwgo.jp/jp/minigo/ It seems that only 24 games are available. Is the whole collection available somewhere? Rémi I have read dozens of times that computer-Go is the next big challenge. But in fact it is a completly amateuristic field where even the most basic things are missing. As a chess programmer I did not even think about, that it is a problem to get a good game collection. There are no proper interfaces, no serious tournaments, a wired data standard... AND there is no money involved: For professional programming I get 60Euro/h (1Euro=1.35$). 2.000h x 60 = 120.000 Euro. This equation is of course completly wrong. One can not make in 2000h a very strong Go programm and one can not earn 120.000 Euro with it. A more realistic equation is; 20.000 Euro/5000h = 4Euro/h. The minimum wage (by law) is in Austria 6Euro/h. Obviously Go programming is even more unqualified than washing dishes in a restaurant. If it would be really a big challenge, there would be some money. In chess nowadays there is also no money. But once it was a good business and there was some considerable money for Deep Blue and on a smaller scale also for Hydra, there was Don's project at MIT, one got a big Cray for Cray-Blitz, Ken Thompson build a chess engine Its like some hobbyst engineers and hobby-pilots would try to fly to the moon. Its probably only good for to write some academic papers. In this case its even an advantage that everything is so amateuristic. The general level is low and one can be the one-eyed king under blind ones. Its clear to me that things are as they are in the West. Go is played only by a small freak community. But if it is so important in China/Korea/Japan why is'nt there something like Fritz and ChessBase? Or does it exist and we are living in a completly other Go-world? Chrilly P.S.: I do not want to offend anyone in this list. Everybody here does his best. I am just feed up with the things as they are. ___ 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] 9x9 games wanted and the next big challenge
David, Very well said. Thank you. Jim David Doshay wrote: Chrilly, It is hard to disagree with what Jim writes, but I will in a small way. When I recently flew to Asia, the screen on the seatback in front of me offered Go as one of its games. At its highest level it played far worse than the average program on CGOS or in a KGS computer tournament, and yet somebody was paid by that airline for the use of that program. And Go++ makes a living for its programmer. There is money to be made in computer Go, but as Jim states, right now the risk/reward ratio does not encourage most normal investors, so it is for either 1) those with a high risk threshold, 2) those who think more about research than production, 3) those motivated by how hard it is and not put off by how much effort it is going to take, or 4) programmers of other games who underestimate how hard it really is. Please do not take offense by number 4. I have huge respect for your programming ability and am glad that you have joined us. Cheers, David On 8, Jul 2007, at 8:36 AM, Jim O'Flaherty, Jr. wrote: Chrilly, The purpose of investment is to generate a return exceeding the original investment, i.e. a profit. Given the state of Go, I am finding it difficult to imagine why an investor would choose to put any good money into Go. There is absolutely no reliable expectation that Go will achieve even close to strong amateur status (1D) in the next couple of years. It's possible some wealthy person might decide to generously donate money into the computer Go domain so as to forward his own passion, just as many of the people here generously donate their own very valuable personal time. Go is not a reasonable place to put investments. At present and from everything I can see, computer Go development depends upon personal passion and generosity. And sans a huge breakthrough, I am currently unable to see this changing anytime soon. That said, I think once Go AI becomes sufficiently and robustly skilled to reliably start giving strong amateurs (1D) genuinely competitive games, you will start to see investment rise. And given a sufficiently high enough rate of change (objectively measured as increases in playing skill), you will start to see the investments accelerate as competition will spur on more innovation resulting in more successes resulting in more investment resulting in further innovation...and a positive feedback loop will be boot strapped. As the probability of producing profits rise, the risk around insufficient returns on an investment fall. Eventually a threshold is crossed and the system becomes self-generative. Succinctly put - there is no money in computer Go (at least compared to computer Chess) because there is currently no hope (mathematically speaking) of the existing crop of computer Go programs to scale up to anything less than moderate amateur levels. Once this changes from no hope to a remote possibility, the investment around Go will likely follow. No to be too Zen here, but...the sooner you accept things as they are and stop resisting what is, the sooner you become free to move forward. Go investment is working exactly as it ought, in relation to the whole. Finally, thank you for your contribution to computer Go. I get that it is an act of generosity (realistically, what else could it possibly be). And I personally appreciate it. Jim ___ 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] Re: pseudoliberties
What's a pseudo-liberty? And how can there be more of them than there are empty intersections (81) on the board? - Original Message From: Jason House [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, March 29, 2007 1:02:01 PM Subject: Re: [computer-go] Re: pseudoliberties After some trial and error, I got 90 * * * * * * * * * * * * *** * * * *** * * * * * * * * * * * * On 3/29/07, John Tromp [EMAIL PROTECTED] wrote: On 3/29/07, John Tromp [EMAIL PROTECTED] wrote: Is 88 the maximum number of pseuoliberties a string can have on 9x9? Make that 89:-) -John ___ 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] Grid Cosmos
Don, Your question is fertile ground for a language/platform argument fest (flame-war?). :) From the 10,000 foot view, I see very little difference/advantage between the Java language/platform and the C#/.Net language/platform. As they say, though, The difference is in the details. My being a Java advocate comes mostly from my 10 year investment in Java. It also comes from my legacy of very strong resistance to Microsoft. I resist MS less now-a-days. I don't see them as the dominant over-bearing threat they used to be. Ultimately, I continue to bet on Java as I see it still mutating and adapting into more parallel hardware optimization context possibilities than Mono or .Net. A good part of that is because the nature of Java has been and is very closely aligned with the nature of Sun. And because Java became so ridiculously popular. There are just so many more minds who can specialize in producing the libraries of math optimizations upon which I know I will depend later. The GPLing of Java will result in some of IBM's scientists releasing some kick ass math libraries with super optimization. I am so looking forward to that. About the only thing that has caught my interest outside of Java has been your investigation and reporting about D. I really like what I am hearing there. And even then, I am reluctant to invest there as opposed to working a higher design levels. My sense is that my moving to D would too strongly influence me to do pre-mature performance optimizations and tweaks. Remaining in Java requires I be creative and innovative in different and more multi-threaded/distributed computing oriented ways. As to my own Go player contribution - I wrote one about three years back, played around with it and decided I wanted to spend more time playing around with conceptual creativity as opposed to being lost in the myriad of technical details (distractions). [basically, it sucked wind, cost me close to 1,000 hours of personal time and resulted in me refocusing on simpler problem domains to prove out my more simple ideas] I will eventually spend the time to take my different lines of thinking and go through the arduous process of getting code massaged until it works. For now, though, I enjoy reading the posts on this list, playing with my own ideas in abstract and with little one-off code experiments. I have been sorely tempted dozens of times to try and write a very simple example MC implementation and get it validated here in the group. I am not certain I am capturing all the nuances around the difference between the MC and UCT discussions. And I would like to personally thank you for all your contributions to this group. I very much look forward to your posts. And to your progress. I really like how you have approached taking on projects, methodically breaking down problems and rigorously experimenting. And then how articulate, concise and yet detailed you are when you post. I'm jealous of the amount of time you are able to invest in the area. And I thoroughly enjoy living vicarously through you by reading your posts and progress. Please keep it up. Jim - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, March 15, 2007 9:18:14 AM Subject: Re: [computer-go] Grid Cosmos What does C# bring that Java doesn't? My understanding is that C# is Microsofts way to try to supplant Java as a standard, not a clone but extremely similar. What advantages over Java? It is a higher level language? - Don On Thu, 2007-03-15 at 07:04 -0700, Jim O'Flaherty, Jr. wrote: Eduardo, I am a strong Java advocate, no doubt. However, Mono/C# have accomplished quite a bit in the last 3 years. My own experience in that area tells me it is much more mature than you have made it sound. To get pretty up-to-date information, try here: http://en.wikipedia.org/wiki/Mono_%28software%29 Jim - Original Message From: Eduardo Sabbatella [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, March 15, 2007 5:11:41 AM Subject: Re: [computer-go] Grid Cosmos As far I know, Mono implements the virtual machine and a couple of core libraries. Anyway, A lot of them are missing. I don't know for sure, but It looks impossible to use real applications inside mono/linux. By the way, As far I know, there was a scam with Icaza/Novell receiving money from Microsoft, plus java sdk released as open source (GPL) a couple of weeks ago. All directions shows that mono on linux is stuck. Specially, after Java SDK published as libre/free software. --- Brian Slesinsky [EMAIL PROTECTED] escribió: On 3/14/07, Darren Cook [EMAIL PROTECTED] wrote: P.S. Is anyone using C# on linux? I thought C# was standardized so I expected to find something, but google is only giving me articles from 2001... I haven't used
Re: [computer-go] Bit Twiddling Hacks
Erik, I am. Jim - Original Message From: Erik van der Werf [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, February 13, 2007 3:37:13 PM Subject: Re: [computer-go] Bit Twiddling Hacks On 2/12/07, Phil G [EMAIL PROTECTED] wrote: For those doing a lot of bit logic in their computer go programs, you might be interested in this collection of highly optimized methods for doing things with bits (like counting bits sets in parallel and computing the minmum or maximin of two integers without branching): http://graphics.stanford.edu/~seander/bithacks.html Seen it before, but still a very nice site with lots of clever tricks. I have some improved bit counters, if anyone is interested... Erik ___ 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] an idea... computer go program's rank vs time
Terry, Where's the notion that through small increments, there is no reasonable path from a house 3 bedroom house to a 10 story building? Isn't the consistency of the assumption set around how a house is designed and built fundamentally (as in pardigm-ally) different than that of how designing and building a 10 story building? And doesn't the assumption set for the 10 story building have to be mostly abandoned when creating the design and building a 100 story building? Isn't there's a point where the shift from one complex infrastructure to another results in a setback as nuanced assumptions must be abandoned when their lower dependent assumptions have to be reorganized or even replaced? Jim - Original Message From: terry mcintyre [EMAIL PROTECTED] To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org Sent: Thursday, January 25, 2007 10:23:13 AM Subject: Re: [computer-go] an idea... computer go program's rank vs time Go, being a matter of efficiency over one's opponent, may be even more susceptible to improvement via many small improvements over many moves than is chess. As long as you don't leave weak shapes behind, picking up a point here, a point there at a slightly faster rate than your opponent will give you the game. Get your own web address. Have a HUGE year through Yahoo! Small Business.___ 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] Can a computer beat a human?
You can if you use some sort of compression scheme...involving multiple values per quanta. I bet there's more than enough room...in the universe...probably just in your eyelash. - Original Message From: alain Baeckeroot [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 24, 2007 2:11:23 PM Subject: Re: [computer-go] Can a computer beat a human? Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a écrit : Since no one has mentioned bounding memory, a complete lookup table (a complete table of correct moves, perfect-hashed by board state) should do the trick. With 10^170 legal position for 19x19 what would be the size of this table ? I m afraid we cannot build it with all the matter in visible universe. Cheers. Alain ___ 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] Mega transposition table
Don, You wrote: Does it matter?... While I am not totally up-to-date on C++ compiler optimizers, it seems like locality of reference compiler optimizations might be influenced if you were to specify allocation on the stack as opposed to the heap. And aren't stack based values much more likely to end up in registers and in CPU cache than heap based references and values? Perhaps all of these kinds of evaluations are rendered ineffective with more modern day CPUs and C++/C compilers. From what I have been following in the Java JVMs, these prove to be VERY important in the way they choose to optimize execution paths and data flows. Just figured that it would matter in C++/C in a similar way. Jim Don Dailey wrote: On Fri, 2007-01-19 at 17:19 -0600, Jim O'Flaherty, Jr. wrote: Don, So could you elaborate on where you are allocating space for big_array in your code snippet below? Does it matter? I just declare it as a global but I will probably eventually just place it on the heap via malloc - with a command line argument to set the size. - Don ___ 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] Making Java much faster
Wodzu, There are roughly two types of approaches to bettering the skill of computer go solutions; incremental and breakthrough. I think for incremental solutions, ones where lots of work results in small shifts in better go playing performance, you are correct. Any optimizations around execution speed will result in better go playing performance per time-unit. This is important if the measurement is winning current computer_go competitions. However, what I hear quite a few people saying is they are looking for breakthrough types of go skill improvement, and more at the application level as opposed to the individual lines of code. And to do that, their needs around adaptability are more influential on their primary constraint (personal time, not eventual execution speed). Their focus is on being able to complete more experiments per personal time unit with the hope of stumbling into a new domain where the go playing performance takes an order of magnitude leap ahead. Once in the new domain, the priorities for the person may shift back to incremental as they begin to see what kinds of limits the new technique might provide. This is where I am at personally. I am far more interested in probability based techniques as opposed to perfecting tactics/fighting strategies. I am very happy others are more interested in those areas. It's a good match. There are short-term benefits to the incremental approach. However, it likely has a much closer threshold of diminishing returns if one follows the standard constraint reduction techniques, largest first, etc.. At which point, all the optimizations start fighting with any attempts to change and/or expand newer ideas, techniques and experiments in an effort to continue making progress. Once one has prioritized code execution speed optimizations as a root value in moving a system forward, almost always there is a large loss in adaptability with the eventual result being the person abandons the bulk of the previous code base to essentially start from scratch. In many, if not most, cases, the error persists in the new approach as the fixation on maximizing execution speed remains too high resulting in a rapid pruning of possible exploration options. There is no short answer to the Go problem. It is going to takes lots of investment by both the code speed optimizers (incremental) and the new technique inventor/innovators (breakthrough) and an effective integration of both before we see result substantially superior to what we experiencing right now. Personally, I have been enjoying the discussions around the progress being made on the UTC/Monte Carlo techniques. I am eager to start playing in that domain. Jim Wodzu wrote: Huh, why not use Pascal? It has speed of C and simplicity of Java :) heck, you could use perl. plenty of packages available (it can even be made multithreaded!), shared memory packages, etc. i mean, if speed isn't your top concern... i think speed is one of most important things beacuse it affects strength of the program ;) (if the time for move is restricted) anyway, chosing a proper (fastest) algorithm has crucial meaning and other things like language, used data structures and so on, have less meaning in improving speed. thats my opinion, regards. ___ 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] Making Java much faster
Mark, It's true. My interpretation of Sun's documents: In the more recent versions of Java (1.4, 1.5, etc.), the runtime analysis in the -server option of Sun's Hotspot JVM is able to do several different types of optimization around potentially final and mostly final methods. The most recent versions have mostly eliminated the need to suggest optimization paths to the compiler via the final or static keywords. Additionally, there are cases where the way the polymorphic calls are actually dropped from an indirection (costly) to a Boolean test (cheapest operation on almost all processor types). It occurs when Hotspot notices the call favors one path over others, remaps the call from being an always deference/indirection to a direct call with a single Boolean test to shuttle off all non-critical-path calls to the slower dereference/indirection mechanism, and the primary call path executes with virtually no cost (a Boolean check is vastly less expensive than all the overhead of a polymorphic context transition). Add to this the fact that the register management of the Java call stack mechanism has been managed so that stack based (as opposed to heap based) optimizations can be utilized with higher effectiveness reduces even more time issues with heap memory fetches. Again, this is done during execution so that non-obvious (at least at compile time) stack use optimization can cross methods. In compiled only languages, this requires the programmer design it in explicitly. With Java, it just happens dynamically. (see caveat in PS) There is a cost for these optimizations. Some of the CPU is being burned in monitoring interpreted code to notice the patterns to optimize. And once an optimization is in place, if the class loader happens to load an additional class which impacts the optimized code path, the optimizations are backed out until the context can be monitored sufficiently for the critical code path to be re-optimized. It’s quite dynamic, and once produced, very effective speed-wise. This does not mean that any programmer can make Java work well. It still takes focusing on design level values, ones that are potentially much more effectively learned in languages like C++/C or assembly. Understanding the fundamentals is almost always an advantage as it enables one to design even more optimally in languages like Java. What I am enjoying is how much I can stay with my OO design principles, engage in only a moderate efficiency focus on less than 10% of my code base and end up with a screaming fast result. I won't say that it is guaranteed to outperform hand optimized C++/C. I am willing to say that the time it takes me to get the +95% as fast result is an order of magnitude smaller in Java than it was in my C++/C/assembly days. I am able to play with many more experiments in the saved time. It is a slight loss short term (not stuck in efficiency fixation local optima) for a huge long term gain (more effectively moving towards global optima, or at least significantly superior local optima-s). My experience tells me, at least with Java and Sun's approach to performance enhancement, staying with generally accepted OO design principles yields nice results immediately, and even better results as Sun continues to expand the number of optimizations that are only possible with on the spot run-time analysis. A compiler can only make educated (theory) guesses at the future execution profile of a code base. Some even use an execution profile log to assist in their engaging in further optimizations at compile time. Sun's approach augments really good guessing (theory) with up-to-date and in context direct observation (practice). This mixed method approach has proven to be significantly more performant and adaptive than the more traditional techniques of just compilation optimization. And given how competitive MS is (regardless of whether you like/dislike and/or agree/disagree with them), I expect .Net/C# to make similar leaps. And I expect that both Sun/Java and MS/.Net/C# will create an arms race that benefits all their users. Jim PS. It is somewhat difficult to talk about memory management between Java and C++/C because their memory models are different. - Original Message From: Mark Boon [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, November 29, 2006 9:22:14 AM Subject: Re: [computer-go] Making Java much faster On 29-nov-06, at 08:43, Stuart A. Yeates wrote: Other tricks for faster java include ensuring that, wherever possible, you use the final, static and private keywords. This enables the compiler to apply more compilation tricks in more places. More and more I find that using 'final' or 'static' to have no effect on speed at all. Most of the time the compiler figures out it can treat a method as final or static. I don't think I have found a case were explicitly putting it helped
Re: [computer-go] .. if Monte-Carlo programs would play infinitestrong
Don (and others), Depending upon your definition of God, I think most of the God conversation is kind of silly. Given He is omnipotent, he has the ability to alter one of His created entities such that it is not possible to beat Him PRIOR to casting His reply as white. The alteration could be as subtle as changing the active potential on some sub-set of neurons in his opponents brain or as acute as creating deep anxiety within his opponent's psyche by being so gargantuan in physical presence. And talk about self-esteem. Hard to top God's opinion of Himself give you are one of His creations. Give He is omniscient, he has no need for generating confusion for His opponent. He already knows his opponents weakness, how it will manifest and why it will do so. That's assuming an omniscient being has any interest in casting a stone in the first place, something very difficult to imagine in any sense of the meaning of the words. Given he is omnipresent, he is has/is/will be in a part of the universe where an animation of the game about to be played is already playing out to completion, so he can see how it ends before it begins (a slight lean on his omniscience here). Better, the game he is watching is on a board made of harp strings and with the stones represented by fairies and unicorns. Hey! When your God, you get to make up all sorts of crazy shite. Finally, what is an objectively best move? How would one measure it? It's as if there was some God knowable state transition diagram (STD) describing an starting go board where the entry points to the STD (OMG, the sexual references here abound) mostly show black to win. So of that set of initial black moves that perfectly state transition into wins for black, which is objectively superior to the other? The question itself is poorly framed? The moves are all peers. None is superior to the other win in n moves candidates, even if their n's vary. The n's only matter if there is some higher value placed on minimizing the number of moves from start to finish. Give He is timeless, the length of game, hence the value of n, is not meaningful. Now, if God had a younger brother who liked to play Go...none of what I said above means anythingwhich is still true even if He doesn't. (a nod to your logic dialog from the other day, Don) Jim - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Monday, November 27, 2006 11:59:30 AM Subject: Re: [computer-go] .. if Monte-Carlo programs would play infinitestrong A good point to consider - is God actively trying to confuse his opponent and complicate things, or is he simply playing objectively best moves? - Don On Mon, 2006-11-27 at 07:39 -0800, steve uurtamo wrote: wow. i thought that there were at least two stones worth of slack in the opening, and another two in ko fighting. :) Seems unlikely. I can't imagine two competent players, say 1p or better, coming out of the opening with one of them having a two-stone lead. one of them is not a competent 1p. one of them is a computer with knowledge of the end result of all possible game trees (my understanding of the definition of a god player). it could, for instance, create an opening whose branches are so complicated that W (or B) was forced to take small gains territorially, but lose, say, 20 pts. by the midgame. And, the right to win all ko fights without having to fight them is only worth half a stone. uh, that depends upon what the kos are for. s. Sponsored Link $420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre ___ 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/
