Komodo bug?

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Laszlo Gaspar
Posts: 64
Joined: Thu Mar 09, 2006 11:07 am
Location: Budapest, Hungary

Komodo bug?

Post by Laszlo Gaspar »

Dear Don,

It seems to me that this is a search bug in Komodo CCT:

Code: Select all

2013-05-30 21&#58;58&#58;05,217<--1&#58;info depth 20 time 5026 nodes 3727408 score cp 396 nps 741625 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d6 e3c5 b4b3 c5d6 f6d6 f2f4 b3b4 g2f3 d6f6 c7c4 b4b3 c4c5 f6d6 c5c7 b3b4 c7c4 b4a5 c4c3 a5a4 c3c1 a4b4 
2013-05-30 21&#58;58&#58;05,221<--1&#58;info depth 21
2013-05-30 21&#58;58&#58;05,222<--1&#58;info currmove e7c7 currmovenumber 1
2013-05-30 21&#58;58&#58;10,811<--1&#58;info depth 21 time 10619 nodes 7696894 score cp 399 nps 724822 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d5 e3h6 d5d6 h6e3 d6c6 c7b7 b4c3 e2f3 c6a6 f3d5 a6d6 b7c7 c3d3 d5c4 d3c2 c4b5 c2b3 e3f4 f6f4 g3f4 b3b4 b5e2 d6d2 g2f3 d2d4 
2013-05-30 21&#58;58&#58;10,814<--1&#58;info currmove e3h6 currmovenumber 2
2013-05-30 21&#58;58&#58;15,931<--1&#58;info depth 21 time 15740 nodes 11700326 score cp 412 nps 743349 pv e3h6 
2013-05-30 21&#58;58&#58;15,934<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;32,792<--1&#58;info depth 21 time 32600 nodes 24577332 score cp 459 nps 753882 pv e3h6 
2013-05-30 21&#58;58&#58;32,796<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;50,750<--1&#58;info nodes 39025410
2013-05-30 21&#58;58&#58;50,751<--1&#58;bestmove e7c7 ponder c3b4
In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.
Regards,
László
User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 4:27 pm

Re: Komodo bug?

Post by Don »

Laszlo Gaspar wrote:Dear Don,

It seems to me that this is a search bug in Komodo CCT:

Code: Select all

2013-05-30 21&#58;58&#58;05,217<--1&#58;info depth 20 time 5026 nodes 3727408 score cp 396 nps 741625 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d6 e3c5 b4b3 c5d6 f6d6 f2f4 b3b4 g2f3 d6f6 c7c4 b4b3 c4c5 f6d6 c5c7 b3b4 c7c4 b4a5 c4c3 a5a4 c3c1 a4b4 
2013-05-30 21&#58;58&#58;05,221<--1&#58;info depth 21
2013-05-30 21&#58;58&#58;05,222<--1&#58;info currmove e7c7 currmovenumber 1
2013-05-30 21&#58;58&#58;10,811<--1&#58;info depth 21 time 10619 nodes 7696894 score cp 399 nps 724822 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d5 e3h6 d5d6 h6e3 d6c6 c7b7 b4c3 e2f3 c6a6 f3d5 a6d6 b7c7 c3d3 d5c4 d3c2 c4b5 c2b3 e3f4 f6f4 g3f4 b3b4 b5e2 d6d2 g2f3 d2d4 
2013-05-30 21&#58;58&#58;10,814<--1&#58;info currmove e3h6 currmovenumber 2
2013-05-30 21&#58;58&#58;15,931<--1&#58;info depth 21 time 15740 nodes 11700326 score cp 412 nps 743349 pv e3h6 
2013-05-30 21&#58;58&#58;15,934<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;32,792<--1&#58;info depth 21 time 32600 nodes 24577332 score cp 459 nps 753882 pv e3h6 
2013-05-30 21&#58;58&#58;32,796<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;50,750<--1&#58;info nodes 39025410
2013-05-30 21&#58;58&#58;50,751<--1&#58;bestmove e7c7 ponder c3b4
In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.
Yes, this is a bug I am aware of. But any time you see something like this let me know and I will try to fix it for next version.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Komodo bug?

Post by syzygy »

Laszlo Gaspar wrote:In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.
Some months ago I made some changes to the root search of my engine and the engine suddenly got 30-35 elo weaker when I played it against the old version. I undid most of the changes to get back as close as possible to the old version. In the end, node counts were exactly the same as those of the old version, but the 30-35 elo gap remained.

Guess what the bug was :-)

I suppose this bug somehow hurts Komodo CCT less than it hurt my engine, or maybe self-play magnified its effect. (Or maybe it is only under certain conditions that Komodo fails to play the move that failed high but for which a score has not yet been established?)
User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 4:27 pm

Re: Komodo bug?

Post by Don »

Laszlo Gaspar wrote:Dear Don,

It seems to me that this is a search bug in Komodo CCT:

Code: Select all

2013-05-30 21&#58;58&#58;05,217<--1&#58;info depth 20 time 5026 nodes 3727408 score cp 396 nps 741625 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d6 e3c5 b4b3 c5d6 f6d6 f2f4 b3b4 g2f3 d6f6 c7c4 b4b3 c4c5 f6d6 c5c7 b3b4 c7c4 b4a5 c4c3 a5a4 c3c1 a4b4 
2013-05-30 21&#58;58&#58;05,221<--1&#58;info depth 21
2013-05-30 21&#58;58&#58;05,222<--1&#58;info currmove e7c7 currmovenumber 1
2013-05-30 21&#58;58&#58;10,811<--1&#58;info depth 21 time 10619 nodes 7696894 score cp 399 nps 724822 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d5 e3h6 d5d6 h6e3 d6c6 c7b7 b4c3 e2f3 c6a6 f3d5 a6d6 b7c7 c3d3 d5c4 d3c2 c4b5 c2b3 e3f4 f6f4 g3f4 b3b4 b5e2 d6d2 g2f3 d2d4 
2013-05-30 21&#58;58&#58;10,814<--1&#58;info currmove e3h6 currmovenumber 2
2013-05-30 21&#58;58&#58;15,931<--1&#58;info depth 21 time 15740 nodes 11700326 score cp 412 nps 743349 pv e3h6 
2013-05-30 21&#58;58&#58;15,934<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;32,792<--1&#58;info depth 21 time 32600 nodes 24577332 score cp 459 nps 753882 pv e3h6 
2013-05-30 21&#58;58&#58;32,796<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;50,750<--1&#58;info nodes 39025410
2013-05-30 21&#58;58&#58;50,751<--1&#58;bestmove e7c7 ponder c3b4
In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.

It is possible this a major bug - but I doubt it will have much impact on the strength. Still, I should probably check it out sooner rather than later.

The reason I don't expect it to be major is that once an iteration has started, Komodo is going to try really hard to complete it. So when I fix it I will also do the UCI fail hi and fail low reported the proper way.

I have to wonder how many games Komodo failed to win or draw due to this bug.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Komodo bug?

Post by syzygy »

Don wrote:The reason I don't expect it to be major is that once an iteration has started, Komodo is going to try really hard to complete it.
Ah, good point. This must be the main reason why it does not affect Komodo as badly as it did my engine. (Obviously the reason for my assumption that it does not affect Komodo so badly is that even with this bug Komodo is playing quite well ;-))
User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 12:00 pm
Location: Slovakia, EU

Re: Komodo bug?

Post by rvida »

Don wrote:
Laszlo Gaspar wrote:Dear Don,

It seems to me that this is a search bug in Komodo CCT:

Code: Select all

2013-05-30 21&#58;58&#58;05,217<--1&#58;info depth 20 time 5026 nodes 3727408 score cp 396 nps 741625 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d6 e3c5 b4b3 c5d6 f6d6 f2f4 b3b4 g2f3 d6f6 c7c4 b4b3 c4c5 f6d6 c5c7 b3b4 c7c4 b4a5 c4c3 a5a4 c3c1 a4b4 
2013-05-30 21&#58;58&#58;05,221<--1&#58;info depth 21
2013-05-30 21&#58;58&#58;05,222<--1&#58;info currmove e7c7 currmovenumber 1
2013-05-30 21&#58;58&#58;10,811<--1&#58;info depth 21 time 10619 nodes 7696894 score cp 399 nps 724822 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d5 e3h6 d5d6 h6e3 d6c6 c7b7 b4c3 e2f3 c6a6 f3d5 a6d6 b7c7 c3d3 d5c4 d3c2 c4b5 c2b3 e3f4 f6f4 g3f4 b3b4 b5e2 d6d2 g2f3 d2d4 
2013-05-30 21&#58;58&#58;10,814<--1&#58;info currmove e3h6 currmovenumber 2
2013-05-30 21&#58;58&#58;15,931<--1&#58;info depth 21 time 15740 nodes 11700326 score cp 412 nps 743349 pv e3h6 
2013-05-30 21&#58;58&#58;15,934<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;32,792<--1&#58;info depth 21 time 32600 nodes 24577332 score cp 459 nps 753882 pv e3h6 
2013-05-30 21&#58;58&#58;32,796<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;50,750<--1&#58;info nodes 39025410
2013-05-30 21&#58;58&#58;50,751<--1&#58;bestmove e7c7 ponder c3b4
In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.

It is possible this a major bug - but I doubt it will have much impact on the strength. Still, I should probably check it out sooner rather than later.

The reason I don't expect it to be major is that once an iteration has started, Komodo is going to try really hard to complete it. So when I fix it I will also do the UCI fail hi and fail low reported the proper way.

I have to wonder how many games Komodo failed to win or draw due to this bug.
I did some research with Critter about handling fail highs at root. I measured the probability of unresolved fail highs being the new best move. Whenever the time management decided to stop the search and there was an unresolved fail high, I forced the engine to finish the iteration and logged the result to see if it really found a better move.

- if a move failed high ONCE, there was an 88% probability that this will be the new best move (this surprised me - I expected a higher number)
- if a move failed high TWICE, the probability increased to 97.5%
- on THIRD fail high the probability was 99.97%

I found out that if the time is really running out, it is quite safe to accept a new move after it failed high 2x. Obviously, if there is enough time, the safest way is to finish the iteration.
User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 12:00 pm
Location: Slovakia, EU

Re: Komodo bug?

Post by rvida »

rvida wrote: I did some research with Critter about handling fail highs at root. I measured the probability of unresolved fail highs being the new best move. Whenever the time management decided to stop the search and there was an unresolved fail high, I forced the engine to finish the iteration and logged the result to see if it really found a better move.

- if a move failed high ONCE, there was an 88% probability that this will be the new best move (this surprised me - I expected a higher number)
- if a move failed high TWICE, the probability increased to 97.5%
- on THIRD fail high the probability was 99.97%

I found out that if the time is really running out, it is quite safe to accept a new move after it failed high 2x. Obviously, if there is enough time, the safest way is to finish the iteration.

A somewhat related topic was also discussed in this thread
User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 4:27 pm

Re: Komodo bug?

Post by Don »

rvida wrote:
Don wrote:
Laszlo Gaspar wrote:Dear Don,

It seems to me that this is a search bug in Komodo CCT:

Code: Select all

2013-05-30 21&#58;58&#58;05,217<--1&#58;info depth 20 time 5026 nodes 3727408 score cp 396 nps 741625 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d6 e3c5 b4b3 c5d6 f6d6 f2f4 b3b4 g2f3 d6f6 c7c4 b4b3 c4c5 f6d6 c5c7 b3b4 c7c4 b4a5 c4c3 a5a4 c3c1 a4b4 
2013-05-30 21&#58;58&#58;05,221<--1&#58;info depth 21
2013-05-30 21&#58;58&#58;05,222<--1&#58;info currmove e7c7 currmovenumber 1
2013-05-30 21&#58;58&#58;10,811<--1&#58;info depth 21 time 10619 nodes 7696894 score cp 399 nps 724822 pv e7c7 c3b4 d5f3 d1d3 f3e2 d3d5 e3h6 d5d6 h6e3 d6c6 c7b7 b4c3 e2f3 c6a6 f3d5 a6d6 b7c7 c3d3 d5c4 d3c2 c4b5 c2b3 e3f4 f6f4 g3f4 b3b4 b5e2 d6d2 g2f3 d2d4 
2013-05-30 21&#58;58&#58;10,814<--1&#58;info currmove e3h6 currmovenumber 2
2013-05-30 21&#58;58&#58;15,931<--1&#58;info depth 21 time 15740 nodes 11700326 score cp 412 nps 743349 pv e3h6 
2013-05-30 21&#58;58&#58;15,934<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;32,792<--1&#58;info depth 21 time 32600 nodes 24577332 score cp 459 nps 753882 pv e3h6 
2013-05-30 21&#58;58&#58;32,796<--1&#58;info currmove e3h6 currmovenumber 1
2013-05-30 21&#58;58&#58;50,750<--1&#58;info nodes 39025410
2013-05-30 21&#58;58&#58;50,751<--1&#58;bestmove e7c7 ponder c3b4
In the aspiration window framework the engine finds a new, better move (e3h6) but the time is not enough to establish the score and the best move is not updated. It plays finally the old best move.

It is possible this a major bug - but I doubt it will have much impact on the strength. Still, I should probably check it out sooner rather than later.

The reason I don't expect it to be major is that once an iteration has started, Komodo is going to try really hard to complete it. So when I fix it I will also do the UCI fail hi and fail low reported the proper way.

I have to wonder how many games Komodo failed to win or draw due to this bug.
I did some research with Critter about handling fail highs at root. I measured the probability of unresolved fail highs being the new best move.
Just to be clear, did you take statistics only when the move was a NEW move and not the same move from the previous iteration?

Whenever the time management decided to stop the search and there was an unresolved fail high, I forced the engine to finish the iteration and logged the result to see if it really found a better move.

- if a move failed high ONCE, there was an 88% probability that this will be the new best move (this surprised me - I expected a higher number)
- if a move failed high TWICE, the probability increased to 97.5%
- on THIRD fail high the probability was 99.97%

I found out that if the time is really running out, it is quite safe to accept a new move after it failed high 2x. Obviously, if there is enough time, the safest way is to finish the iteration.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
User avatar
Rebel
Posts: 6991
Joined: Thu Aug 18, 2011 12:04 pm

Re: Komodo bug?

Post by Rebel »

rvida wrote:I did some research with Critter about handling fail highs at root. I measured the probability of unresolved fail highs being the new best move. Whenever the time management decided to stop the search and there was an unresolved fail high, I forced the engine to finish the iteration and logged the result to see if it really found a better move.

- if a move failed high ONCE, there was an 88% probability that this will be the new best move (this surprised me - I expected a higher number)
- if a move failed high TWICE, the probability increased to 97.5%
- on THIRD fail high the probability was 99.97%

I found out that if the time is really running out, it is quite safe to accept a new move after it failed high 2x. Obviously, if there is enough time, the safest way is to finish the iteration.
These numbers confirm my own testing. And when you fail-high at the first move there hardly is a risk at all, exceptions are very rare.

What's also interesting to research (changing the topic a bit) are the false fail-high's, often they will appear as best move one or two iterations later after all. In the 90's I tested 2 options:

1. Accept any false fail-high as best move;

2. Research a false fail-high again but now one ply deeper.

Due to the limited hardware of these days plus the fact false fail-high's are rare it was impossible to make an educated decision.
User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 12:00 pm
Location: Slovakia, EU

Re: Komodo bug?

Post by rvida »

Don wrote:
Just to be clear, did you take statistics only when the move was a NEW move and not the same move from the previous iteration?
Yes, only when the move was a different one.