Author: Don Dailey
Date: 11:54:13 07/13/98
Go up one level in this thread
On July 12, 1998 at 17:13:52, Robert Hyatt wrote: >On July 12, 1998 at 15:28:18, Don Dailey wrote: > >>On July 12, 1998 at 13:06:09, Robert Hyatt wrote: >> >>>On July 12, 1998 at 10:56:24, Don Dailey wrote: >>> >>>>On July 11, 1998 at 19:20:03, Roberto Waldteufel wrote: >>>> >>>>> >>>>>On July 11, 1998 at 13:39:34, Don Dailey wrote: >>>>> >>>>>>On July 09, 1998 at 17:14:02, Roberto Waldteufel wrote: >>>>>> >>>>>>> >>>>>>>On July 09, 1998 at 16:25:08, Bruce Moreland wrote: >>>>>>> >>>>>>>> >>>>>>>>On July 09, 1998 at 12:38:17, Robert Hyatt wrote: >>>>>>>> >>>>>>>>>On July 09, 1998 at 10:31:08, Dave Gomboc wrote: >>>>>>>>> >>>>>>>>>>On July 08, 1998 at 20:33:41, Bruce Moreland wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>On July 08, 1998 at 17:27:41, Tom Kerrigan wrote: >>>>>>>>>>> >>>>>>>>>>>>My problem was that I invariably forgot about the dead-bit scheme and did all >>>>>>>>>>>>sorts of calculations assuming that captured pieces existed. >>>>>>>>>>> >>>>>>>>>>>The only place they exist is in the piece list, and unless you are somehow >>>>>>>>>>>randomly accessing your piece list, the only way you'll access this is via a >>>>>>>>>>>loop, so write the loop once and copy-paste :-) >>>>>>>> >>>>>>>>>>Why copy-paste? What's wrong with a routine and an "inline this" compile >>>>>>>>>>directive? >>>>>>>> >>>>>>>>It'd be hard to inline just the "for" and an "if". Sure, you could write an >>>>>>>>iterator function that took another function as a parameter, inline everything, >>>>>>>>and hope for the best, but I bet you wouldn't get the best every time. >>>>>>>> >>>>>>>>>two things. (1) the "inline" attribute in a program only applies to >>>>>>>>>C++; (2) you can only "suggest" that a C compiler inline a function. Just >>>>>>>>>like you can "suggest" that a variable be kept in a register by using >>>>>>>>>"register int sq;". But you can't force it to happen, and you might eat >>>>>>>>>a lot of function call overhead as a result... >>>>>>>> >>>>>>>>It is a suggestion in C++ as well. >>>>>>>> >>>>>>>>bruce >>>>>>> >>>>>>>OK, I'm going to stick my neck out and admit that I program in Basic - don't >>>>>>>laugh too loudly. One thing that is available in that language is the $include >>>>>>>directive, which includes the contents of a specified text file exactly as if it >>>>>>>were typed instead of the $include statement. The same text file can be included >>>>>>>in as many places as you like, so the kind of inline optimization discussed here >>>>>>>is easy to implement. My compiler also allows Basic and assembler code to be >>>>>>>freely intermixed, which is useful for speeding up critical parts of the code. I >>>>>>>don't know how well it would compare with C, however. Does anyone else use >>>>>>>anything but C to write chess programs? >>>>>>> >>>>>>>Best wishes, >>>>>>>Roberto >>>>>> >>>>>>There is no magic language you should use to write chess programs. The >>>>>>advantages of C are that the compilers are quite good and C is widely >>>>>>available in many platforms. Basic may be quite good too, I don't >>>>>>really know but I suspect the good compiler technology exists for >>>>>>basic also so I don't see why not. The #include "filename" works >>>>>>just fine in C and probably other languages as well. >>>>>> >>>>>>My own personal opinion is that most languages will work and it should >>>>>>be possible to write a very strong program in them. However you cannot >>>>>>expect an interpreted language to work well because of the speed. >>>>>>So compiled Basic, Pascal, C and others should be fine. >>>>>>Rexchess was written in assembly with a little Pascal mixed in. >>>>>> >>>>>>I do think you might have a small edge in using C since it's usually >>>>>>cutting edge and often considered the language of choice for fast >>>>>>efficient optimizations. If you are adding assembly code (and doing >>>>>>it well) there may little or no difference however. >>>>>> >>>>>>I think it is more important to be happy with the language you are >>>>>>using and feeling productive and comfortable with it. >>>>>> >>>>>>- Don >>>>> >>>>>Hi Don, >>>>> >>>>>I have heard about all sorts of compiler optimization available in C compilers, >>>>>but since I am used to Basic I have stuck with it. Until very recently I only >>>>>had a 16-bit compiler for Basic to create DOS applications, but the >>>>>manufacturers (PowerBasic Inc) have recently released two 32-bit Basic compilers >>>>>for creating Windows programs with very similar syntax to the DOS versions. I >>>>>ported my old code to the new compiler, and it's pretty fast now. The PowerBasic >>>>>compiler also does some fancy optimisation stuff (eg register variables), but I >>>>>have no idea how well it compares to C. It is certainly orders of magnitude >>>>>faster than the Visual Basic Compiler, which is really only an interpretter >>>>>anyway. Interestingly, they have stated there intention to develop versions of >>>>>this compiler for other platforms such as linux and unix in the future, which >>>>>would make it very portable. I mainly use the assembler for doing loops through >>>>>bitboards, since then I can do everything in registers instead of RAM. >>>>> >>>>>I do find it disheartening that everyone quotes code in C, because I have to >>>>>struggle to make any sense of it. I can generally understand Pascal easily >>>>>enough, because the syntax is very similar to Basic, and also to a large extent >>>>>Fortran, although I haven't seen any Fortran code in decades now. >>>>> >>>>>BTW did you manage to find your old RexChess preprocessor code that you >>>>>developped with Larry? You said yo would send it to me of you could find it. >>>>> >>>>>Best wishes, >>>>>Roberto >>>> >>>> >>>>I did not find the RexChess source code at all. I went through every >>>>possible source I have (old boxes of diskettes etc.) Unfortunately >>>>I am not always as well organized as I wish I were. It looks like >>>>this is lost forever. >>>> >>>>However I found a later program of mine with a pre-processor and 2 >>>>separate "rulebases", one for middle and one for endgames. But >>>>the pre-processor is mixed in with dynamic evaluation ulike REX >>>>which was (except for a few pawn structure terms) entirely piece >>>>square pre-processed tables. >>>> >>>>The only >>>>problem is that I don't really have the rights to this program and >>>>could not make them available in good conscience. I am planning on >>>>checking into this after contacting the company that does have the >>>>rights to it. It's the program that won the 93 ACM international >>>>championship, it's old enough that they might not be interested in it >>>>anymore. I also must check with Larry Kaufman who is co-author with >>>>me on this one. If they say no then I must say no too. I have to >>>>also re-check the contract, there may be a date clause or something. >>>>But I will honor their wishes. >>>> >>>>My plan is to make it public domain if possible. I will make some >>>>changes that will definitely strengthen it too. All this is >>>>hypothetical so we will have to see. The program should be very >>>>strong though, it's quite a bit stronger than anything of mine that >>>>ever got released. The user interface may not be too cool at first >>>>until I figure out what to do about it. Perhaps the first pass will >>>>be xboard (and winboard) compatibility. >>>> >>>>Someone should write a super cool GUI for chess programs (at least for >>>>Unix and Windows) that's trivial to interface and public domain. >>>>Something a lot better than Xboard. Does anyone know about compatible >>>>gui libraries that are not commercial? I've considered XFORMS (unix) >>>>but there is no windows version although there is talk of development. >>>>tcl/tk or just tk is one possiblility which I think is available on >>>>both platforms. Does anyone else have a good sense of what is available >>>>and non-commercial? >>>> >>>>- Don >>> >>> >>>I'm not sure how someone would write "something better than xboard" and >>>remain portable across all versions of X and unix and win95/98 and so >>>forth. It provides easy access to an engine, a chess server, and engine >>>vs engine test matches. All it is missing is a set of menus that let you >>>get to all of an engine's options, but that would be so non-portable for >>>certain... >>> >>>My impression of xboard has been quite good, personally. You need to try >>>to provide something that interfaces with a dozen programs and have a go at >>>supporting such a thing. I don't envy Tim in the least. Crafty is quite a >>>pain maintaining portability across every machine I know of, including the >>>multiprocessing stuff. It is a challenge... >> >>I'm not knocking xboard. But I don't view it as a total solution. >>It's really limited as a full featured interface although you make >>a good point that it has some nice features most interfaces do not >>have. >> >>We have our own interface for this reason but I have noticed that >>xboard does gradually improve over time. Perhaps the solution >>is to stick with xboard and even hack some code for it. I think >>a lot of features could be implemented portably. One thing I do >>with our own private interface protocol is let the interface >>support many features but the engine can return a message saying >>the feature is not supported. >> >>I agree that it's a little hairy and I don't envy Tim either. I >>actually do like the graphics and general look. Maybe I'll >>re-consider xboard based on your comments. >> >>- Don > > >It's worked pretty well, and has gotten better and better. Tim works >quite hard on it, and also gets input from the who-knows-how-many crafty >users that are using xboard/winboard as the GUI, rather than the more >portable text-only interface built in to it... > >Perhaps it is, or could be possible, to add some "do-it-yourself" menus >that let you specify a menu option, and (hidden) a string to send to the >engine to accomplish that. Xboard already has all the needed facilities >for handling the game, such as backing up, moving around, changing sides, >and so forth. But it could use a facility to make it easy to do things >like "no book" or "no tablebases" or "resign when a rook or more down". >I have commands to control everything in crafty, but with xboard you can >use the "send-to-program" pop-up to send a command, but it would be nicer >to have some configurable windows (maybe a "program option" pulldown) >that could be customized for each engine, since it is pretty obvious that >we are never going to have a uniform engine interface standard... Most of this is not hard. For instance, you can easily have a check box menu that is configurable by the chess program, you send xboard a desciption of the menu and the defaults and xboard can send back changes. This type of thing can work with other parameters too. I don't believe that having a uniform interface standard is hard to do or unlikely at all, but someone actually has to do it, that is where the problem comes in! Perhaps Xboard is the defacto standard right now. One complaint is that I would love to be able to drag pieces. Right now it acts as if they are being dragged, but the pieces do not actually move until you let go of the mouse. Our tcl/tk interface has this and it adds more to the program than you would think. - Don
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.