New engine release: Jumbo

[Sven]

A successor to Surprise.

Yes, but also to KnockOut.
Surprise was released in 2004, KnockOut in 2010, Jumbo in 2016.

[mar]

Yes, but also to KnockOut.
Surprise was released in 2004, KnockOut in 2010, Jumbo in 2016.

I sense a pattern
Congratulations

[Adam Hair]

Did you write the code from scratch or did you copy from an established engine such as Moron? I seem to recall some dispute between you and Fern about code similarities

Seriously, your announcement has caused me for the first time in a awhile to wish that I had an active computer. I would love to run some matches with Jumbo. I am glad to see that you are still active, Sven.

[Sven]

Yes, but also to KnockOut.
Surprise was released in 2004, KnockOut in 2010, Jumbo in 2016.

I sense a pattern
Congratulations

Code: Select all

By year:

2016                       xx
2014                    ..
2012                 ..
2010              xx
2008          ..
2006       ..
2004    xx

     Surprise  KnockOut  Jumbo


By target elo:

3000                       xx
2700                    ..
2400                  ..
2100              xx
1800    xx

     Surprise  KnockOut  Jumbo

[Sven]

Thanks Sven.

I have a problem, though. Maybe I'm doing something wrong but I have had 75 time forfeits by Jumbo out of 139 games. WinBoard 4.0.8b used under 64-bit Win10.

It may very well be the well-known problem of the engine not counting the moves fed by an external book.

Hi Gabor,

I guess you did not use WinBoard 4.0.8b but a more recent version ...

Moves fed by an external book should usually not cause a problem, Jumbo should handle that correctly. It may be a problem of the time management code, though. Which TC did you use, and do you have a debug log?

[Guenther]

Thanks Sven.

I have a problem, though. Maybe I'm doing something wrong but I have had 75 time forfeits by Jumbo out of 139 games. WinBoard 4.0.8b used under 64-bit Win10.

It may very well be the well-known problem of the engine not counting the moves fed by an external book.

Hi Gabor,

I guess you did not use WinBoard 4.0.8b but a more recent version ...

Moves fed by an external book should usually not cause a problem, Jumbo should handle that correctly. It may be a problem of the time management code, though. Which TC did you use, and do you have a debug log?

Hi Sven,

It was a typo, I use 4.8.0b.

I use 40 moves in 1 minutes and 50 seconds. No debug yet but I'll switch it on for a couple of games.

Is that mixed time control really supported by xboard programs?

[ZirconiumX]

Is that mixed time control really supported by xboard programs?

Although I have seen exceptions, in general: yes.

The XBoard protocol allows a level command to be in minutes:seconds form, so a 40/1m50s would be a "level 40 1:50 0" string. UCI handles this by using milliseconds as its native time management granularity.

[Guenther]

Is that mixed time control really supported by xboard programs?

Although I have seen exceptions, in general: yes.

The XBoard protocol allows a level command to be in minutes:seconds form, so a 40/1m50s would be a "level 40 1:50 0" string. UCI handles this by using milliseconds as its native time management granularity.

I guess we have a missunderstanding. I thought Gabor means 40/1m +50s inc.

[ZirconiumX]

Is that mixed time control really supported by xboard programs?

Although I have seen exceptions, in general: yes.

The XBoard protocol allows a level command to be in minutes:seconds form, so a 40/1m50s would be a "level 40 1:50 0" string. UCI handles this by using milliseconds as its native time management granularity.

I guess we have a missunderstanding. I thought Gabor means 40/1m +50s inc.

Actually, XBoard protocol *also* supports that. Increment is what the third field in "level" is for. So 40 moves in 1 minute plus 50 seconds increment per move would be "level 40 1 50". But I don't see why you'd ever want to do that.

[Guenther]

Is that mixed time control really supported by xboard programs?

Although I have seen exceptions, in general: yes.

The XBoard protocol allows a level command to be in minutes:seconds form, so a 40/1m50s would be a "level 40 1:50 0" string. UCI handles this by using milliseconds as its native time management granularity.

I guess we have a missunderstanding. I thought Gabor means 40/1m +50s inc.

Actually, XBoard protocol *also* supports that. Increment is what the third field in "level" is for. So 40 moves in 1 minute plus 50 seconds increment per move would be "level 40 1 50".

AFAIK it is supported since not too long ago, but a lot of programs might choke on this.

But I don't see why you'd ever want to do that.

Well people do a lot of weird things ;-)