Komodo 10 released

[lkaufman]

Up to now I was OK seeing an engine display a score of 0.7, I knew its advantage was equal to almost one pawn.
Now if I set Magnify from 88 to 200, the same position provides a score of about 1.5.
This is confusing, to obtain a traditional value I will always have to check the value of Magnify and modify the score accordingly.

Do we really need this?

Why not just leave it at the default level then? It does reduce scores on average a bit from K9.42, but I think it just roughly brings them back on average to levels Komodo used a year or two ago. It's not the most useful option; we may not keep it in the future.

[Laskos]

This is awful. There is a standard for scoring, and GUIs as well as engines should stick to it. Options like this just promote chaos.

What is awful, is that there is a standard for scoring, and, worse, that this standard is not well defined. I wonder if this standard did not constrain too much engine programmers to stick with a single way to evaluate a position. Instead of a centipawn, why not a winning probability, a distance to make progress, a millipawn, or whatever else?
Moreover, nothing is more volatile than the value of a pawn. Can you show us this unknown pawn that should be use as a reference of 100 centipawns?

I think some engine authors do use some winning probability, say 65% for 100cp. And it correlates well with the static value of the pawn in endgame for many.

[cma6]

Thanks, LK, I will experiment with that.

[whereagles]

The $99 is just about par for US standards. Trouble is, those are high standards

[abulmo]

I think some engine authors do use some winning probability, say 65% for 100cp. And it correlates well with the static value of the pawn in endgame for many.

Take kpk as an example. In kpk, there are 67,168% of winning positions (for the side with the pawn), so here we have an exact relationship between one pawn and a winning probability. But... each kpk position is or an exact draw or an exact win not a probable win at 67.168%. A good evaluation should give a value of 0 or +mate (In practice a more moderate value, with some tricks to allow progress) not a +100 cp to a kpk position.

[schack]

Larry et al - is the engine available from Chessbase the same as the one directly from you guys? (I know the Chessbase people tend to put some kind of copy protection on their versions.)

[lkaufman]

Larry et al - is the engine available from Chessbase the same as the one directly from you guys? (I know the Chessbase people tend to put some kind of copy protection on their versions.)

As of now, they are identical except for copy protection differences and some GUI set options; for example we make 1 thread the default, CB tries to guess how many cores you have, often reporting 8 instead of 4 and using 8 when 4 is a better choice. If we offer any free bug-fix upgrades CB has the option to offer them too. CB will probably not offer unfree upgrades (10.1,10.2 etc).

[Ozymandias]

CB will probably not offer unfree upgrades (10.1,10.2 etc).

You don't know? Isn't that in the contract?

[lkaufman]

CB will probably not offer unfree upgrades (10.1,10.2 etc).

You don't know? Isn't that in the contract?

The contract only gives them upgrades for a short time, but we can always agree to give them upgrades after that date on request.

[rabbits23]

Agreed. I've got Komodo 9.42 and paid just over $100 for it. I've enjoyed
experimenting with it enormously and don't begrudge the programmers a cent
of their money.
Allan