A gentleman on the CCC forum mentioned that there may be a new format out that Shredder 10 is using.
Anyone know if this is true and some info on it?
Normal questions: licensing/code available for generation and use in an engine
-Josh
New egtb format?
-
guyhaw
- Posts: 489
- Joined: Sat Jan 21, 2006 10:43 am
- Sign-up code: 10159
- Location: Reading, UK
- Contact:
EGT formats
Thanks for referring to CCC posts.
I for one have essentially given up on CCC: it's full of clutter and now - ironically - I thnk it is harder to look up an old thread than it was.
I hope this EGT BB doesn't go the same way.
I'm not expert in all aspects of the 'EGT format': JT and RA had to remind me about the CRC-per-block checksum and the datacomp test for example.
However, options for moving to a new format include:
- creating WLD EGTs (though securing wins from such EGTs is fraught in Checkers and more so in Chess)
but they could be a useful efficiency-prelude to create DTx EGTs
- moving to the DTZ metric: _much_ smaller EGTs, and better guard against a k-move rule (though not perfect)
- having more comprehensive header information
metric, degree_of_completion, sub-endgame range,
author, date of completion, hw/OS/programs used for generation/verification
- having an index-system which is less demanding of RAM at runtime
- partitioning EGTs across files in some Pawn-position related way
e.g. for KPK, KP(a6)K and KP(a5)K rather than KP(a6)K and KP(b6)K in same file
Changing would require a change to engine-architecture to handle multiple formats of EGT and the new format(s) - and the co-operation of the sales channel.
g
I for one have essentially given up on CCC: it's full of clutter and now - ironically - I thnk it is harder to look up an old thread than it was.
I hope this EGT BB doesn't go the same way.
I'm not expert in all aspects of the 'EGT format': JT and RA had to remind me about the CRC-per-block checksum and the datacomp test for example.
However, options for moving to a new format include:
- creating WLD EGTs (though securing wins from such EGTs is fraught in Checkers and more so in Chess)
but they could be a useful efficiency-prelude to create DTx EGTs
- moving to the DTZ metric: _much_ smaller EGTs, and better guard against a k-move rule (though not perfect)
- having more comprehensive header information
metric, degree_of_completion, sub-endgame range,
author, date of completion, hw/OS/programs used for generation/verification
- having an index-system which is less demanding of RAM at runtime
- partitioning EGTs across files in some Pawn-position related way
e.g. for KPK, KP(a6)K and KP(a5)K rather than KP(a6)K and KP(b6)K in same file
Changing would require a change to engine-architecture to handle multiple formats of EGT and the new format(s) - and the co-operation of the sales channel.
g