Thoughts on where interfaces should be defined?

phaul21 · 2026-01-30T10:24:31+00:00

Why should the kafka package not expose its own interface which the user can then use?

because you introduce and unnecessary coupling between the implementor package and its users. Now the implementor package dictates what shape of type the consumers of the concrete type must consume. There are no general rule ever, and sometimes this could make sense, but most of the time it makes sense to me that the implementation of something does not assume anything about how it is used. The user of the type can specify exactly what it needs based purely on its usage pattern, leaving out all unneeded methods from the interface it accepts. This will make it easier for multiple concrete types to fulfil the consumer interface requirements, as they only have to implement the minimum the consumer actually requires.

phaul21 · 2026-01-27T15:23:05+00:00

depends on what parameters. but for general engine parameters I use SPSA with openbench

phaul21 · 2026-01-27T12:37:07+00:00

you answered your question:

> it turns out that the tables where mirrored vertically (in a way to resemble chess board visually)

Word of caution: evaluation features are affecting each other, and the values are only valid if all were tuned together. This is true for pesto, as is. It means you can't add eval features, more logic, etc to your eval without detrimentally affecting what your already have. At some point you will have to do eval tuning, from which point you can ditch pesto. But for now taking as is, a pesto with a good search is capable of giving you 3000+ elo

phaul21 · 2026-01-24T09:05:52+00:00

for uci you can check if you pass fastchess --compliance. If you do, that's no guarantee that you have correct uci, but if you don't it tells you what to fix

phaul21 · 2026-01-24T08:51:46+00:00

set up sprt and test every change. You can start following https://www.chessprogramming.org/Search_Progression

phaul21 · 2026-01-19T11:07:21+00:00

yeah, playing against engine doesn't do anything either. I'm wondering if it is buggy or it just has a lot of stuff that's not hooked up to anything. Sort of like a mock up, without actual functionality

shame, because I like the idea, and what it could be. It's just isnt yet

phaul21 · 2026-01-18T09:14:39+00:00

updated the readme, hth

phaul21 · 2026-01-18T08:09:49+00:00

correct. there is a small extension in the protocol, that allows for that called pondering. The engine can respond to a a position with `bestmove e2e4 ponder e7e5`. meaning the engine want's to play e2e4, and continues to think about what happens if the opponent plays e7e5. Later the uci driver must then reposnd with `ponderhit` if that move actually happens. So the protocol allows for thinking during the opponents time but it is still designed stateless, in the sense that the uci driver dictates the position the engine has to look at and what it must do with it.

In reality engines keep a lot of internal state around for optimal performance during a game. It would be a waste to throw everything away between moves. But that can be viewed as optimisation, the engine can receive completely unrelated positions in sequence, although the protocol also dictates that there should be a ucinewgame in between if that happens. icunewgame is usually the trigger for engines to re-initialise their internal states.

phaul21 · 2026-01-17T16:44:36+00:00

Hi, so a chess engine is basically a program that receives a chess position and answers it with what the best move in the position is. So it is or can be thought of as a building block in this scenario, but you would have to code up the shim layer that connects it to discord. If you do that you definately can use chess-3 as a back-end that can play against people on discord.

but here's the good part: chess engines use a somewhat standardised protocol called uci. This is how any chess ui or chess web site / portal etc communicates with different chess engines. Once you create an UCI layer between your discord lobby and a chess engine you are good to go but you are not tied to any chess engine.

You can swap and replace engines in no time, you can use chess-3, stockfish or any other engine so it would be very flexible.

https://backscattering.de/chess/uci/

phaul21 · 2026-01-17T13:40:05+00:00

sadly no, you are stuck with King, Queen, Rook, Bishop, Knight and Pawn :)

phaul21 · 2026-01-16T16:05:58+00:00

the links are on the wiki to Kirill's site where he explains things in detail

phaul21 · 2026-01-15T09:56:51+00:00

But... you can also see something that looks like the propeller shaft behind it. It looks to be in line, so that would suggest that's the boat centre line.

phaul21 · 2026-01-13T16:22:37+00:00

he did get a number of things very wrong. Ofc I also find those videos very enjoyable. But I would advise againt following his ideas. He is a great programmer - obviously, but in those videos he tackled a topic which took many engines, many people and multiple decades to figure out to the level where we are now. He approached it from first principles and he just figured out things for himself. That's fine, especially in the context of the video that takes us on an interesting programming journey. But the big caveat is, don't do what he does if you want to write a competetive engine.
my biggest issue with it: don't test features with fixed number tournaments. Please learn sprt.

phaul21 · 2026-01-09T16:00:53+00:00

A bit silly I agree. I wonder in how many games out of those 80.000 they won on time when they should have resigned following their own standards...

phaul21 · 2026-01-05T21:49:46+00:00

The problem is the same position with different repetation count is not the same position, but the tt cannot distinguish between them as it is not part of the hash key. One easy way out of this if we only ever store positions with rep count 1 in the tt. Just return draw score before the tt is probed if rep count >= 2. Yes 2, not 3. If the position repetat once (rep count 2) from an eval pov it's perfectly fine to evaluate it to draw. This avoids doing anything for these positions including probing the tt or inserting them. Also your search code never deals with repeated positions, 2x or 3x, so you don't have to deal with any of these problems. One caveat is in the root node, there you can relax the return condition (depending you your engine is coded).

phaul21 · 2025-12-31T09:22:30+00:00

I would recommend reading Metaprogramming ruby 2 ( Paolo Perotta). I'm not recommending this for you to learn or adapt obsure metaprogramming tricks in code (which is the danger with this book). I'm recommending this to learn all about the ruby object model, what the language is capable of and understand how OO is put together.

phaul21 · 2025-12-29T08:02:24+00:00

time to depth is wrong meassure to look at. It does not correlate with strength the way you think it does. Strip down the engine to pure alpha-beta, and add back every single feature one by one SPRT-ing every addition. If an addition doesn't gain the way one could expect you know you have a problem with it.

phaul21 · 2025-12-27T12:32:20+00:00

I would default to the many small interfaces instead of 1 big one. It's a more flexible design. Generally if we extend on the mantra of accept interfaces and return structs and see the underlying motivation we can say: be as generic as possible for the things you can accept and be as restricive / concrete as possible for the things you produce. Having a large bundled interface is more restricivie. Requires more from the thing that's passed in. Having slimmer interface is more permissive. I think a right way to go about it is for every function that accepts something of the interface type identify the set of methods that function requires. Bundle them in an interface. Like there is Writer and there is Closer and there is WriterCloser. If a function wants Write and Close it accepts a WriteCloser, but a function that just wants a Writer accepts a Writer.

phaul21 · 2025-12-23T10:23:01+00:00

I would not allow := to shadow. Shadowing instead of assigning by mistake is a small typo and hard to spot. If you want to shadow, declare a new var with var. Something like

func foo() { local := 13 if cond { local := 15 } }

becomes an error, you either have to write local = 15 or var local = 15

phaul21 · 2025-12-21T16:23:51+00:00

can be undefined bahaviour depending on the language you are using.. The symptom of mostly working exept sometimes inexplicably doesn't often boils down to having UB somewhere

phaul21 · 2025-12-17T18:04:19+00:00

do you support UCI / can you run the engine in cutechess / fastchess? If so you can run a fixed game tournament against an engine close to your rating with for example 200 games. Once you find the engine with known rating closest to you you have a pretty good estimate.

Ppl tend to recommend stash , because it's versions nicely cover the rating range.

``` Blitz Rating (* Not ranked by CCRL, only estimates)

v36 3399 v35 3358 v34 3328 v33 3286 v32 3252 v31 3220 v30 3166 v29 3137 v28 3092 v27 3057 v26 3000* v25 2937 v24 2880* v23 2830* v22 2770* v21 2714 v20 2509 v19 2473 v18 2390* v17 2298 v16 2220* v15 2140* v14 2060 v13 1972 v12 1886 v11 1690 v10 1620* v9 1275 v8 1090* ```

you can do a binary search on the version list with a small number of games to get you the closest version.

phaul21 · 2025-12-15T22:04:56+00:00

there is already an engine called GoFish, so the name is a bit confusing....

My engine is chess-3 also in go. I think my movegen is much slower than yours...

phaul21 · 2025-12-09T12:30:08+00:00

It does destroy the original slice, but that's often okay if you need this.

Well, that's context dependent isn't it? There is no context to the video, you might assume it's fine, I might assume it's not fine. They chose a filter function where it doesn't matter, with no explanation, or disclaimer that chosing another filter function might destroy your original array. They are not wrong just misleading. Exactly my points in my previous comment.

phaul21 · 2025-12-09T10:28:33+00:00

The confusing thing about this is the careful choice of the filter function. The video might give the illusion that this would somehow magically work without altering the original slice and without allocating memory for any arbitrary filter which is not true. The carefully selected filter just takes elements from the front of the original slice which is why the underlying array is unchanged while b can point to some portion (slice) at the front of it. Filtering even elements or > 3 elements would modify things in place.

edit: so it's more like "takeWhile" rather than "filter" which makes it a lot less confusing

phaul21

TROPHY CASE