Author: vladan
Date: 02:27:11 03/31/04
Go up one level in this thread
On March 29, 2004 at 20:02:50, Keith Evans wrote: >On March 29, 2004 at 03:34:23, Steven Edwards wrote: > >>On March 28, 2004 at 17:44:26, Keith Evans wrote: >>>On March 28, 2004 at 15:55:36, Steven Edwards wrote: >>>>On March 27, 2004 at 22:49:01, Keith Evans wrote: >>>>>On March 25, 2004 at 22:15:16, Steven Edwards wrote: >>>>> >>>>>>Also, I've got a backup development plan that also uses Lisp and a low NPS, >>>>>>whole tree approach. This alternative doesn't rely much on patterns and >>>>>>planning, but on a market simulation (!) idea. Here, each node has an instance >>>>>>of an interpreter running a program in a Lisp-ish language called NodeScript and >>>>>>these instances compete for resource allocation (i.e., greater proportion of >>>>>>interpreter step cycles). All the NodeScript interpreter instances run at the >>>>>>same time, communicate via messaging plus blackboards, and together perform a >>>>>>planless search where the final move selection is reached by consensus. >>>>>> >>>>>>My NodeScript idea is certainly not like any other chess program known to me, >>>>>>and it's also rather unlike the reasoning process of a human player. But it >>>>>>does have some similarities to human group behavior, perhaps like a team of >>>>>>investment analysts, where economic projections and results guide resource >>>>>>allocation and target areas of market expansion. >>>> >>>>>How many nodes do you think would be running simultaneously? >>>> >>>>Thousands at least; the only limitation is the addressing space. All nodes run >>>>the same uniquely stored NodeScript program; each node only needs to store its >>>>own copy of the interpreter state and this is likely under 8 KByte or so. >>>> >>>>>I don't really >>>>>"get" this idea, but it's sort of interesting to me because I could see where >>>>>you could implement many of these node processors on an FPGA board, and they >>>>>could really run in parallel. (I mention an FPGA board only because it would >>>>>make development easier, there would obviously be many ways to approach this >>>>>problem.) >>>> >>>>While a multiple programmable gate array technique may be possible, it may not >>>>be the best approach for the above due to the ensuing high shared memory >>>>bandwidth requirements. >>> >>>Does every node need to communicate with every other node, or just a very >>>limited subset? >>> >>>Any hint about what type of messages the nodes would be sending? Just a simple >>>example of the type of transaction? >> >>It would be difficult to give precise answers here as too much of NodeScript is >>still only a techical outline. I'll post more details when/if they become >>available. > >Have you seen the papers on turbo codes? CHESS PROGRAMS BASED ON LISP OR OTHER VI LANGUAGES WILL NEVER BE BETTER THAN ONES WRITTEN ON C OR ASSEMBLY. Interpreted languages are too slow. Also, it is very hard job to implement high level of chess knowladge to support intensive pruning for selective searchers on that level. Many similar approaches failed, I do not see any reason to work in that direction. IN COMPUTER CHESS, MACHINE MUST USE ITS BASIC ADVENTIGES, SPEED OF CALCULATION, TO ACHIEVE MAXIMAL SEARCHING DEPTH. WHEN SEARCH DEPTH IS HIGH, WITH GOOD AND NOT TOO COMPLEX EVALUATION FUNCTION AND EXTENDER MACHINES WILL PLAY STRONGEST CHESS. Regards, Vladan V. , AXON programmer (www.playwitharena.com)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.