SF beats Lc0 from start position!
Moderator: Ras
-
- Posts: 3621
- Joined: Wed Mar 08, 2006 8:15 pm
- Full name: Jouni Uski
-
- Posts: 3621
- Joined: Wed Mar 08, 2006 8:15 pm
- Full name: Jouni Uski
-
- Posts: 3379
- Joined: Sat Feb 16, 2008 7:38 am
- Full name: Peter Martan
Re: SF beats Lc0 from start position!
Remarkable once in while again, that Lc0 doesn't see the losing blunder 44...g5? as for the eval of its own until move 50, while SF jumps to +- at once after the losing move of Black's, regards
Peter.
-
- Posts: 498
- Joined: Wed Mar 08, 2006 9:45 pm
- Location: Portland, OR
Re: SF beats Lc0 from start position!
Worse than that, seems like there is some severe memory or time management bug in LC0. It started using drastically less time after move 29 when the position became locked up, then absolutely no time at all and depth 1 starting on move 37. The blunder was on move 44.
-
- Posts: 2097
- Joined: Wed Jul 13, 2011 9:04 pm
- Location: Madrid, Spain.
Re: SF beats Lc0 from start position!
Hello:
I would like to remark how deep they went into known theory without opening book. It is not new at all, but is also quite encouraging.
Lc0's blindness is notorious. For example:
48.- Nf4 (SF → +4.47), Bf7 (Lc0 → +0.12); 49.- Nh5 (SF → +4.65).
[...]
55.- Kf3 (SF → +199.48), Kb7 (Lc0 → +0.75); 56.- Be6 (SF → +199.47).
All evals from white's POV. It was surely produced by what Ian says.
Regards from Spain.
Ajedrecista.
I would like to remark how deep they went into known theory without opening book. It is not new at all, but is also quite encouraging.
Lc0's blindness is notorious. For example:
48.- Nf4 (SF → +4.47), Bf7 (Lc0 → +0.12); 49.- Nh5 (SF → +4.65).
[...]
55.- Kf3 (SF → +199.48), Kb7 (Lc0 → +0.75); 56.- Be6 (SF → +199.47).
All evals from white's POV. It was surely produced by what Ian says.
Regards from Spain.
Ajedrecista.
-
- Posts: 3379
- Joined: Sat Feb 16, 2008 7:38 am
- Full name: Peter Martan
Re: SF beats Lc0 from start position!
There must have definitely something been wrong with Lc0 and its time management in this game. If I read the time used correctly (mt= pondertime in milliseconds?) the engine moved from 44th move till the end of the game within about 1 centi- second (10msec) per move each time, didn't it?
Starting Lc0 with 3070ti GPU and 6147500PT- net at the postion before Black's 44th move, it doesn't get the blunder ...g5? there into output at all (switching to MultiPV=6 it's ranked 5th with 157cp, best is ...Bd8 with 058, best one getting lower over time pondering, ...g5 higher from White's point of view) and its eval jumps to +- at once after the move is given in.
Starting Lc0 with 3070ti GPU and 6147500PT- net at the postion before Black's 44th move, it doesn't get the blunder ...g5? there into output at all (switching to MultiPV=6 it's ranked 5th with 157cp, best is ...Bd8 with 058, best one getting lower over time pondering, ...g5 higher from White's point of view) and its eval jumps to +- at once after the move is given in.
Peter.
-
- Posts: 69
- Joined: Tue Sep 04, 2018 5:33 am
- Full name: John Kominek
Re: SF beats Lc0 from start position!
As I understand it, when lc0 runs out of memory it abandons search and reverts to single-node "search" to select next moves, i.e. making use of the policy network only at the root. That happened in the TCEC game 4 of the VVLTC bonus. For some reason the OOM bug has persisted.peter wrote: ↑Sat Apr 12, 2025 9:04 pm There must have definitely something been wrong with Lc0 and its time management in this game. If I read the time used correctly (mt= pondertime in milliseconds?) the engine moved from 44th move till the end of the game within about 1 centi- second (10msec) per move each time, didn't it?
Starting Lc0 with 3070ti GPU and 6147500PT- net at the postion before Black's 44th move, it doesn't get the blunder ...g5? there into output at all (switching to MultiPV=6 it's ranked 5th with 157cp, best is ...Bd8 with 058, best one getting lower over time pondering, ...g5 higher from White's point of view) and its eval jumps to +- at once after the move is given in.