UCI Hash Usage Rules

[hgm]

If I want an engine to use a 1GB transposition table, attempting to set the parameter to 1GB isnt enough under HGM's definition, as the value I asked for is not the value that I will get. I will also need to know how much the engine is going to deduct from the value that I asked for, and that may even be based on the value of another setting.

Now I am juggling several settings just to set what was otherwise just a single setting. I guess HGM thinks this makes it twice as fun? I don't think he realizes that it actually makes it HARDER to achieve fairness when setting interact in poorly defined and absurdly specified ways.

UCI isnt a same-resources-please tournament specification. That would be somewhat... not Universal.

The point is that the typical user never wants to use 1GB (or whatever) TT hash. Because he has no clue about the difference between TT, Pawn Hash, eval cache, NN weight cache, counter-move table, ... (or a hole in the ground, or that matter). These are concepts only meaningful to engine programmers or other CC experts like testers. A very small group. The average user is just interested in setting a value that makes his engine make best use of the computer he has. If he sets 1GB, he wil do it because he found that setting 'Hash size' to 1GB works for all other engines, not because he wants a TT of 1GB. In fact most GUIs would do this automatically, applying a general hash setting to all engines. And he will be very (unpleasantly) surprised when the engine then does not work at all, while all other engines do. And he will have no clue how to cure this.

Because GUIs automatically apply the same value to all engines, it is important that all engines behave the same for the same setting of this parameter. Making some engines work fine, while others would be totally wrecked (hashing on disk) for a universally applied setting does not serve the interest of the typical user.

I am not sure what you mean by the 'fairness' remark. We have had this discussion before. What do you consider 'fair'? If they both run with equal hash, despite that the other uses 2 times as much memory for other purposes (say memory-loaded bitbases), or if they can both fully use the resources of the same computer? Anyway, it was pointed out many times that fairness is not amongst the goals of UCI. But making things work smoothly for the user is. Forcing him to alter hash size on a per-engine basis for technical reasons he does not understand definitely does not qualify as 'smooth operation'.

[hgm]

So nowhere do I imply that UCI engine authors are "stupid".

You clamed that no UCI author would discount the size of huge additional tables from the TT (to keep total memory use constant), which would obviously make his engine require special treatment (changing the Hash value), which the typical user would not be able to provide. IMO making engines so that they predictably would cause trouble for its users qualifies as 'stupid'.

Nor do I write anything amounting to "to hell with the UCI specs, no one takes those seriously anyway.

By adopting the stance that the UCI specs don't have to be followed to the letter, "because they were not drawn up by lawyers", you did exactly that. I you would take the specs seriously, the fact that it uses the plural woul be decisive.

Just go ahead, use as many additional memory as you want. Make an engine that causes as much trouble for its users as you can, because a misinterpretation of the UCI specs perfectly allows you to do so, and you can always hide behind that."

That is an unavoidable consequence of allowing other options to specify additional memory use over the specified Hash option, rather than deduct them from TT size to keep the total memory use constant. And you do argue against the interpretation of Hash as total memory.

[syzygy]

So nowhere do I imply that UCI engine authors are "stupid".

You clamed that no UCI author would discount the size of huge additional tables from the TT (to keep total memory use constant),

Already here you are misrepresenting my words. I simply stated that, to my knowledge, all UCI authors treat the Hash setting as the (maximum) size of the TT. That is a completely neutral, factual statement about UCI authors.

which would obviously make his engine require special treatment (changing the Hash value), which the typical user would not be able to provide. IMO making engines so that they predictably would cause trouble for its users qualifies as 'stupid'.

So that's a boatload of your own interpretation and misgivings that you were trying to attribute to me. It's your usual trick, and there are no nice words for it.

[hgm]

So you want to argue that "making engines so that they predictably would cause trouble" would be considered a smart thing to do, by the majority of people?

[syzygy]

So you want to argue that "making engines so that they predictably would cause trouble" would be considered a smart thing to do, by the majority of people?

There you go again. Boring.

[hgm]

"yes" or "no" would have sufficed; then we could make some progress. Of course I can understand why it is not really in your interest to make any progress resolving this, and that dodging painful questions offers some hope to get off the hook.

[syzygy]

"yes" or "no" would have sufficed; then we could make some progress. Of course I can understand why it is not really in your interest to make any progress resolving this, and that dodging painful questions offers some hope to get off the hook.

There is nothing to resolve because I have been more than clear already. The topic of this thread is the meaning of the UCI Hash option, so my contribution is limited exactly to that.

[hgm]

Dodgy, dodgy...

In fact most of your 'contribution' to this thread has been attempts to derail the discussion about that.

The meaning of the UCI Hash option is indeed clear, and I already gave it before you appeared.

You, however, advocate a deviating meaning, apparently feeling free to do so "because the specs were not drawn up by a lawyer", which furthermore would cause the engine of those authors who follow it (when it matters) would lead their engine to appear broken to the typical user.

[syzygy]

Dodgy, dodgy...

Indeed, and I am perfectly happy to dodge your questions and "let you boil in your soapy water".

In fact most of your 'contribution' to this thread has been attempts to derail the discussion about that.

Do you believe that yourself? I have been very careful to stick to a single issue here.

So far you have not disputed my point that all UCI engines treat the UCI Hash setting as the (maximum) size of the transposition table. (There may be exceptions, but I don't know of any.)

Apparently you take the view that it is somehow ridiculous to treat the UCI Hash setting that way. If you have that view, that's just fine with me. I am simply not going to argue for or against it.

But when you attempt to attribute to me that view of yours, then that's just cheap trolling.

[hgm]

Do you believe that yourself? I have been very careful to stick to a single issue here.

Ah, sure. Disputing the meaning of the term 'insisting' was no doubt part of that issue...

So far you have not disputed my point that all UCI engines treat the UCI Hash setting as the (maximum) size of the transposition table. (There may be exceptions, but I don't know of any.)

But when these engines do not use any other tables of significant size (as none of them that are aware of do), that is not evidence for either interpretation, right? Then ty also use the UCI Hash setting as the maximum size of the total, as the TT is the total.

This is why I asked whether you knew any UCI engine that would use significant memory in addition to the Hash (which then would not work for most users without altering the centralized Hash setting that is perfect for almost every other engine). If you could name one, you would have a point.

But of course you failed to provide an answer, which leaves you entirely empty handed.