What happens using egbb

[kranium]

Good riddance...

Agreed, Houdini 4 users will discover that the Syzygy bases are a vastly superior solution.

All the best,
Robert

??
Daniel's Scorpio Egbb's work extremely well with many engines...all Fruit derivatives that I know of, including Toga, Grapefruit, Cyclone have not had problems

i'm not sure what the issue is with Houdini...
(and i dont really care)

but i find it rude and disrespectful that you have used his 'free' software to help line your pockets with cash,
only to shit on him now, when a problem in Houdini's implementation is made public

[Daniel Shawul]

Thanks Norman! I warned him that the audience is not gullible...

[syzygy]

For egbbs, there is even a very simple implementation that has no hassle by just put the probe() inside eval. Other WDL databases do not work like that because they just return either Win,Loss or Draw but scorpio-egbbs work like majic there.

If you're not probing in interior tree nodes, you lose most of the advantages of using tablebases.

[kranium]

i think everyone agrees that your solution (offered 10 years after Daniels) has it's advantages...and i'm sure you are thrilled to be now partnering with the great Houdini

but my point is:
it could have been handled very differently, in a more respectful/thankful manner...

for ex: the next Houdini release could have simply replaced Scorpio with your solution, without the public put-down

in many ways it's part and parcel to what seems to be a pattern of Houdart self entitlement...
take and use everything and anything without respect or acknowledgement to anyone else

[Daniel Shawul]

What are you talking about? Eval() will be called eventually so it will avoid most progress problems since you will have the whole depth by which the engine searches by itself. The eval() implementation was so simple many authors had it work perfectly because the engine had the whole search depth to find ways to make progress. Only scorpio had an implemention to interrupt search earlier by using rules such as captures/pawn moves and make cutoffs earlier, currently 2/3*search_depth or earlier when pawn moves/capture. This was difficult for some to implement but using the whole search_depth by just probing at eval() , obviously, gives it more ways to find wins.

I understand you are new to this stuff which is probably why you DTZ, which IMO is pointless atleast for 5-men. I bet the story will not be much different for 6 men either since Diep uses WDL alone.

[syzygy]

i think everyone agrees that your solution (offered 10 years after Daniels) is an improvement...and i'm sure you are thrilled to be now partnering with the great Houdini

I am not partnering with anyone. Everybody is free to add support for my tablebase format.

for ex: the next Houdini release could have simply replaced Scorpio with your solution, without the public put-down

So you don't think the "good riddance" had anything to do with what you call a "public put-down". Anyway, this is just not interesting. It is too obvious that you bear some grudges.

[kranium]

So you don't think the "good riddance" had anything to do with what you call a "public put-down".

no, not important... both sides expressed the same sentiment:

Robert responded in kind:

Good riddance...

Agreed

[Daniel Shawul]

Norman ignore the trolls. They are just pissed that I started generating 6 men. Infact there wouldn't be a debate now if I hadn't dared to question bitboards aren't faster for move generation (inside joke)

[syzygy]

What are you talking about?

I think my point is pretty clear. The "right" way to use tablebases in the search is to probe them once a tablebase position is reached and to use the result to prune a whole subtree.

Progress towards a tablebase win can be ensured the same way one ensures progress towards a mate, i.e. by adding/subtracting the distance to root.

Once the game has reached a tablebase position, things are a bit different. I already explained some solutions.

Only scorpio had an implemention to interrupt search earlier by using rules such as captures/pawn moves and make cutoffs earlier, currently 2/3*search_depth or earlier when pawn moves/capture.

You would wait until 2/3*search_depth? That is reasonable if the root position is already in the tablebases.

I understand you are new to this stuff which is probably why you DTZ, which IMO is pointless atleast for 5-men. I bet the story will not be much different for 6 men either since Diep uses WDL alone.

I am so new to this stuff that you asked me 5 years ago how my "neat method" for indexing tablebases with k similar pieces worked.

[Daniel Shawul]

I think my point is pretty clear. The "right" way to use tablebases in the search is to probe them once a tablebase position is reached and to use the result to prune a whole subtree.

No you were talking about internal nodes and you thought I was probing at the root only. I have a pretty good progress making that avoids the need for DTM/DTZ that worked for years.

Progress towards a tablebase win can be ensured the same way one ensures progress towards a mate, i.e. by adding/subtracting the distance to root.

This is what I say you are new too. Just adding +/- PLY is not enough, you need to add a lot more factors from the position score, and merge is with WINPLY as well which is not necessarily 1. It would take a lot for me to explain all this and this is exactly what I said you are 'new' to, so chill.

So enjoy your partnership, and let me generate my 6 men ...