Search found 333 matches

by noobpwnftw
Sat Jan 07, 2017 2:53 am
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Enpass + Castling for Zorbist hashes
Replies: 21
Views: 3085

Re: Enpass + Castling for Zorbist hashes

The overhead of handling this issue is so small it should not be able to account for the drop of at least 3. Not to mention, that in theory, fixing this bug should be an elo gain. I guess the reason is although the overhead is relatively small, the circumstances that having these information accura...
by noobpwnftw
Fri Jan 06, 2017 10:34 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Enpass + Castling for Zorbist hashes
Replies: 21
Views: 3085

Re: Enpass + Castling for Zorbist hashes

The symptoms you observed may be a proof of my assumption (http://www.talkchess.com/forum/viewtopic.php?t=62639) that ignoring castling rights probably won't break the overall consistency of the search tree. I didn't thought about sending a pawn to be captured via EP is a bad move on ply-1 unless th...
by noobpwnftw
Thu Jan 05, 2017 1:24 am
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: New 6-piece tablebases
Replies: 194
Views: 106007

Re: New 6-piece tablebases

I've tried build EGTB with SSDs some years ago, they worn out soon after a single run. Just don't do it. :P Nowadays consumer-class servers can have 1TB of memory, I have some spare ones if you want to do a 7-man run. But even if we build it, its hard to distribute and we will end up with some kind ...
by noobpwnftw
Sun Jan 01, 2017 6:26 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

My implementation requires specific hardware and software stack, it isn't meant to be downloaded and ran effectively under any environment. Since I already built everything for it, I wonder if it is worthwhile to port it to chess for whoever interested. Typical use case for this is that you can have...
by noobpwnftw
Sun Jan 01, 2017 4:45 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

Hash keys, or at least a hash index to partition the database is always needed unless your database is not on a large scale. But we have differences about the definition of a node: My 46 bytes(worst case) per node is used for alternative indexing, and this index is less than 2x the size of a hash in...
by noobpwnftw
Sat Dec 31, 2016 9:22 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

I agree with using only hash is fast & compact, but let me describe my method here: move+score is stored in a LSM tree, one index is bitfen representation of the board, which would have 361 bits per board, round up to 46 bytes at most, stored by a 64-bit radix tree index it would have no more than 6...
by noobpwnftw
Sat Dec 31, 2016 5:58 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: GPU chess update, local memory....
Replies: 14
Views: 2943

Re: GPU chess update, local memory....atomics...64 bit ops

GPU is not optimized for control logic, which is used extensively in chess engines. Even if you do get the same or better performance with NPS, it is still not efficient when pruned search is introduced. You would either waste too much on cut-offs(lazy) or waiting for the slowest child(ybwc) or just...
by noobpwnftw
Sat Dec 31, 2016 5:35 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

You can see what it is like from my web query interface. It is a database of chess engine search tree and supports live "lazy smp" style extension. I wonder how is it possible that you can generate moves with only an arbitrary 64-bit hashkey of the board without performing enumerating from an known ...
by noobpwnftw
Sat Dec 31, 2016 10:23 am
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

Storage size is not a problem, I wish to seek the possibility of saving the extra calculation/evaluation of the "same position" with different castling rights, it now seems not very viable after your discussion. It would be pretty much the same as my current Chinese chess implementation, can you kin...
by noobpwnftw
Thu Dec 29, 2016 11:20 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 4989

Re: Cumulative building of a shared search tree

You are right, in the endgames it is possible to make a subset for each castling condition if we have the "standard" tablebases, where this subset contains only the outcome of conversion to non-castling positions. My question is that if I want to build a large database for the opening stage, can I a...