Command-Line Interface

Tomat is controlled through a command-line interface (CLI), which communicates with the background daemon. Below is a summary of the available commands.²

Notifications and Sound Alerts

Tomat comes with built-in support for desktop notifications (using notify-rust), which means that it will integrate nicely with your desktop environment’s notification system as long as you have a notification daemon running, such as dunst or mako.

Sound alerts are also supported and compiled directly into the binary, which means that you don’t need to install any additional dependencies to get sound alerts working. By default, Tomat uses simple beep sounds:

Integrations

All of the above just gets you set up with the daemon and CLI client, but the goal of Tomat, as I mentioned, is to use it with status bars. Configuring that is the final piece of the puzzle. A full integration guide is available in the repo, but here I summarize the steps needed for Waybar.

Waybar

Waybar is a highly configurable status bar for Wayland window managers, and it is my current status bar of choice. Tomat was built with waybar integration in mind, so setting it up is quite straightforward.

In your waybar configuration file (typically ~/.config/waybar/config), you can add a custom module for Tomat like this:

{
  "modules-right": ["custom/tomat"],
  "custom/tomat": {
    "exec": "tomat status",
    "interval": 1,
    "return-type": "json",
    "format": "{text}",
    "tooltip": true,
    "on-click": "tomat toggle",
    "on-click-right": "tomat skip"
  }
}

This configuration will add a Tomat module to the right side of your Waybar, which will display the current status of the Pomodoro timer. Clicking on the module will toggle the timer (start/pause), and right-clicking will skip to the next session (work/break).

In my own setup, it looks like Figure 3.

CSS Styling

You can also style the module based on the timer state using CSS classes. For example, you can add the following to your Waybar CSS file (typically ~/.config/waybar/style.css):

#custom-tomat {
  padding: 0 10px;
  margin: 0 5px;
  border-radius: 5px;
}

#custom-tomat.work {
  background-color: #ff6b6b;
  color: #ffffff;
}

#custom-tomat.work-paused {
  background-color: #ff9999;
  color: #ffffff;
}

Hooks

A recent addition to Tomat³ is the support for event hooks, which allow users to run commands on state changes (e.g., when a Pomodoro session starts or ends). This means that you can integrate Tomat into more complex workflows, such as

• locking your screen when a break starts,
• pausing or even changing your music when a work session starts,
• dimming your screen during breaks, or
• opening up a task management application (e.g. taskwarrior) when a work session starts.

Hooks can only be configured through a configuration file (at ~/.config/tomat/config.toml by default), and an example configuration with hooks looks like this:

# Example: Dim screen when timer is paused
[hooks.on_pause]
cmd = "/home/user/scripts/dim-screen.sh"
cwd = "/home/user"
timeout = 3

# Example: Pause music during work sessions
[hooks.on_work_start]
cmd = "playerctl"
args = ["pause"]
timeout = 2

Redesigned Color System

The biggest change in this release is a complete redesign of how colors work in Moloch. I have become increasingly frustrated with the previous system for a couple of reasons:

• The colors of the text, its background, and the respective colors in the frame titles were all linked together, which for instance meant that the frame title background color had to be the same as the text color, which limited customization options.
• Switching between light and dark modes was toggled by background=dark, which both felt unintuitive (since it actually inverted all the colors) and also meant that the colors in the primary palette had to make sense if inverted, which again limited flexibility.
• Because the light and dark switching was so basic, it meant that alert and example colors needed to be the same for both light and dark variants, but typically one wants to have brighter colors when the background is dark, and vice versa.
• Customizing the colors was quite difficult. Users would have to modify colors manually using Beamer’s \setbeamercolor{}, with fg and bg options set correctly. I didn’t really have any problem with that, but it could not allow for granular control of light and dark themes. And more problematically, colors were linked via use options, but these do not automatically refresh if the color linked is updated, which meant that users would have to add multiple lines just to modify the alert color everywhere it was used.
• Color themes lived in their own files and were added via \usecolortheme{moloch-tomorrow} etc, which was starting to feel a bit hard to manage given that we might want to eventually support a large variety of color themes.

The new color system now promises to fix all of these issues and is activated via a new macro \molochcolors{}. In the next sections I’ll try to outline how it works.

\molochcolors{variant=light}
\molochcolors{variant=dark}

\molochcolors{theme=tomorrow}

\molochcolors{theme=tomorrow, variant=dark}

\usetheme[
  colortheme=tomorrow,
  colortheme variant=dark
]{moloch}

\molochcolors{
  alerted text=red,
  progressbar fg=blue
}

\molochcolors{
  light/normal text fg=black,
  light/frametitle bg=white
}

% Use theme colors in TikZ graphics
\begin{tikzpicture}
  \node[fill=mAlertFg, text=mNormaltextBg] {Alert!};
\end{tikzpicture}

% Or in text
This is \textcolor{mExampleFg}{colored text} using theme colors.

New Color Themes

As a result of the redesigned color system, it is now much easier to add new color themes. And in this release, I’ve added two new themes:

• Catppuccin, which is based on the popular Catppuccin color palette
• Paper, a high-contrast theme that uses black, white, greys, and a set of colors based on Stephen Few’s book Show Me the Numbers (Few 2004).

\usetheme[colortheme=catppuccin]{moloch}

\usetheme[colortheme=paper, colortheme variant=light]{moloch}

Improved Existing Themes

I’ve also made a few changes to the dark variants of the existing themes to take advantage of the new color system. In general, I do not find the use of a white (or very light) frame title background on dark themes to be appealing, so I have adjusted these to use the same background color as the main text area or a slightly darker shade.

New Documentation Website

The Moloch documentation is now available as both a PDF manual and an interactive website at moloch.ink. Even if PDF documentation seems natural for LaTeX packages, I’ve long felt that it is cumbersome to navigate, especially since users often have to scroll through many pages to find what they need and search functionality is limited compared to a website. Not to mention that PDFs are not exactly mobile-friendly.

I’ve been meaning to set this up for a while, but haven’t really figured out a good way to do it. Much of the documentation for the implementation details of Moloch is written inside the .dtx files, which is great for keeping the documentation close to the code, but not so great for building a website.

I realized, however, that I could just keep the documentation in LaTeX syntax there, and just have Pandoc convert it to Markdown, which can then be used as source files for a Quarto website, which I can thereafter render into both HTML and PDF² formats.

The documentation is built with Quarto, which means:

• Always up-to-date: Documentation is generated directly from the theme’s source code
• Interactive examples: Live code samples you can copy and modify
• Searchable: Find what you need quickly
• Beautiful presentation: Clean, modern interface with syntax highlighting
• Accessible anywhere: Read on any device without downloading PDFs

The PDF manual is still available for offline reading, but the website offers a much better browsing experience with its table of contents, search functionality, and responsive design.

Refined Itemized List Styling

In version 1.1.0, Moloch introduced a refreshed list styling that used new symbols for itemize environments. Instead of using filled circle, circle, smaller circle, I switched to filled circle, filled square, and filled triangle, which I found to be more visually distinct and appealing.

However, there were still some issues with the design³. In particular, the triangle and circles I used were based on math fonts, which sometimes led to inconsistent sizing and alignment issues that could depend on the compiler and font setup.

Therefore in this release, the symbols are now all drawn using TikZ (or PGF primitives, to be precise), which ensures consistent sizing and alignment across different setups.

Increased Line Widths for the Progress Bar

The progress bars for Moloch (at section pages by default), have had quite a thin line width⁴ that was often hard to see. So in this release, I’ve increased it from 0.4pt to 1.0pt, which should make it more visible without being too obtrusive. I hope that most users will find this change beneficial, and know that you can otherwise easily customize it to your liking:

\molochset{progressbar linewidth=0.4pt}

The above line would restore the previous thin line width if desired.

The title separator line on the title page was also increased, but only marginally from 0.4pt to 0.5pt, given that it has only decorative purpose, but I am considering increasing it further in a future release.

The New C++ Library

All of the above has now been implemented. I’ve decoupled the C++ parts of qualpalr into a separate library called Qualpal, which lives in its own repository on GitHub.

The new C++ library is designed to be lean and carries no other dependencies than the C++ standard library, although there is support for multi-threading via OpenMP (if available).

The functionality of the package is mostly concentrated in the Qualpal class, which uses a builder-type interface to customize palette generation. Here’s an example, where we construct a five-color palette from part of the hue-saturation-lightness (HSL) color space as input.

#include <qualpal.h>

using namespace qualpal;

Qualpal qp;
qp.setInputColorspace({ -170, 60 }, { 0, 0.7 }, { 0.2, 0.8 });
auto colorspace_pal = qp.generate(5);

In the next example, we change to using one of the built-in color palettes, in this case Set2 from ColorBrewer (Harrower and Brewer 2003) as input, and adapting the color palette to the color vision deficiency type deuteranomaly of severity 0.7 (70%).

qp.setInputPalette("ColorBrewer:Set2").setCvd({ { "deutan", 0.7 } });
auto cvd_pal = qp.generate(4);

Extensive documentation, including a complete API reference, is available at jolars.github.io/qualpal.

The R Package (qualpalr)

The R package, qualpalr, now uses the C++ library as a backend, and new releases of the C++ library are semi-automatically integrated into the R package. Only the R-specific parts remain in the qualpalr package, which means that development is now focused on the C++ library directly.

The main major change of the package is a switch in the character method of the main function of the package, qualpal(), which now assumes that the second argument is the name of a built-in palette. But backwards compatibility with the old behavior¹ is maintained by selectively handling the previous set of allowed input.

In the following example, we generate a 4-color palette by picking colors from Vermeer’s Girl with a Pearl Earring. This example also showcases a new feature that allows users to optimize the palette against a given background color (in this case white).

library(qualpalr)
pal <- qualpal(4, "Vermeer:PearlEarring", bg = "white")
pal$hex

[1] "#80a0c7" "#100f14" "#a65141" "#b1934a"

The default plot method shows a multi-dimensional scaling (MDS) plot of the colors in the color difference metric space, which gives an idea of how well-separated the colors are.

plot(pal)

The CLI Tool

As a result of refactoring the package into a pure C++ library, it was also straightforward to create a command-line interface (CLI) tool for Qualpal, relying on the excellent CLI11 library. This CLI tool is only available from source as of now, but I hope it will be packaged for various Linux distributions in the future.

Here’s an example of generating a 5-color palette from the HSL colorspace:

qualpal -n 5 -i colorspace "0:360" "0.4:0.8" "0.3:0.7"

Please see the instructions in the README for how to build and use the CLI tool.

The Web App

One of the major motivations for refactoring Qualpal into a C++ library was to make it possible to serve it as a static web app by compiling the C++ code to WebAssembly (WASM). Although I love how easy it is to turn R code into web apps using Shiny, I have always been bothered by the hoops you have to jump through to deploy and manage Shiny apps, whereas the new Qualpal web app is hosted on GitHub pages as a static site and is served directly upon successful builds from GitHub Actions.

Running a server instance is also not free, so hosting this as a static web app means significant cost savings and automatically scales to any number of users.

Normalization

Like most people who have been introduced to the lasso, I quickly learned that you need to normalize the features () before fitting the model since their scales affect the resulting coefficients. The larger the scale (as measured in variance or, equivalently, standard deviation), the smaller the effect of regularization becomes. The reason for this is that the coefficient can be smaller for an equivalent effect on the predicted response.

Many sources, including one of the first papers on the lasso by Tibshirani (1996), recommend that you standardize your data, which means centering and scaling each feature by its mean and standard deviation. If your features are normally distributed, this practice speaks to intuition: each feature’s distribution can be described fully by its mean and standard deviation, so standardizing it will create a standard normal distribution, ensuring that the effects of regularization will be fair across the full set of features. After having standardized, most people will eventually want to return the coefficients to the original scales of the features, but doing so is simple.

The problem with the procedure, however, is that not all features are normally distributed. What, for instance, should we do about binary features?¹ At this point you may wonder if this matters in practice, and the answer is that it does. Consider Figure 1, which shows the lasso paths for four different data sets and under two types of normalization schemes: standardization and max–abs normalization. The latter of these scales the data to lie in which preserves sparsity for binary data but makes it sensitive to outliers.

The point of this figure is to illustrate that the choice of normalization matters in a critical way, leading to different models and affecting the conclusions you draw from it.

The Paper

The paper that we have written about this is titled The Choice of Normalization Influences Shrinkage in Regularized Regression (Larsson and Wallin 2025) and is now out on arXiv². In it, we begin to address this apparent knowledge gap by studying this interplay between normalization and regularization in lasso, ridge, and elastic net regression. Our focus is on the case of binary features and mixes of binary and normally distributed features.

Our first result is that the class balance (proportion of ones versus zeros³) of the binary feature directly influences shrinkage. For both ridge and the lasso, the effect is basically that the more imbalanced the feature is, the more the coefficient will be shrunk by the estimator. Note that this effect is a by-product of regularization and does not, for instance, occur with standard linear regression.

Interestingly, this effect from a given normalization scheme depends directly on which regularization method is used, which means that to mitigate this effect you will need different normalization strategies depending on which type of penalty we use in our model.

To study this more formally, we introduce a parameterization for scaling a feature, given by where is the class balance of the th feature. When , there would for instance be no scaling for the binary feature (as in max–abs normalization). If , we would scale by the standard deviation of the feature—as in standardization. If , then we would instead scale by its variance.

Throughout the paper we assume that our data comes from a linear model where is the response, is the matrix of features, and is the vector of errors, which we assume to be identically and independently distributed and, for many of our results, normally distributed.

These are classical and mostly non-controversial assumptions in this field. But we also make a strong⁴ assumption, assuming that the features are orthogonal to one another, so that is some diagonal matrix. In this case, the elastic net estimator admits a closed-form expression, which means that we can study the effect of varying the scaling parameter .

Bias–Variance Trade-Offs

What we show in our paper is that there is a bias–variance trade-off with respect to this normalization parameter, . See Figure 2 for a simple example of this, where we consider a two-dimensional problem with one binary feature and one normally distributed feature. We have kept the true coefficients fixed at one for each of the features, and only vary : the class balance (proportion of ones and zeros in the binary feature). We consider the cases (no scaling), (standard deviation scaling), and (variance scaling) and we see that there are only two settings that seem to mitigate this class-balance bias: in ridge and lasso regression, respectively, these are and .

This figure also shows that this type of variance scaling, while reducing bias, increases variance in the estimates. This is not particularly surprising, however, since an unbalanced feature necessarily provides less information than a balanced one.

Figure 2 is purely an empirical result from a simulation, but under our particular assumptions we can work out this bias–variance trade-off exactly. In Figure 3, we have done exactly that for the lasso. (The paper includes results for ridge regression and the elastic net as well.) In this figure, represents the standard deviation of the error term in our data—the measurement noise. And what we can deduce from this figure is that this bias–variance trade-off very much depends on the noise level. If the signal is strong, then we can reduce the mean-squared error (MSE) by employing this variance scaling, but if the problem is noisier, we do better (in a prediction error sense) by using standardization instead.

To study if and how this choice of the normalization parameter might impact predictive performance in a real-data setting, we’ve also conducted experiments where we have varied both as well as the regularization strength () for lasso and ridge models, recording hold-out error for each fit. The results are shown in Figure 4, from which it is evident that the optimal value for is data-dependent, although standardization might make for a good default since it mitigates some of the class-balance bias without imposing too much variance.

Mixed Data

We spend a substantial amount of time in the paper to also discuss the problem of mixed data: data sets that include both binary and continuous features, although in the paper we restrict ourselves to study the case of normal features.

When dealing with regularized methods, this scenario imposes a tricky question, namely: how do we put binary and continuous features on the same scale? This question is critical because, as we have already seen, shrinkage from the lasso and company will depend directly on how we choose to normalize the features to deal with this.

To put this problem into perspective, let’s say that we standardize all our features and also assume that our binary features are perfectly balanced (so that for all corresponding to a binary features). If all of this holds, then it actually turns out that the coefficients of the binary and normal features will be regularized by the same amount if flipping the binary feature from 0 to 1 corresponds to a change of one standard deviation in the normal feature. In other words, our choice of normalization imposes this particular choice of what a one-unit change in terms of a binary feature should be equivalent to in terms of a normal feature (or vice versa).

You may or may not think this is a reasonable approach to scale binary and normal features relative to one another, but I would be surprised if you thought that this was reasonable for all binary features, given that they often represent entirely different things. Some features are indeed truly binary in nature, but many are just too distant points on the same continuum. It is true that some binary features come from dichotomization of continuous variables, in which case you should be able to base your choice of scaling on the original continuous feature’s scale, but even in this case it is not the case that there is one single way to dichotomize a variable that ensures that they are put on the same scale.⁵

The particular relative scaling imposed by standardization was actually the subject of a paper by Gelman (2008), although tackled from the perspective of presenting standardized coefficients in standard regression model settings. In this paper, he argues that the default of equating a one-unit change in a binary feature to a one-standard deviation change in the normal feature is typically not a good default and advocated for instead using two standard deviations. In our paper, we adopt this setting, but here I want to stress that there is nothing critical in our results that depend on this. But we want to stress that this choice should if possible be done actively.

Another interesting part about this is that if we switch normalization method to, say, maximum–absolute value normalization, then this relationship changes.⁶ With another normalization method comes another relative scaling of binary and normal features. So, the choice of normalization does not just lead to a different behavior with respect to class balance, it also leads to an implicit weighting of binary and normal features relative to one another.

Moloch

This has now (since some months back actually) led me to fork Metropolis to try to fix these outstanding issues. I call the new theme Moloch (which is likely familiar to you if you know your Metropolis). The original design is still pretty much intact save for a few tweaks that I will summarize in Section 3, which overall bring the theme closer to normal beamer behavior. The code for the theme has also been simplified and made more robust. Metropolis, for instance, made much use of \patchcmd from the etoolbox package to patch beamer theme internals in order to support modifications to, for instance, frame titles. This was what lead the theme to break in the first place as beamer introduced changes in these commands and I have thus opted to remove all this kind of patching in favor of relying on standard functionality from the beamer theme instead.

In fact, it is now possible to change the title format directly through beamer, for instance by calling \setbeamertemplate{frametitle}{\MakeUppercase{\insertframetitle}} to make titles upper-case.¹

This comes at the price of sacrificing some features, such as toggling title formatting between uppercase, small caps, and regular text. But, as the Metropolis documentation itself noted,² these modifications were problematic in the first place and I therefore think that their removal is on the whole a good thing.

I’ve also removed the pgfplots theme that was included in Metropolis. I don’t mind the theme per se, but I don’t think it belongs in a general-purpose beamer theme.

Getting Started

The design of the theme does not stray far from the original Metropolis design (and will not do so in the future either). Below is a simple example of a few slides of the theme.

Moloch is now on CTAN, so you can install it with the TeXLive package manager by calling the following line of code:

tlmgr install moloch

If you have TeXLive 2024 (or later), then Moloch is already included in the distribution and you don’t have to do anything to install it.

Using the theme is as simple as using any other beamer theme. Here is a simple example:

\documentclass{beamer}

\usetheme{moloch}

\title{Your Title}
\author{Your Name}
\institute{Your Institute}
\date{\today}

\begin{document}
  \maketitle
  \section{First Section}
  \begin{frame}
    \frametitle{First Frame}
    Hello, world!
  \end{frame}
\end{document}

See the package documentation to learn more about the theme and its various options. If you’re used to Metropolis, then you mostly need to know that \metroset has been replaced by \molochset and that some things are no longer supported, which is precisely what we’ll dig into in the next section!

Changes

I’ve tried to outline the main changes that I can think of in the following sections.

\setbeamertemplate{page number in head/foot}[appendixframenumber]

\documentclass[10pt]{beamer}

\usetheme{moloch}

\title{Title}
\subtitle{Subtitle}
\author{Author}
\institute{Institute}
\date{\today}
\titlegraphic{\hfill\includegraphics[height=2cm]{logo.pdf}}

\begin{document}
  \maketitle
\end{document}

\usepackage{fontspec}

\setsansfont[
  ItalicFont={Fira Sans Light Italic},
  BoldFont={Fira Sans},
  BoldItalicFont={Fira Sans Italic}
]{Fira Sans Light}
\setmonofont[BoldFont={Fira Mono Medium}]{Fira Mono}

\AtBeginEnvironment{tabular}{%
  \addfontfeature{Numbers={Monospaced}}
}

git clone https://github.com/jolars/moloch.git
cd moloch
l3build install

Paper 1

The first of the papers introduces the strong screening rule for SLOPE (Larsson, Bogdan, and Wallin 2020), which is the first screening rule for SLOPE. If you haven’t heard about screening rules before, they are algorithms that discard features (predictors/variables) prior to fitting the model. They are remarkably effective for sparse methods in the high-dimensional setting and typically offer speed ups of several orders of magnitude in the high-dimensional setting. They were first discovered for the lasso with El Ghaoui, Viallon, and Rabbani (2010) and have since proven to be a key ingredient in making the lasso computationally efficient.

They are based on the following reasoning:

1. The solution to a sparse regression problem is, of course, sparse, particularly in the case when the number of features () outnumber the number of observations (). For the lasso, for instance, the size of the support must in fact be no larger than .
2. We can often guess quite accurately which features have little chance of being in the support, for instance by looking at the correlation between the features and the response or the solution to a problem with a larger (or smaller) penalty.¹
3. Even if we are wrong about which features are in the support, it is typically cheap to check if we made a mistake and refit with these features added back in.

This reasoning turns out to be pretty-much on spot and as a result screening rules have turned out to be critical for good performance for the lasso and related methods.

Screening rules are typically separated into safe and heuristic rules. Safe rules guarantee that discarded features are in fact not in the optimal solution, whereas heuristic rules do not. This division is something is something of a misnomer, however, since it is easy to check optimality conditions after fitting the model on the reduced set of features, catch any mistakes, and refit is necessary. And because safe rules sacrifice effectiveness for safety together with the fact that the optimality checks are not very expensive, it is my experience that heuristic rules typically offer better performance. They can even be used together.

The first heuristic screening rule for the lasso was introduced by Tibshirani et al. (2012): the strong screening rule. And in the first paper of my thesis, we extend this screening rule strategy to the problem of solving sorted (_1) penalized regression (SLOPE) (Bogdan et al. 2015).

I have provided some results from the first paper in Table 1. As you can see, screening improves performance considerably and offers no computational overhead even when it has little effect (as in the case of the physician data set).

Dataset	Model			Time (No screening)	Time (Screening)
dorothea	Logistic	800	88119	914	14
e2006-tfidf	Least squares	3308	150358	43353	4944
news20	Multinomial	1000	62061	5485	517
physician	Poisson	4406	25	34	34

Paper 2

Screening rules are particularly effective when they are sequential, that is, operate along the regularization path.² But another possibility that had previously not been explored is the idea of screening not only for the next step on the path, but for all of the remaining steps as well. This is the idea behind look-ahead screening rules, which I introduce in the second paper of the thesis, which is a short paper (Larsson 2021). We use the Gap-Safe screening rule (Ndiaye et al. 2017) here. As the name suggests, it is a safe screening rule. This means that if a feature is screened out, it is guaranteed to be zero in the solution.

As I show in the paper, the results are quite promising (Figure 2), especially since you get this kind of screening essentially for free (if you’re screening anyway).

Paper 4

An ongoing problem in literature on optimization (including screening rules) is that there are now so many methods to examine and so many different models and datasets on which to compare them on, that it has become difficult to keep track of which methods it is that actually do best on a given problem. You can easily find a paper A that studies optimization methods X and Y on datasets I and II and conclude that X is better than Y but then find another paper B, which studies methods X, Y, and Z on datasets I and III and conclude that, actually, Y is better than X and, by the way, Z happens to be best of them all. Then, later, you find paper C, which claims that Z actually is considerably worse than X, which in fact also performs better for data set IV. This confused state of affairs is typically the result of authors having benchmarked their methods using different hardware, programming languages for their implementations, hyperparameters for their methods, and convergence criteria, to name a few of the many possible sources of variation.

In short, there is a dire need for a framework through which this process can be made simple, reproducible, and transparent. This is the motivation behind the benchopt package, which we present in the fourth of this thesis’ papers (Moreau et al. 2022).

The goal of benchopt is to make life easier for both researchers in optimization and users of optimization software. For a researcher who has developed a new optimization method for SLOPE, for instance, all you need to do is to write the code for your solver (optimization method) and plug it into the existing benchopt benchmark for SLOPE and run it. The package will then automatically compare your method with all the other methods in the benchmark and output table and plots of the results Figure 3. If you instead are a user who is interested in using SLOPE for your applied work and want to know which algorithm to use, you can either browse the extensive database of results that other users have already uploaded or just download the benchmark and run it yourself on the data that you are interested in using it for.

Paper 5

Proximal coordinate descent is a very efficient optimization algorithm for fitting the lasso, but it cannot handle the case when the penalty term is non-separable, which is the case in SLOPE. In practice, this has reduced the applicability of SLOPE to large data, which is unfortunate given the many appealing properties of the model.

In paper 5 (Larsson et al. 2023), however, we present a way to circumvent this issue by using a hybrid of proximal coordinate and proximal gradient descent. Our main discovery is that if we fix the clusters and optimize over each cluster in turn, rather than each feature, the problem becomes separable, which means that coordinate descent can be used. And if we combine this with proximal gradient descent steps, which allow us to discover the clusters, then we can guarantee convergence and at the same time benefit from the efficiency of coordinate descent.

The solver is illustrated for a two-dimensional SLOPE problem in Figure 4. The orange cross marks the optimum. Dashed lines indicate PGD steps and solid lines CD steps. Each dot marks a complete epoch, which may correspond to only a single coefficient update for the CD and hybrid solvers if the coefficients flip order. The CD algorithm converges quickly but is stuck after the third epoch. The hybrid and PGD algorithms, meanwhile, reach convergence after 67 and 156 epochs respectively.

Paper 6

The final paper of the thesis is a working paper in which we tackle the issue of normalization of binary features. Normalization is necessary in order to put the features on the same scale when dealing with regularized methods. What “same scale” means, however, however, is not clear, yet has been met mostly with neglect in the literature. We think that this is both surprising and problematic given the almost universal use of normalization in regularized methods and the apparent and large effects it has on the solution paths.

In our paper, we begin to bridge this knowledge gap by studying normalization for the lasso and ridge regression when they are used on binary features (features that only contain values 0 or 1) or mix of binary and normally distributed features. What we find is that there is a large effect of normalization with respect to the class balance of the features: the proportion of ones to zeros (or vice versa). Both the lasso and the ridge estimators turn out to be sensitive to this class balance and, depending on the type of normalization used, have trouble recovering effects that are associated with binary features as long as their class balance is severe enough Figure 4.

I will offer more details on this paper once work on it has been completed, but I think the results are interesting and that this field is ripe for further exploration.

SLOPE 0.2.0

SLOPE 0.2.0 is a new verison of the R package SLOPE featuring a range of improvements over the previous package. If you are completely new to the package, please start with the introductory vignette.

library(SLOPE)
fit <- SLOPE(wine$x, wine$y, family = "multinomial")

plot(fit)

xy <- SLOPE:::randomProblem(100, 1000)
system.time({SLOPE(xy$x, xy$y, screen = TRUE)})

   user  system elapsed 
  1.198   0.004   0.159 

system.time({SLOPE(xy$x, xy$y, screen = FALSE)})

   user  system elapsed 
  2.781   0.006   0.364 

# 8-fold cross-validation repeated 5 times
tune <- trainSLOPE(
  subset(mtcars, select = c("mpg", "drat", "wt")),
  mtcars$hp,
  q = c(0.1, 0.2),
  number = 8,
  repeats = 5
)
plot(tune)

The promise of polygons

R has powerful functionality for plotting in general, but lacks capabilities for drawing ellipses using curves. High-resolution polygons are thankfully a readily available remedy for this and have since several version back been used also in eulerr.

The upside of using polygons, however, are that they are usually much easier, even if sometimes inefficient, to work with. For instance, they make constructing separate shapes for each overlap a breeze using the polyclip package (Johnson and Baddeley 2018).

And because basically all shapes in digital maps are polygons, there happens to exist a multitude of other useful tools to deal with a wide variety of tasks related to polygons. One of these turned out to be precisely what I needed: polylabel (Mapbox [2016] 2018) from the Mapbox suite. Because the details of the library have already been explained elsewhere I will spare you the details, but briefly put it uses quadtree binning to divide the polygon into square bins, pruning away dead-ends. It is inefficient and will, according to the authors, find a point that is “guaranteed to be a global optimum within the given precision”.

Because it appeared to be such a valuable tool for R users, I decided to create a wrapper for the c++ header for polylabel and bundle it as a package for R users.

# install.packages("polylabelr")
library(polylabelr)

# a concave polygon with a hole
x <- c(0, 6, 3, 9, 10, 12, 4, 0, NA, 2, 5, 3)
y <- c(0, 0, 1, 3, 1, 5, 3, 0, NA, 1, 2, 2)

# locate the pole of inaccessibility
p <- poi(x, y, precision = 0.01)

plot.new()
plot.window(
  range(x, na.rm = TRUE),
  range(y, na.rm = TRUE),
  asp = 1
)
polypath(x, y, col = "grey90", rule = "evenodd")
points(p, cex = 2, pch = 16)

The package is availabe on cran, the source code is located at https://github.com/jolars/polylabelr and is documented at https://jolars.github.io/polylabelr/.

Euler diagrams

To come back around to where we started at, polylabelr has now been employed in the development branch of eulerr where it is used to quickly and appropriately figure out locations for the labels of the diagram.

library(eulerr)

plot(euler(s))

Background

R features a number of packages that produce Euler and/or Venn diagrams; some of the more prominent ones (on CRAN) are

• eVenn,
• VennDiagram,
• venn,
• colorfulVennPlot, and
• venneuler.

The last of these (venneuler) serves as the primary inspiration for this package, along with the refinements that Ben Fredrickson has presented on his blog and made available in his javascript venn.js.

venneuler, however, is written in java, preventing R users from browsing the source code (unless they are also literate in java) or contributing. Furthermore, venneuler is known to produce imperfect output for set configurations that have perfect solutions. Consider, for instance, the following example in which the intersection between A and B is unwanted.

library(venneuler, quietly = TRUE)
venn_fit <- venneuler(c(A = 75, B = 50, "A&B" = 0))
plot(venn_fit)

Enter eulerr

eulerr is based on the improvements to venneuler that Ben Fredrickson introcued with venn.js but has been coded from scratch, uses different optimizers, and returns the residuals and stress statistic that venneuler features.

library(eulerr)

# Input in the form of a named numeric vector
fit1 <- euler(c("A" = 25, "B" = 5, "C" = 5,
                "A&B" = 5, "A&C" = 5, "B&C" = 3,
                "A&B&C" = 3))

# Input as a matrix of logicals
set.seed(1)
mat <-
  cbind(
    A = sample(c(TRUE, TRUE, FALSE), size = 50, replace = TRUE),
    B = sample(c(TRUE, FALSE), size = 50, replace = TRUE),
    C = sample(c(TRUE, FALSE, FALSE, FALSE), size = 50, replace = TRUE)
  )
fit2 <- euler(mat)

fit2

      original fitted residuals regionError
A           13     13         0       0.008
B            4      4         0       0.002
C            0      0         0       0.000
A&B         17     17         0       0.010
A&C          5      5         0       0.003
B&C          1      0         1       0.024
A&B&C        2      2         0       0.001

diagError: 0.024 
stress:    0.002 

# Cleveland dot plot of the residuals
dotchart(resid(fit2))

abline(v = 0, lty = 3)

fit2$stress

[1] 0.00198

plot(fit2)

# Change fill colors, border type (remove) and fontface.
plot(
  fit2,
  fills = c("dodgerblue4", "plum2", "seashell2"),
  edges = list(lty = 1:3),
  labels = list(font = 2)
)

Examples

qualpalr relies on one basic function, qualpal(), which takes as its input n (the number of colors to generate) and colorspace, which can be either

• a list of numeric vectors h (hue from -360 to 360), s (saturation from 0 to 1), and l (lightness from 0 to 1), all of length 2, specifying a min and max, or
• a character vector specifying one of the predefined color subspaces, which at the time of writing are pretty, pretty_dark, rainbow, and pastels.

library(qualpalr)
pal <- qualpal(
  n = 5,
  list(
    h = c(0, 360),
    s = c(0.4, 0.6),
    l = c(0.5, 0.85)
  )
)

# Adapt the color space to deuteranopia
pal <- qualpal(n = 5, colorspace = "pretty", cvd = "deutan")

The resulting object, pal, is a list with several color tables and a distance matrix based on the din99d color difference formula.

pal

---------------------------------------- 
Colors in the HSL color space 

        Hue Saturation Lightness
#73CA6F 117       0.46      0.61
#D37DAD 327       0.50      0.66
#C6DBE8 203       0.42      0.84
#6C7DCC 229       0.48      0.61
#D0A373  31       0.50      0.63

 ---------------------------------------- 
DIN99d color difference distance matrix 

        #73CA6F #D37DAD #C6DBE8 #6C7DCC
#D37DAD      28                        
#C6DBE8      19      21                
#6C7DCC      27      19      19        
#D0A373      19      18      20      25

Methods for pairs and plot have been written for qualpal objects to help visualize the results.

plot(pal)

pairs(pal, colorspace = "DIN99d", asp = 1)

The colors are normally used in R by fetching the hex attribute of the palette. And so it is straightforward to use the output to, say, color the provinces of France (Figure 3).

library(maps)
map("france", fill = TRUE, col = pal$hex, mar = c(0, 0, 0, 0))

Details

qualpal begins by generating a point cloud out of the HSL color subspace provided by the user, using a quasi-random torus sequence from randtoolbox. Here is the color subset in HSL with settings h = c(-200, 120), s = c(0.3, 0.8), l = c(0.4, 0.9).

The function then proceeds by projecting these colors into the sRGB space (Figure 5).

It then continues by projecting the colors, first into the XYZ space, then CIELab (not shown here), and then finally the DIN99d space (Figure 6).

The DIN99d color space (Cui et al. 2002) is a euclidean, perceptually uniform color space. This means that the difference between two colors is equal to the euclidean distance between them. We take advantage of this by computing a distance matrix on all the colors in the subset, finding their pairwise color differences. We then apply a power transformation (Huang et al. 2015) to fine tune these differences.

To select the n colors that the user wanted, we proceed greedily: first, we find the two most distant points, then we find the third point that maximizes the minimum distance to the previously selected points. This is repeated until n points are selected. These points are then returned to the user; below is an example using n = 5.