Saturday, December 11, 2021

srf - spaced repetition flashcards

I have been using srf to study Mandarin for about 6 months now, with a selection of decks imported from anki, and cards I have created myself. 

My study time is better regulated and I am making better progress than when I was studying with anki

The difference is the scheduling algorithm. The scheduler in srf regulates new cards automatically, to maintain a target study time per day and sorts due cards differently, allowing good progress even with a large backlog of due cards (e.g. after not studying for a few days).

Initial development of srf is now complete. Rate of change is slowed. The user interface, particularly for editing content, remains a bit crude but adequate. Lately, I spend most of my time studying and very little developing the program.

I was reluctant to develop a new program. It took a lot of time away from study. But the limitations of the anki scheduler were too frustrating and it is now clear that a better scheduler makes a big difference to progress. From a technical perspective, the differences are subtle and simple but practically they make a big difference.

The essential differences are:

  • present cards with shorter interval before cards with longer interval
  • automatically regulate new cards based on past and future workload

Presenting cards with shorter intervals first makes a big difference when working through a backlog. Anki presents cards in the order they were due, regardless of interval. The difference is subtle but important.

With a large backlog in Anki, the backlog effectively blocks review of cards with shorter intervals. Unfamiliar / difficult cards are not seen as soon as they should be, defeating learning. With a large enough backlog, it is practically impossible to learn: one churns through a large number of cards without making progress because it is too long between reviews.

The problem is exacerbated by anki introducing more new cards every day, despite the backlog. It is possible to change the number of new cards per day manually but paying attention to this takes attention away from studying.

The scheduler in srf prioritizes the cards you are learning (with shorter intervals) over the backlogged cards. Thus, one can learn despite the backlog and that learning is the way to clear the backlog. And while there is an excessive backlog, srf does not introduce new cards, so gradually, reliably, the backlog is cleared. When it is cleared, new cards are introduced again.

With these changes, study time per day is more consistent: varying closely around configured target study time per day. And progress is better when one is not overloaded.

libinput - touchpad acceleration - piecewise linear profile

I have implemented a piecewise linear acceleration profile for touchpad in a fork of libinput.

The mapping function is defined by an array of points: (speed, factor), which must be sorted in order of increasing speed. Between the points, factor is determined by linear interpolation.

A single point gives a fixed acceleration factor, like the libinput flat profile.

Two points give a single, linear slope, clipped at the upper and lower input speeds. But the clipping is irrelevant if the speeds of the two points are sufficiently low (e.g. 0) and high respectively, in which case all inputs will be at speeds between the points.

Factor
^
|                   _________
|                 /
|                /
|               /
|-----------/
|
+-----------------------------------------------> Speed

More complex curves can be approximated by more points. With enough points, any of the profiles in the old X.org server can be approximated.

At the moment, configuration parameters are hard coded, because I haven't figured out how to add configuration parameters and because using new parameters would require changing code outside libinput (e.g. the X or Wayland libinput drivers).

One of the limitations of libinput is that the only means of configuration is via the API. As a result, to add new configuration parameters requires modification of both the libinput library and whatever software (e.g. Wayland compositor, xf86-input-libinput, etc.) calls it. I may add configuration via environment variable to work around this limitation but in the meantime, as you will have to compile and install this version anyway, it is almost as easy to edit the source as a separate configuration file or environment variable.

See the touchpad-pl branch of this fork of libinput.

To try this profile for your touchpad:

$ git clone https://github.com/ig3/libinput.git
$ cd libinput
$ git checkout touchpad-pl
$ meson --prefix=/usr builddir/
$ ninja -C builddir/
$ sudu ninja -C builddir/ install

This is working for me on Debian 11 with xfce desktop. I haven't tried a system running Wayland.

To change the profile, edit src/filter-touchpad-pl.c. The parameters are in function touchpad_accel_profile().

To test:

$ sudu libinput debug-events

Labels