Author: Robert Hyatt
Date: 10:12:21 07/08/04
Go up one level in this thread
On July 08, 2004 at 01:05:35, Keith Evans wrote: >On July 08, 2004 at 00:06:12, Robert Hyatt wrote: > >>On July 07, 2004 at 23:45:53, Keith Evans wrote: >> >>>On July 07, 2004 at 22:56:46, Robert Hyatt wrote: >>> >>>>On July 07, 2004 at 20:55:10, Mike Byrne wrote: >>>> >>>>>On July 07, 2004 at 11:51:44, Gian-Carlo Pascutto wrote: >>>>> >>>>>>...in the blitz tournament :) >>>>>> >>>>>>Couldn't get a PGN yet. >>>>>> >>>>>>-- >>>>>>GCP >>>>> >>>>>Whew - I thought you meant at long time controls. We all know anything cna >>>>>happen in Blitz, just ask Topalov. >>>>> >>>>>;>) >>>> >>>> >>>>I have not looked at the games. But Peter and I discussed this and we chose to >>>>use my wide-open ICC book for these games to avoid giving away anything about >>>>his tournament preparation. >>>> >>>>I knew that we would bust one or more openings. The one thing I forgot is that >>>>I cleverly copied my binary books from my xeon to the opteron. Doesn't work. >>>>90% of my book was unusable leading to some bizarre opening choices. I did that >>>>late at night and just forgot that even though the opteron and xeon are both >>>>little-endian, the opteron has a longer struct padding (to 8 bytes rather than 4 >>>>bytes) which kills my binary book copy. >>>> >>>>Stupid. Stupid. Stupid. >>>> >>>>I should have remembered. :( >>> >>>Is there any way that you can have crafty automatically detect that a binary >>>book has been "corrupted" in this fashion? This seems worth doing. If you made >>>this mistake, then surely a lot of other people will make the same mistake. >> >>No. But there is a plan to have a portable binary format for Crafty. Part of >>the code is written. The rest will be finished after the WCCC, and will start >>version 20.0 with a new binary book format. I'll read byte-by-byte and pack the >>bytes into a struct after reading, to avoid this endian stuff and varying >>lengths for floating point and binary numbers and the structure padding >>incompatibilities. >> >>IE when I get this finished, a book.bin will be transportable to any >>architecture and this problem will be history. That is the only responsible way >>to solve this mess... >> >>I can't "detect" it unfortunately, although I could add a signature to the end >>of the file (the same as I do for the version) to note that it was big endian, >>little endian, and 32 vs 64 bit. But the architecture independent approach is >>better for obvious reasons. > >I didn't know that you were planning on this. It's definitely much better to be >able to use a book, than to see a message "Sorry your book isn't compatible >please try again." Part of the code is already in the source, other working pieces are not yet. The idea is to have a function to read a 32 bit int as 4 consecutive bytes, then piece 'em together so that it works regardless of the endianness. No structures so there is no padding. Etc... Just a stream of bytes in the book.bin file...
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.