Author: Don Dailey
Date: 12:28:18 07/12/98
Go up one level in this thread
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
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.