I would not post but there is some contraformation being stated.

Quote:Original post by alvaro

Quote:Original post by dj3hut1
Prolog is good for solving search problems like the AI for chess.

No, it's not. I spent about seven years developing a chess program on weekends, I've read most of the relevant literature since the 80s to around 2000 and I can tell you that Prolog didn't even play a minor roll in getting computers to play chess well. Search in chess is done using alpha-beta with refinements (quiescence search, move-ordering heuristics, transposition tables, null-move pruning...), preferably in whatever language is fastest (usually C with many clever tricks so things are fast).

Nonsense. Look at his statement. Prolog *is* good for solving search problems. And in the general, most any modern language can handle 'chess algorithims' just fine. In the 80s, C over Prolog made sense because computers were slow, simple and in order. Momentum and tradition may be why it still continues. As stated earlier in thread speed is not the main issue and even Python was advised. But I prefer the Prolog suggestion myself but would suggest Clojure (lisp derivative) or Oz as better.

Quote:

Quote:The advantage is, that you don't have to code the algorithm, you must only declare the problem in the right way.

I know that's how they always try to sell you declarative languages. In practice, you want to know exactly what your computer is doing at all times, and the abstraction offered by languages like Prolog doesn't buy you that much. This point of view may not be true for every type of programming problem, but it's most definitely true for chess.

In practice you cannot know exactly what your computer is doing at all times these days. Less and less with multicore. And the abstractions offered by declarative languages buy you a massive amount. I say this as someone who uses them for work. And cringe when I have to do something in C# that I know would be implemented much more clearly and robustly in a more declarative language. These languages excel at recursion and manipulating complex data structures (especially recursive ones like trees). I never done any chess programming but those algorithims you state would be more easily implemented correctly in a declarative languages.

http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

"Now for the fifth argument. It has to do with the influence of the tool we are trying to use upon our own thinking habits. I observe a cultural tradition, which in all probability has its roots in the Renaissance, to ignore this influence, to regard the human mind as the supreme and autonomous master of its artefacts. But if I start to analyse the thinking habits of myself and of my fellow human beings, I come, whether I like it or not, to a completely different conclusion, viz. that the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all!"

Trikri, have you tried genetic programming? It seems to be just what you are looking for. You generate a number of different code "candidates", and test each to see its performance. Then you take the best candidate, and regenerate several parts of its code again to create a new generation of candidates. You test these in turn, and carry on until hopefully you have evolved a kick-ass evaluation function!

Quote:Original post by DaeraxIn practice you cannot know exactly what your computer is doing at all times these days. Less and less with multicore.

I don't follow. I thought multicore had no impact at all on what a program was doing. I was under the impression that, unless you specifically designed your program to use multiple processors, the OS would treat your app just like it always has.

Quote:Original post by willh

Quote:Original post by DaeraxIn practice you cannot know exactly what your computer is doing at all times these days. Less and less with multicore.

I don't follow. I thought multicore had no impact at all on what a program was doing. I was under the impression that, unless you specifically designed your program to use multiple processors, the OS would treat your app just like it always has.

Exactly. If you are not writing for multicore these days then you are not writing for the present. Certainly not for the future.

Quote:Original post by willh

Quote:Original post by DaeraxIn practice you cannot know exactly what your computer is doing at all times these days. Less and less with multicore.

I don't follow. I thought multicore had no impact at all on what a program was doing. I was under the impression that, unless you specifically designed your program to use multiple processors, the OS would treat your app just like it always has.

The OS certainly isn't intelligent enough to automatically parallelize single-threaded code, so, yes, a single-threaded application will more-or-less run on a single core (or in the worst case, switch cores all the time, but it will never run on two or more cores simultaneously).

I believe Daerax meant that if one wants to actually utilize multiple cores, he or she needs to step into a very chaotic and nondeterministic world, and that harnessing the power of multiple cores correctly is extremely hard when using "regular languages" such as C++, java or C#, while when programming in a higher level language such as Prolog, Haskell, Oz or Erlang, a lot of complexity can be handled by the language/compiler, and writing a correctly behaving multi-threaded program can then become quite easy. For example, as far as I know, most Prolog programs (those who do not use the somewhat ugly assert/retract constructs) can be run on multiple cores with no change to the source code whatsoever.

(Directed towards "use any language you wish" posts) Languages are indeed "just tools", meaning there is no sense in claiming one language is absolutely superior to another. However, using the right language for the right problem can make a huge difference. Screwdrivers are not inherently better than forks, but they sure make it easier to put those screws in. There's more than one programming language for a reason.

Quote:Original post by TriKri
By the way, I read a book before sometime which contained a chapter about a computer or a computer program (don't know which) called Eurisko (you can see http://en.wikipedia.org/wiki/Eurisko). Ever heard of it? I think that used Lisp too, or at least something similar. That computer achieved some amazing things! Does anyone know how it worked? It would be really awesome if my program could do about the same thing!

I have spent some time documenting myself about Eurisko. Unfortunately, the details available in the literature are sparse. It was a rule-based system that had rules to generate new rules. It was some sort of an expert-system designed to create expert-systems. Very interesting stuff. Now its designer founded CycCorp. I am not sure about how well it is doing but he got a truckload of money to develop datamining software for antiterrorist purposes. Unfortunately it makes most of his work unpublished. There is an open version of Cyc named OpenCyc but I never really understood how one was supposed to use that.

If these interest you, I suggest you read about rule base system, planners, theorem solvers, and all that falls into the GOFAI (Good Old Fashion AI) field.

I would think the language with the richest ai history is prolog. But again just like everyone is saying, the best language is always a situationally dependent question.