DEV Community: Dimos Michailidis

Yet another attempt to get better at chess

Dimos Michailidis — Mon, 15 Jul 2024 03:50:33 +0000

Do you recall that golden period when your chess rating skyrocketed? When you were effortlessly conquering opponents who seemed invincible? It felt like you could defeat anyone with just a little extra focus on the next game. Perhaps you even believed that your rating would continue to soar indefinitely. You may have even thought you were one of those rare few who effortlessly transitioned from beginner to expert.

Sadly, this is almost never the case. That phase I described usually marks the transition from amateur to club player. It is at this stage that you come to realize that improvement requires effort and dedication. You understand the importance of tactical training, endgame theory, and preparation for different openings, as well as the need for strategic thinking. Not only must you invest countless hours in honing these skills, but you must also develop the intuition to blend them harmoniously. In fact, becoming better at chess requires consistent study.

Every now and then, I tend to overlook this truth and delude myself into thinking there must be an easier path. It was during one of these moments of self-deception that I ended up creating the first version of this mobile app.

After a decade, I've made the decision to make better use of my limited time for chess. To achieve this, I've enabled the Zen mode in lichess and hidden all ratings. This allowed me to focus on enjoying the game rather than worrying about improvement.

But once again, instead of studying chess, I started playing partially-blindfold games. Lichess allows players to use disguised pieces, where their color is visible but their specific figures are not shown.

Without the visual cues of the chess pieces, I had to rely on memorizing each position. Although it took some time to adjust, I found that I now make fewer mistakes.
It took me a couple of weeks to be able to play with disguised pieces, and I imagine most club players would find it equally manageable.

However, I was still starving for a new challenge. Using JavaScript code in the browser's console, I changed all the pieces to white.

Concealing the color of the pieces encourages the mind to imagine the chessboard in more detail. We can aid this process by revealing the last move in the target square. The code below detects the most recent move and presents it in the center of the appropriate square. To ensure visibility, let's lessen the transparency of the pieces.

document.querySelectorAll("cg-board piece").forEach(piece => {
    piece.style.opacity = '0.5';
});

const kwdbElements = document.querySelectorAll("kwdb");
const kwdbContent = kwdbElements[kwdbElements.length - 1].innerHTML;
const lastMoveSquare = document.querySelector("cg-board square.last-move");

let textSpan = document.createElement('span');
textSpan.innerText = kwdbContent;
textSpan.style.color = 'black';
textSpan.style.fontWeight = 'bold';
textSpan.style.fontSize = `${lastMoveSquare.offsetWidth * 0.2}px`;

lastMoveSquare.style.display = 'flex';
lastMoveSquare.style.alignItems = 'center';
lastMoveSquare.style.justifyContent = 'center';

lastMoveSquare.appendChild(textSpan);

The result looks like this:

During a chess game, it is necessary to execute the code multiple times. To enable this, we can modify the code, install the tampermonkey browser extension, and configure it for the lichess web pages. Below is the complete tampermonkey script:

// ==UserScript==
// @name         Update Lichess Piece Classes and Display kwdb Content
// @namespace    http://tampermonkey.net/
// @version      0.9
// @description  Change piece classes to 'white' and display last kwdb content in last-move square
// @author       You
// @match        *://lichess.org/*
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    let lastKwdbContent = '';

    function main() {
        document.querySelectorAll("cg-board piece").forEach(piece => {
            let classNames = piece.className.split(' ');

            if (classNames.length > 0) {
                classNames[0] = 'white';
                piece.className = classNames.join(' ');
                piece.style.opacity = '0.5';
            }
        });

        const kwdbElements = document.querySelectorAll("kwdb");
        if (kwdbElements.length > 0) {
            const kwdbContent = kwdbElements[kwdbElements.length - 1].innerHTML;

            if (kwdbContent !== lastKwdbContent) {
                lastKwdbContent = kwdbContent;

                document.querySelectorAll("cg-board square").forEach(square => {
                    square.innerHTML = '';
                });

                const lastMoveSquare = document.querySelector("cg-board square.last-move");
                if (lastMoveSquare) {
                    let textSpan = document.createElement('span');
                    textSpan.innerText = kwdbContent;
                    textSpan.style.color = 'black';
                    textSpan.style.fontWeight = 'bold';
                    textSpan.style.fontSize = `${lastMoveSquare.offsetWidth * 0.2}px`;

                    lastMoveSquare.style.display = 'flex';
                    lastMoveSquare.style.alignItems = 'center';
                    lastMoveSquare.style.justifyContent = 'center';

                    lastMoveSquare.appendChild(textSpan);
                }
            }
        }
    }

    window.addEventListener('load', main);

    const observer = new MutationObserver(main);
    observer.observe(document.body, { childList: true, subtree: true });
})();

It works on my computer's Chrome and on my android's Firefox browser.

After playing thousands of games, I may finally be able to play fully-blindfold chess. Also, by paying attention to the displayed last move, especially on the square names, I may develop the skill to read chess books without needing a chessboard.

In the next decade, I should see significant improvement in my chess skills. By the time I reach my 50s, I should become a highly respected player in the chess community.

On the other hand, there is always a chance for me to participate physically in a chess tournament, where I will undoubtedly be defeated by players of all skill levels and get forced to face the truth one more time: there is no shortcut, becoming better at chess requires consistent study.

Is tail call optimization truly necessary?

Dimos Michailidis — Wed, 03 Jul 2024 09:16:56 +0000

When I was learning about a new functional programming language, one of the first things I would check would be if it supports tail call optimization. My thinking was that if this feature isn't available, then the tail-recursive functions could blow the stack.

Tail call optimization is a technique that makes recursive function calls efficient by eliminating the need for new stack frames. When the last expression of a function is a call to itself, this optimization reuses the current function's stack frame rather than creating a new one. So, it prevents stack overflow errors and improves performance.

Scala supports tail call optimization. However, it is not enabled by default. You need to use the @annotation.tailrec annotation to tell the compiler that a function should be optimized.

def factorial(n: Int): Int =
  @annotation.tailrec
  def go(m: Int, acc: Int): Int = m match
    case 0 => acc
    case _ => go(m - 1, m * acc)

  go(n, 1)

The above code is an implementation of the factorial function. The go function is tail-recursive because the last expression is a call to itself go(m - 1, m * acc). The @annotation.tailrec annotation ensures that the compiler will optimize this function.

Recently, I've started wondering whether tail call optimization is really necessary. Let me explain why. The majority of functional programming languages have collections whose elements can be processed lazily, without loading them all into memory at once. Among other things, we use these collections to process large datasets. For example, we treat the contents of a huge file as a lazy sequence of lines, and we perform operations like map, filter, fold, reduce, etc. to compute some result. Interestingly, we can generate these collections with methods like unfold or iterate. It seems to me that almost all tail-recursive functions can be rewritten using lazy collections.

def factorial(n: Int): Int =
    Iterator
      .iterate((n, 1)) { (m, acc) => (m - 1, m * acc) }
      .dropWhile { (m, _) => m > 0 }
      .next()
      ._2

In the code above, the iteration is managed without additional call-stack usage, and the memory footprint is low because the elements are created and consumed on the fly.

We can achieve similar functionality with other programming languages that follow the functional paradigm. So, the question remains: is tail call optimization truly necessary?

Primitive Type Differentiation in F#

Dimos Michailidis — Mon, 24 Jun 2024 13:48:21 +0000

One of the reasons why most F# developers love the language is the strength of its type system. As everybody expects from a statically typed language, the compiler won't let us mix apples and oranges. If we try to pass a string where an integer is expected, the compiler will tell us that we are doing something wrong.

But how can we differentiate between an integer that represents the number of apples and an integer that represents the number of oranges? To highlight this problem, let's phrase it in more explicit terms. Imagine that we have a function that accepts two parameters: the age of a person and the number of children that the person has. Both parameters are integers, but the meaning of the numbers is different. If we accidentally switch the order of the parameters, the compiler won't be able to help us, because both parameters have the same type.

In this article, I will try to list the available options for solving this problem.

Discriminated Unions

The discriminated union allows us to create a type that usually has multiple cases. But we can also use single-case discriminated unions for types that are semantically different from the built-in types.

type TB = B of int
type TC = C of int

let a = 1
let b = B 2
let c = C 3

let f (_: int) = None
let g (_: TB) = None
let h (_: TC) = None

In this example, the TB and TC types are different from the built-in int type. We can write f a, g b, and h c, but any other combination will result in a compilation error.

The single-case discriminated unions is a valid solution. The only drawback I can think of is that we have to wrap and unwrap the values frequently, which may lead to some boilerplate code.

Units of Measure

The units of measure were introduced in F# to ensure correctness in numeric computations involving different kinds of quantities. This feature though can be leveraged to solve the problem we are facing.

[<Measure>]
type mb

[<Measure>]
type mc

let a = 1
let b = 2<mb>
let c = 3<mc>

let f (_: int) = None
let g (_: int<mb>) = None
let h (_: int<mc>) = None

Again, we can write f a, g b, and h c, but any other combination will make the compiler unhappy.

Instead of wrapping and unwrapping the values (like in the discriminated unions case), here, we convert the values to the desired type. For example, to convert a to <mb>, we can multiply it by 1<mb> like this: a * 1<mb>. To convert b to int, we just need to call the int function: int b.

It seems to me that the units of measure is a more concise solution, but conceptually, they don't always fit for the problem we are trying to solve. When we deal with a unit of measure, we typically expect it to be a quantity we can perform specific numeric operations on. In the above example, we can multiply or divide b and c, but we can't add or subtract them. Although the compiler treats <mb> and <mc> as quantities, in reality, they are just labels.

Extended Units of Measure

Despite the occasional mismatch between the units of measure and the problem domain, the feature is quite powerful for numeric types. For non-numeric types, there is a library called FSharp.UMX.

#r "nuget: FSharp.UMX, 1.1.0"

open FSharp.UMX

[<Measure>]
type sb

[<Measure>]
type sc

let a = "a"
let b: string<sb> = %"b"
let c: string<sc> = %"c"

let f (_: string) = None
let g (_: string<sb>) = None
let h (_: string<sc>) = None

Like all the other solutions, we can write f a, g b, and h c, but any other combination will be rejected by the compiler.

To convert a to string<sb>, we annotate the type and use the % operator like this: let a1: string<sb> = %a. To convert b to string, we can call the string function.

If we evaluate the expression b = %"b" we will get true and [ b, 2 ] |> Map.ofList |> Map.find %"b" will return 2. This is good news. The extended units of measure seem to do a decent job when it comes to equality-based operations.

The downside is that they cannot be used in pattern matching.

Conclusion

You expected me to present a perfect solution, didn't you? Well, that's not going to happen. I tried to list the available options I am aware of, and I am sure people will continue arguing about which solution is the best, no matter what.

Despite not seeing a clear solution to this particular problem, I remain convinced that F# is one of the best programming languages out there. If you like typed functional programming, and you don't want to dive into the great depths of category theory, chances are you already love F#.