Vibe Coding

[BertTuyt]

Let’s face it, AI is improving at coding incredibly rapidly. It’s a bit like Moore’s law, but now every 18 weeks instead of 18 months.

Good remark Rein.
To often we focus on the flaws of a new technology/development.
But neglect the speed in which it is improving.
Not sure if it is 18 weeks, but certainly next year we will have all (slightly) changed verdict.

Bert

[MichelG]

I think Rein's estimate of doubling every 18 weeks is fairly good on the spot.

The current AI compared to that in februari this year is already incredable. Recursive self improvement is on the horizon in my opinion, where AI will write the next generation of AI's. (and do that in a loop)

Only limit seems to be the amount of electricity and chips the companies can claim for themselfs.

[Rein Halbersma]

I think Rein's estimate of doubling every 18 weeks is fairly good on the spot.

The current AI compared to that in februari this year is already incredable. Recursive self improvement is on the horizon in my opinion, where AI will write the next generation of AI's. (and do that in a loop)

Only limit seems to be the amount of electricity and chips the companies can claim for themselfs.

I’m late to the game. Over on Talkchess I codeveloped 100% symmetry-reduced indexing for endgame databases (May). I had the idea to also codevelop an identical Qt GUI for Kingsrow-Hub so that Ed could forget about the Win32 API. Alas, Gijsbert beat me to it by a week. Currently I am sitting on the couch with my iPad, using Claude Code Cloud and ChatGPT Codex Cloud to babysit my GitHub C++ projects and do all kinds of refactoring and documentation (that I had neglected for a decade).

[BertTuyt]

Rein, this was exactly my first (bigger) Codex project, a Qt implementation of the Damage GUI.

See screenshot, with the Kingsrow hub engine...

Bert

[Joost Buijs]

I decided to take the easy route too. Although I already programmed a large part of a GUI with MFC it has two drawbacks, it looks a bit old-fashioned, and it's impossible to port it to Linux. So I decided to use QT as the primary toolbox (another option would have been wxWidgets).

In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.

The board looks nice too, actually this was most of the work because with the QT drawing function it kept looking ugly, so I decided to let Codex implement it with OpenGL.

Too bad, the forum doesn't allow me to add another screenshot, I hope they will fix this some day.

Joost

[Rein Halbersma]

In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.

Why would you add a proprietary protocol instead of HUB when the latter is also a breeze to get to work with Codex?

[Joost Buijs]

In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.

Why would you add a proprietary protocol instead of HUB when the latter is also a breeze to get to work with Codex?

HUB clearly has more overhead than a binary protocol. While this is not a problem for games with 'normal' time controls, it becomes noticeable in very fast games. Of course, completely integrating the engine into the GUI is an even better solution.

[BertTuyt]

As Im "studying" the history of computer draughts, I wanted to know more about Tunstall compression for endgame databases (as used by some of the Kingsrow databases). For this reason I asked Codex to add this type of compression to my database-generator. To measure the effect of several compression design choices, a dialog with options was added. see screenshots.

In the end Codex also made a report for this architecture.


Bert

[BertTuyt]

To better understand what was "cooking" under the surface Codex also developed an EGDB Explorer, see some screenshots.

Bert

[BertTuyt]

Today, I was playing around with MCTS.
A known (so far unsolved) characteristic of MCTS is that it hardly recognizes combination traps.
Also this time the MCTS version suffered from this short sight in a game against Kingsrow.
In this position white has played 29-23? and it is now black (Kingsrow turn).

The response 15-20 24x4 13-18 4x13 18x47 13x27 7-11 16x18 17-22 28x17 8-12 18x7 2x31 36x27 47x35, see the final board position.

Bert

[MichelG]

I think the premise for mcts is wrong here.

My idea is that the default mcts algorithm expects that the scores follow a normal distribution, but here that is not the case.

I suspect mcts may work if you have a good estimator of the error distribution. And this will need to depend on the position.

So maybe have a neural net predict not only the expected value, but also the distribution characteristics, for example the trap chance.

So if a trap is likely, mcts will be forced to explore that node rather than accept its value.

Note that is also possible to detect a good fraction of traps by a manually written trap detector.

[BertTuyt]

Michel, you are right!
And it is not unlikely that in the end nothing will beat alpha-beta (at least for 10x10 international draughts).
But I wanted to understand MCTS somewhat better, and as Codex helped me to write the routines, I could do a quick test.
So not sure I want to spent much more energy, but for a Saturday experiment it was fun....

Bert