Jonas Greitemann

The C++ range adaptor pipe operator is associative

Sun, 13 Nov 2022 13:37:28 +0000

Tina Ulbrich (@_Yulivee_) recently gave her talk “How to Rangify Your Code” at my local meetup, in which she gave a rundown of several examples from her codebase where loop-heavy code was replaced by pipelines of range adaptors. I sunk my teeth into one of those from an API design perspective and show how it can be generalized to work with generic ranges, based on the associative property of the pipe operator used to compose ranges and range adaptors.

Tina’s `sliding_mean` example

First off, Tina used the range-v3 library for most of her code samples as it supports more range adaptors and consumers than the meager subset that was standardized for C++20. However, C++23 will improve the situation significantly and MSVC (or rather the Microsoft STL) already has good enough support that I will use C++23 standard ranges in this post.

Now, one of the first examples Tina showed was the calculation of a sliding mean. The code that she started out with iterated over a span of values with a raw loop and created arrays of five elements in each iteration which was than passed into a mean function. The resulting means for each of the sliding windows were than pushed into a vector. She then showed how you’d go about doing the same with ranges:

constexpr auto mean(std::span<double const> rng) -> double {
  return std::reduce(rng.begin(), rng.end(), 0.) / rng.size();
}

auto sliding_mean(std::span<double const> rng)
    -> std::vector<double>
{
  return rng | std::views::slide(5)
             | std::views::transform(mean)
             | std::ranges::to<std::vector>();
}

Godbolt

The ranges-based implementation has several advantages over the loop-based one: The size of the window is easily changed; in fact, it could just be turned into a second parameter to the sliding_mean function. Additionally, the original code would have needed to do bounds checking in case the input range is smaller than the window size; the ranges code does that automatically and produces an empty vector in that case.

Generalizing the function to return ranges

Tina already mentioned in her talk that the std::ranges::to<std::vector>() is not even necessary, but she included this to keep the function signature the same compared to the original implementation. If you relax this requirement, sliding_mean turns into a lazy algorithm and its result can be further adapted, e.g., by rounding the window means to the nearest integer:

constexpr auto sliding_mean(std::span<double const> rng)
    -> std::ranges::random_access_range auto
{
  return rng | std::views::slide(5)
             | std::views::transform(mean);
}

auto round_to_int(double d) -> int {
  return static_cast<int>(std::lround(d));
}

int main() {
  std::array const a = {3., 4., 5., 4., 3., 2., 4., 5., 9., 7.,
                        8., 6., 5., 4., 3., 2., 0., 1., 2., 1.};
  fmt::print("{}\n", sliding_mean(a)
                     | std::views::transform(round_to_int));
}

Godbolt

I’m using the {fmt} library here which has the ability to format ranges directly. To be clear, this would’ve worked with the previous version as well but it would’ve meant that first the means are calculated and aggregated into a vector and then, second, that vector would’ve been iterated, its elements rounded and the result would’ve been printed. Instead, this version doesn’t need to allocate any memory for the intermediate vector and instead calculates the means, rounds them, and prints the resulting integers in a single pass.

You may also notice the funny-looking trailing return type. The actual return type is some unwieldy thing like slide_view<transform_view<span<double const>, ...>>. It is of course perfectly fine to omit the return type altogether and have auto deduce it, but just like that’s often not the best idea for “normal” functions with respect to readability, it is beneficial to constrain the return type with an appropriate range concept to give the consumer of the API just the information they actually need to use it. I haven’t seen constrained return types being used in the wild yet, but I hope they catch on as people get more comfortable with concepts as a tool for understanding and documenting requirements rather than just as language support for std::enable_if. In this case, we input a std::span which is a contiguous range, but transform can only retain the random access property.

It should be noted that doing things lazily is not always more efficient and can easily lead to work being done twice. One should be conscious of where the actual work happens (inside of fmt::print where the range is consumed) and that saving the range itself as a local variable and using it multiple times only saves you from rebuilding the “expression template” but does not cache the result of the calculation. If the latter is desired, the caller needs to follow up the range with a to<std::vector>() at the call site to eagerly consume it and then share the result. From an API design perspective, this leaves the decision between lazy and eager computation with the caller; that’s fine so long as they are aware of the responsibility bestowed upon them which can be problematic when introducing this kind of thing to legacy codebases where team members expect eager algorithms.

Generalizing function arguments to accept ranges

Tina’s sliding_mean is already great in that it accepts a std::span. That means that it can be called using a std::vector or a std::array, a C-style array, or in general any range that is both sized and contiguous. That is however still a pretty hefty requirement and rules out almost all the non-trivial range adaptors, as well as range factories like std::views::iota. And it’s an unnecessary requirement at that, given std::views::slide merely requires a forward range. To relax it, we need to turn sliding_mean into a template (here using C++20’s auto template parameters):

constexpr auto sliding_mean(std::ranges::forward_range auto rng)
    -> std::ranges::forward_range auto
{
  return rng | std::views::slide(5)
             | std::views::transform(mean);
}

Constraining the template with the appropriate concept is of course optional, but it helps with readability and fails earlier. There’s a catch here, however: mean so far also operated on spans which worked because slide yields views which are sized and themselves model the same range concept as the input range; i.e., when operating on a contiguous range (like span), slide yields itself sized and contiguous ranges which are then implicitly convertible to spans. Now that we relaxed the contiguity of the argument of sliding_mean, we need to do the same for the argument of mean. Merely turning mean into a function template doesn’t work either, as it cannot be passed as a function reference to std::views::transform without specifying its template arguments which is difficult to do portably. What does work is turning mean into a function object with a generic call operator, e.g. by defining it as a lambda:

inline constexpr auto mean =
    [](std::ranges::sized_range auto rng) -> double {
      using std::ranges::begin;
      using std::ranges::end;
      using std::ranges::size;
      auto c = rng | std::views::common;
      return std::reduce(begin(c), end(c), 0.) / size(rng);
    };

Another detail here is that the <numeric> algorithms are not yet rangified, so we use C++17’s iterator version of std::reduce. That however requires both begin and end iterators to have the same type which is not true for some range views, e.g., std::views::filter. To fix this, the input range is first adapted into a common range.

With this, we are finally able to use our sliding_mean with an input view which is itself a range pipeline, where fmt::print still consumes the range completely lazily but that now also includes the generation of the input numbers themselves.

fmt::print("{}\n", sliding_mean(std::views::iota(0, 30)
                                | std::views::filter(is_even))
                   | std::views::transform(round_to_int));

Godbolt

Composite range adaptors

While the above version is now functionally exactly where we want it to be, it looks pretty awkward. It would be much nicer if sliding_mean would support range pipelining:

fmt::print("{}\n", a | sliding_mean
                     | std::views::transform(round_to_int));

fmt::print("{}\n", std::views::iota(0, 30)
                   | std::views::filter(is_even)
                   | sliding_mean
                   | std::views::transform(round_to_int));

Besides the fact that there’s something deeply satisfying about lining up the pipe operators, this also communicates more clearly that sliding_mean is merely adapting a range and is itself lazy. How might we implement support for operator|? This is actually quite hard to do in general with the range facilities as they stand in C++20 without adding to the std namespace, which is in fact undefined behavior. Fortunately, the situation is about to improve in C++23 thanks to Barry Revzin’s P2387 which introduces the CRTP base class std::ranges::range_adaptor_closure. The sliding_mean function can then be replaced by the call operator of a function object sliding_mean_fn which derives from range_adaptor_closure:

struct sliding_mean_fn
  : std::ranges::range_adaptor_closure<sliding_mean_fn>
{
  constexpr auto operator()(forward_range auto&& rng) const
      -> std::ranges::forward_range auto
  {
    return rng | std::views::slide(5)
               | std::views::transform(mean);
  }
};

inline constexpr sliding_mean_fn sliding_mean;

Godbolt

That works and is honestly not that much boilerplate. There exists however a much simpler way of achieving the same effect which already works in C++20 (at least if you ignore that slide is C++23) and relies on the fact that the pipe operator for range adaptors is associative, meaning that given a range R and two range adaptors A₁ and A₂, the expression R | A₁ | A₂ can both be seen as the successive application of both adaptors, (R | A₁) | A₂, or equivalently as the application of a single combined adaptor, R | (A₁ | A₂). Hence, instead of defining a sliding_mean function which applies two adaptors to a generic range argument and then going to the motions of turning that function into a range adaptor closure, we can simply combine both adaptors to yield the sliding_mean adaptor object directly!

inline constexpr auto sliding_mean =
    std::views::slide(5) | std::views::transform(mean);

Godbolt

That is almost embarrassingly simple. Composing range adaptors in this way is akin to point-free programming in functional programming languages where functions are defined through composition and partial application (“currying”) of other functions. The equivalent of currying is also possibly by creating a range adaptor factory function, e.g. to allow specifying the window size:

constexpr auto sliding_mean(std::size_t s) {
  return std::views::slide(s) | std::views::transform(mean);
}

Godbolt

EuroRust 2022 Trip Report

Sat, 29 Oct 2022 21:58:48 +0000

This fall, I attended the first-ever EuroRust, the European offshoot of Rustfest, in Berlin. The conference was fairly small (but sold out) with just two days and a single track, yet the talks were all pretty high-quality. Since the Rust community is quite small and full-time Rust jobs are still in short supply, it was interesting talking to people who managed to work in one. I had a great time in Berlin; the organizers were very professional, the venue was appropriately industrial, food and coffee (!) were great, and it was all rounded out by a delightful closing dinner on a boat on the Spree river. In short, I’m already looking forward to next year’s edition.

Below, I’ve collected my impressions of some of the talks, grouped by their overarching topics.

Integration and interop with other languages

Few people get the chance to start a greenfield project at work, let alone in Rust; for most projects and products, the aim is to start using Rust in some fairly small corner where it can play out its strengths, be it performance or safety, and gradually expand its scope from there. The headline story in this context in recent months certainly was Rust being used inside the Linux kernel, but an arguably even more pervasive piece of software which underpins billions of devices, is libcurl. Its maintainer, Daniel Stenberg, gave the opening keynote and presented the architecture of libcurl which provides several C interfaces for HTTP 1/2/3, QUIC, and TLS backends, all of which have implementations in Rust, based on the hyper, quiche, and rustls crates, respectively. Neither one is feature-complete at this point, and it’ll be awhile until downstream projects start shipping libcurl with the Rust backends by default, but I’m amazed that a library as well established as libcurl dares to build on top of, say, hyper and the underlying Tokio runtime. Vice versa, libcurl’s requirements can inform the development of new APIs in those crates, as well as the Rust language at large.

Colin Finck, who’s a contributor in the React OS project which aims to reverse-engineer a binary-compatible clone of MS Windows, presented on his crate nt-list which comes with an ABI compatible implementation of Windows Linked Lists in Rust. He highlighted some of the challenges that arise from the need to copy the memory layout of the intrusive LIST_ENTRY node and how to overcome those in safe Rust. The resulting implementation prevents most of the common misuses of the original C implementation while retaining binary compatibility which allows using them to write Windows drivers or to browse their contents in WinDbg, even with versions predating Rust itself.

Raphaël Gomès reported on how the Mercurial VCS has been rewriting some of its Python codebase in Rust. He went over some of the challenges, from technical issues related to encodings and testing, to human ones, like building Rust experience in a team of Python devs. While the learning curve has been steep and bumpy at times, he surmised that introducing Rust has been beneficial not just for the head-spinning performance improvements of 20,000x in some cases, but also in terms of developer productivity.

While many of the Rust integrations rest on the FFI to C, interoperating with higher-level languages can be a bit more of a challenge. As a C++ developer in my day job, Rust’s interop story with C++ was of particular interest to me. Tobias Hunger reviewed several approaches, from calling member functions of C++ classes from within Rust (and vice versa) using the cxx crate, including automatic translation between certain library types like std::unique_ptr, std::vector, and std::string to Rust counterparts, to writing inline C++ code within a Rust function using the cpp crate. Tobias also briefly touched on how C++ libraries can be integrated into Cargo projects and how Rust code can be built from a CMake project using Corrosion. I was pleasantly surprised by what is possible in this space, esp. in the context of the current craze around C++ successor languages like Carbon, which actually recommends to use Rust for new projects and pitches itself as an option for seamless interop with legacy C++ codebases. I wonder if an investment into Rust interop wouldn’t be more fruitful than building another memory-unsafe language from scratch.

Last but not least in this category, there was a talk by Bogdan Kolbik about interop with the JVM from an application written in Scala. While it is possible to call into native code from the JVM using the JNI, they ended up passing Protobuf messages between Rust and Scala code. It would be interesting to know how JetBrains does interop between Kotlin, another JVM language, and the Rust backend in their new Fleet IDE, but I suspect it will be a similar story, given that Fleet’s backend can run remotely as well.

Rust and the Web

While in C++ circles, Rust is perceived mainly as a competitor systems programming language, a lot of the interest in Rust is actually coming from the massive web development community. This is attested to by Mainmatter, a Munich-based web consultancy, who presented EuroRust and publicized what they call a “strategic bet on Rust” at the start of the conference. In this space, there are mainly two areas where Rust is becoming increasingly popular: Using Rust in the server backend to replace web frameworks like Rails, as well as compiling Rust to WebAssembly to run in the browser. Of course, both of these can be combined in the same application to convey some of the same benefits that made Node.js popular, i.e. sharing code between client and server side, and WASM itself can be executed server-side as well, either through Node.js or for instance wasmtime.

On the first front, server-side web frameworks, Rust developers are increasingly spoiled for choice. Rainer Stropek did a good job reviewing and comparing four of them: Actix-web, Rocket, Warp, and Axum. He implemented the same simple API in each of them and gave the audience a feel for their respective approaches. While Rocket seems to be the most ergonomic of the bunch with its “magic” proc macro routes and being pitched as “batteries-included”, personally I like the tradeoffs chosen by the newcomer Axum best as it is built on top of Tower, Tokio’s middleware ecosystem, and ditches macros in favor of still-readable-yet-not-quite-as-magic builder patterns.

On the WebAssembly side of things, François Mockers showed how games written using the Bevy engine can be compiled into WASM. His talk was somewhat in the same vein as the one by Ólafur Waage back at C++ on Sea who showed how to accomplish the same thing in C++, albeit without the benefit of a feature-rich engine such as Bevy. Subsequently, Alberto Schiabel dove a little more into technical details on the secret sauce which makes the integration of Rust into a JS app relatively smooth, but also showed some of the limitations that (still) exist.

Case studies

There’s just something deeply satisfying in starting out with a long spaghetti-code function and iteratively refactoring it until it fits comfortably on a single slide. That’s exactly what Stefan Baumgartner did in this talk “Trails, traits, and tribulations”. While some of this is just the application of common sense and recognizing where the responsibility of one function ends and that of another starts, Stefan also had some advice specific to Rust, like using the ?-operator to focus the function on the happy path and how implementing standard library traits for your own types helps you identify those responsibilities and leads to more idiomatic code, meanwhile promoting code reuse, e.g. by implementing Display for Foo instead of writing a function print_foo.

Rafael Epplée gave an account of how he went about end-to-end testing a web backend, though I found that most of what he presented carries over to other types of application you’d want to write tests for (which should be all of them!), be it integration tests or unit tests. In Rust, the story really isn’t any different from how you’d go about it in other languages: abstract over the unit’s interactions with the outside world (filesystem, databases, other program units which are tested separately) with a trait, and inject a fake test implementation which can be used to verify the expected effects but doesn’t depend on the actual environment, thus giving you fast, parallel, and reproducible tests. Rust’s trait system is uniquely suited for this task as it allows implementing the trait also on foreign types, thus eliminating the need for a wrapper around third-party dependencies. Rafael also introduced the rstest crate which I have since started using myself as it provides support for test fixtures, parametrized tests, and more.

A colleague of mine at MVTec, Lukas Bergdoll, set out on a journey to optimize Rust’s existing stable sort implementation and took the audience along to witness the mistakes he made on the way and shared his learnings. Overall, it served as a humble reminder to always re-check your assumptions when confronted with surprising results. It takes some courage to admit that you’re wrong, let alone to turn that into a talk. Here’s to hoping that his work might still make it into the standard library.

Governance and Organizations

This last cluster of topics focussed less on the language itself but rather on the people and processes that drive its progress. Recent events and discussions about the future of C++ pointed out the shortcomings of its ISO process and many see Carbon’s biggest advantage over C++ in its open-source process for evolving the language (draft) which is inspired by the likes of Swift and Rust. Hence, I was interested in how the Rust project’s governance model actually works and Ryan Levick gave a pretty good overview of its structure and processes in his keynote at the start of the second day. The day before, Pietro Albini, who heads the Rust Security Response WG, walked through the lifecycle of a particular CVE and shed some light on the sensitive work that by definition has to happen behind closed doors.

The first day concluded with a panel discussion, moderated by the Rust Foundation’s CEO, Rebecca Rumbul, with representatives from four companies which are using Rust. An interesting takeaway was that the market for Rust developers is still pretty much inverted from the labor market at large, both because Rust is popular with developers, but also because companies are still reluctant and careful to migrate projects to (or start projects in) Rust. And when they do, they typically start with a small team of veteran engineers; few companies are willing to take the risk of trusting a new hire with a project using a technology they don’t have experience with — that’s one unknown too many. Thus, for folks who wish to use Rust professionally, the panel recommended to try to push for Rust at work when the chance presents itself, to find some niche where Rust can be integrated and play out its strengths, and then to talk about it, at conferences, in blog posts, on Twitter, to make the industry see that placing the bet on Rust may not be as risky as it might seem.

C++ on Sea 2022 Trip Report

Sun, 07 Aug 2022 13:04:49 +0000

I had a chance to attend “C++ on Sea” in Folkestone this year. This write-up aims to give an overview of my personal highlights as well as some solid overview talks.

Highlights

Jason Turner: Making C++ fun, safe, and accessible

Jason gave the closing plenary talk of the conference, dubbed “endnote”, and this was announced as his “most interactive talk” yet which says a lot if you know his style. However, it started out perfectly silent with him putting up slides with code in a made-up language with gibberish keywords and unfamiliar syntax, prompting the audience to infer what the code would do and by extension learn a new language. This was later revealed as a pitch for a project to develop resources to teach C++ to people (and particularly children) who don’t speak English (yet) to make it more accessible.

As for whether C++ as a language is safe, he showed a code snippet with several bugs and demonstrated how using the right tools, modern compilers will suggest how to make the code compile, sanitizers can spot memory errors among other things, and static analyzers will nudge you in the way of best practices. These tools can be difficult to set up properly (as even our build systems have the wrong defaults) and Jason promoted his best-practice CMake starter projects on Github which come with full sanitizers and static analyzers running in CI on day one.

Daniela Engert: Contemporary C++

Daniela’s talk was dominated largely by her scrolling through a toy project (which is already on her Github) which is a simple client/server architecture where the server reads GIFs from a directory and writes their frames to socket; whereas the client reads the images and displays them in a GUI. This was accomplished through liberate use of coroutines: iterating the directory using a generator, reading the GIFs from disk, and running the server — all done asynchronously but without spawning any dedicated threads. Instead, she plugged the coroutines into each other and scheduled the whole thing on a thread pool provided by the ASIO library, meaning that she could just as well run the whole app just on a single thread, without ever blocking on I/O operations. Even though the presentation of the code was a bit dry at times, this was a really impressive demo how to use coroutines in practice and how they have the potential to revamp and simplify our architectures, removing the need for synchronization completely and thus eliminating entire species of bugs.

Daniela also showed off the use of std::stop_source for cooperative cancellation (standalone, without using std::jthread) to shut the server down cleanly, and generally wrapped all her dependencies in modules which re-export the bits she needed.

Jonathan Müller: Coroutines in C++ vs. Rust

I was looking forward to this talk ever since the programme was announced. Same as C++, Rust gained language support for coroutines (more commonly just referred to as “async/await”) fairly recently and both languages went for a “stackless” approach (contrary to Go’s “Goroutines” which are stackful). Otherwise, they went for quite different approaches.

In C++, a coroutine looks like a regular function but has to contain one of the new keywords co_await , co_return, or co_yield . The return type of the function is not the “logical” return type which is “returned” through co_return or co_yield , but a coroutine type like std::generator (coming in C++23) which customises the behaviour of the coroutine through its associated promise_type and is usually templated on the logical return type. Rust coroutines are more obvious to spot from the function declaration as they are functions prefixed with the async keyword. There’s no special syntax to return from them, co_await x is spelled x.await, and there is no way to yield values from them.

There are also notable differences in how the memory associated with a coroutine is managed. A C++ coroutine’s internal state machine resides in a compiler generated type, the coroutine frame, which is inaccessible to the programmer who interacts with it solely through a type-erased handle. For that reason, the coroutine frame is technically always heap-allocated, though that allocation may be elided in some cases. In contrast, the state machine type powering Rust’s async functions (which implements the Future trait) is either entirely compiler-generated, or can be entirely hand-written and its type can be named and is Sized. This gives Rust programmers control over how they want to store the coroutine, including on the stack when practical, but also means that the type must be known to the compiler frontend which prevents the backend from optimising away unused members.

I’ll definitely have to rewatch the talk after I have played around with coroutines in both languages more. Jonathan talks quite fast and the subject is not easy so all of us came out of that talk with our heads spinning. My impression is that C++’s approach is overall probably a bit more efficient and flexible; I’m just wondering if that is worth it, considering that Rust’s async functions seem more accessible, particularly to programmers coming from e.g. Javascript where working with async/await is common practice.

Honourable mentions

Hana Dusíková: Lightning Updates

Hana gave the opening keynote of the conference, presenting a soon-to-be-open-sourced library to manage update mechanisms with possibly complex update path graphs. This was an interesting case study in API design, showing off many of the new features coming in C++23 along the way. Working at Avast, the natural example for this are Anti-Virus definitions which need frequent updates but shouldn’t guzzle too much bandwidth. However, towards the end she showed how the updater can be customized to draw its update data from the filesystem, effectively turning her library into a simple VCS.

Andrew Soffer: How Hard Could It Be? Lessons Learned from Replacing int64 With int64_t.

Andrew gave an account of what it took to refactor Google’s entire codebase to replace Google’s own typedef int64 with the standard int64_t. Even when only considering x86_64 Linux as the target architecture, this turned out much harder than one might expect even though both types represent the same idea, have identical binary representations, and are implicitly interconvertible. Still, both typedefs alias distinct types (long vs. long long) which has implications for overload resolution of function templates, as well as type specifiers in printf-style format strings.

The sheer size of Google’s codebase (about 250 million lines) means that manual refactorings just don’t scale. Instead, he stressed the importance of automatic refactorings using clang-based tools and how an almost full unit test coverage is essential to confidently commit changes too large for any human to review.

Ólafur Waage: Sandbox Games — Using WebAssembly and C++ to make a simple game

It’s been more than four years since I last worked with C++ compiled into WebAssembly using the Emscripten toolchain, so I was curious to see how the tooling improved, esp. given that Rust has been leading the way in terms of WASM support recently. Emscripten now targets WASM by default (as opposed to asm.js) and bindings for C++ data structures and functions can be defined through macros in the emscripten.h header which is a huge improvement from the raw shared memory access I was familiar with, though it’s nowhere near as convenient as Rust’s bindgen.

In terms of tooling, Ólafur demonstrated how the built-in (Javascript) debugger in Chrome and Firefox can be used to debug and profile WASM, including setting breakpoints in C++ code or viewing flame graphs. Additionally, standalone WASM runtimes allow using WebAssembly also outside of the browser similar to Node.js, or they can be embedded to create portable plug-in infrastructures.

Good overview talks

Anthony Williams: An introduction to multithreading in C++20

Anthony is responsible for many of the multithreading features in C++ and gave a good overview of latches, barriers, futures, mutexes, semaphores, and atomics — and why should reach for them in that order. He also explained how the cooperative cancellation API and std::jthread can help treat dedicated threads as value types.

Bryce Adelstein Lelbach: Standard Parallelism

Bryce gave an introduction into the “senders and receivers” proposal which will hopefully be accepted for C++26. If so, it will deliver on the final two “pillars” of standard parallelism, the first one being the C++ 17 ExecutionPolicy overloads of standard algorithms. In the second part of the talk, Bryce then presented std::mdspan, which is now almost certainly coming in C++23, and gave an outlook how it may tie into the various linear algebra proposals.

Mateusz Pusz: Sneak Peek C++23

Mateusz’s talk went over all the new features that made it into C++23 so far. In particular, he spent quite a bit of time on “deducing this” which will reduce the amount of boilerplate code library authors will need to write and will make CRTP obsolete. Update: Unfortunately, the video of this talk is not available on Youtube. There may have been a problem with the recording.

Closing remarks

This being my first C++ conference I was curious how the experience would compare to academic (physics) conferences and how much of a difference it would make to attend in person as compared to watching the recording on Youtube. It is definitely something else to sit in a Jason Turner talk for real. I also didn’t find the more technical talks as exhausting as watching them on Youtube. This was helped by the fact that the programme had plenty of coffee breaks. Those are sometimes referred to as the “hallway track” and I found it easy to engage in conversation with other people as this was the first conference for many of them. Lastly, I was pleasantly surprised by how diverse and inclusive the conference was.

View from the conference venue, overlooking the English channel with the Frensh coastline on the horizon.

Joining MVTec

Mon, 02 Dec 2019 06:32:07 +0000

Besides prepping for the defense of my thesis, I spent most of the past few months scouring the job market in Munich. To that end, I’ve made a habit of attending the MUC++ meet-up to get a peek into different companies using C++ in and around Munich. The line-up of speakers at those meetings is quite impressive and I will certainly keep going whenever possible.

It is through these meet-ups that I became aware of MVTec, a local software company specializing in machine vision with a focus on industrial applications. After a quick round of interviews, I’ve accepted an offer for a position as Software Architect working on their MERLIC product, starting today.

I’m very excited to embark on this next step in my career. Naturally, I am not at liberty to discuss any details of my work in the same manner as I did during my PhD. Still, I expect to be able to keep this blog going, highlighting some of the C++ tidbits I’ll come across or side projects that I may or may not have time for. Any and all opinions voiced on this website remain my own and are in no way affiliated with MVTec.

Version 3 release of TK-SVM — Wrapping up

Sun, 01 Dec 2019 22:17:04 +0000

A new version of the TK-SVM framework has just been released and is now available on the university’s GitLab repository. In keeping with the number of SVM-related papers we have published in the past 1.5 years, this is version 3 and reflects the changes made to the framework to facilitate our latest paper, studying the XXZ model on the pyrochlore lattice.

svm-order-params

This release brings about a larger selection of sweep policies, more flexibility in combining data from different runs, a new client code for generic classical frustrated spin systems, a new MPI-based parallelization model, infrastructure for parallel tempering, many extensions to the simple graph analysis introduced in the previous version, and countless bug fixes. A comprehensive changelog is also available.

More information on the TK-SVM method is now also publically available in my PhD thesis, including an (otherwise unpublished) application to the Heisenberg model on the Kagome lattice. This wraps up my involvement with the TK-SVM project, even though this work will very much continue without me.

Frustrated magnetism: Thesis motivation

Tue, 03 Sep 2019 21:58:09 +0000

From water to spin ice

Frustration is ubiquitous in nature. So much so that the properties of water, including its unusually high melting and boiling points, its large heat capacity, latent heat, and anomalous density curve—all crucial for the development of life as we know it—are all consequences of frustration.

Figure 1: A configuration of five water molecules obeying the ice rules: each oxygen is covalently bound to two hydrogens and exactly one hydrogen sits between any two neighboring oxygens.

It is well known that the hydrogen atoms in \(\mathrm{H_2O}\) span an angle of about \(104^\circ\), slightly less than the \(109^\circ\) corresponding to the unperturbed tetrahedral coordination of hybridized \(sp^3\) orbitals of the central oxygen atom. This leads to a nonvanishing dipolar moment due to the partial charges induced by the larger electronegativity of oxygen as compared to hydrogen. In water ice (specifically the ice \(\mathrm{I}_h\) phase formed under terrestrial conditions), the molecules are arranged in a lattice with close to tetrahedral bond angles as well. Due to the partial charges, it is energetically favorable for exactly one hydrogen to sit between any neighboring oxygen atoms, being covalently bound to one of them and forming a weak “hydrogen” bond with the other. The orientation of the water molecules in the lattice is then determined by the Bernal-Fowler “ice rules” [1] which state that each molecule should be faced by the hydrogen atoms of two of its neighbors and the oxygen sides of the other two. An example of a configuration respecting these ice rules is shown in Fig. 1.

The ice rules do not uniquely determine the ground-state configuration of water ice. Rather, the number of compatible configurations, i.e. the degeneracy of the ground state, grows exponentially with system size. This then gives rise to an extensive contribution to the residual entropy which was famously estimated by Pauling as \(S_0/n = \ln(3/2) R\approx 3.4\,\mathrm{J}/(\mathrm{mol\,K})\) [2]. The extensive residual entropy consequently affects the thermodynamics of bulk properties and leads to the above anomalies associated with water. An exponential ground-state degeneracy is one of the hallmarks of frustrated systems. Somewhat sloppily, it is more commonly referred to as an extensive ground state degeneracy (exGSD) because it gives rise to an extensive residual entropy.

Figure 2: The equivalent spin ice configuration on a pyrochlore lattice. For each tetrahedral cluster, two spins are pointing inwards and two are pointing outwards.

An analogous situation is realized in a class of magnetic systems which—for this reason—are known as spin ices. Experimental realizations of spin ices have been discovered in the rare-earth oxide materials \(\mathrm{Ho_2Ti_2O_7}\) [3] and \(\mathrm{Dy_2Ti_2O_7}\) [4,5]. In these compounds, only the rare-earth ions (\(\mathrm{Ho}^{3+}\) and \(\mathrm{Dy}^{3+}\)) are magnetic. These form a pyrochlore lattice, a network of corner-sharing tetrahedra; its geometry is depicted in Fig. 2. Due to a strong crystal-field anisotropy along the axis connecting the centers of tetrahedra, the magnetic moments behave as Ising spins. The energy of such a configuration is then minimized if within each of the tedrahedra, two of the spins point inwards, while the other two point outwards. This “two-in-two-out” rule is the spin-ice analogue of the ice rules in water. Indeed, Fig. 2 depicts a configuration obeying the two-in-two-out rule which is equivalent to the water ice configuration in Fig. 1 by having the spins in the former point towards the location of each of the hydrogen atoms in the latter. The residual entropy of \(\mathrm{Dy_2Ti_2O_7}\) has been found from its heat capacity to be consistent with that of water ice \(\mathrm{I}_h\) and Pauling’s estimate [6].

Gauge theoretical description and magnetic monopoles

The fluctuations permitted by the spin-ice rule may also be understood by analogy to magnetostatics. By identifying the spins \(\mathbf S_i\) at positions \(\mathbf r_i\) in the lattice with the local strength of an artificial magnetic field \(\mathbf B(\mathbf r_i)=\mathbf S_i\), the spin-ice rule can be summarized in a generalize Gauss’ law, \(\mathbf\nabla\cdot\mathbf B=0\) [7]. Hence, two magnetic “field lines” enter into each lattice tetrahedron and likewise two also exit it. After coarse graining, this immediately implies that the correlations between magnetic fields a distance \(\mathbf r\) apart take on a dipolar form [8,9,10],

\[\left\langle\mathbf B(\mathbf 0)\otimes \mathbf B(\mathbf r)\right\rangle\sim \frac{\mathbf{r}^{\otimes 2} - \|\mathbf r\|^2/3}{\|\mathbf r\|^5},\]

and thus decays as \(1/\|\mathbf r\|^3\) at large distances. Power-law correlations like this are unusual away from critical regimes. They manifest themselves as sharp features called “pinch points” in the spin structure factor and have been observed in neutron scattering experiments on \(\mathrm{Ho_2Ti_2O_7}\) [11].

Violations of the spin-ice rule lead to defects for which \(\mathbf\nabla\cdot\mathbf B\) takes on a nonvanishing value which may be interpreted as a magnetic “charge” density. Excitations above the ground state manifold thus correspond to the creation of a pair of magnetic monopoles of opposite charge at which a magnetic field line—in this context referred to as a Dirac string—originates and terminates, respectively [7,12,13]. Once created, the monopoles can move away from each other at no additional energy cost. They thus constitute fractionalized excitations and the energy associated with each monopole is half that of a single spin flip [14]. Since the spins carry a magnetic moment, these monopoles exert a magnetostatic Coulomb interaction onto each other. This is weak compared to the electrostatic force but its signature was nonetheless first measured in diffuse neutron scattering experiments on \(\mathrm{Dy_2Ti_2O_7}\) in 2009 [15]. The ensuing onslaught of experiments has focussed primarily on the dynamics of monopoles both in classical [16] and quantum [17] spin ices. Monopoles have also been observed in artificial spin ice realized in lithographically fabricated magnetic nanodevices [18].

Classical and quantum spin liquids

Spin ices are the posterchild of a class of correlated spin states, nowadays collectively known as classical spin liquids (CSLs). More traditionally, these have also been called correlated or cooperative paramagnets as they crucially do not exhibit long-range order, but rather strong algebraically decaying correlations. As in the case of spin ice, these originate from fluctuations within an extensive ground-state manifold which is characterized by local constraints such as the spin-ice rule. The constraints in turn signal the emergence of a gauge theoretical structure, complete with monopole-like fractionalized excitations.

At low enough temperatures, even fluctuations within the ground-state manifold eventually slow down and the CSL may freeze out of equilibrium. For example, in spin ice, at the very least hexagonal rings of six spins can cooperatively flip at once while remaining in the ground state. The ever-smaller tunneling probabilities for such zero modes hence cause the spins to freeze into an amorphous glassy state; in \(\mathrm{Dy_2Ti_2O_7}\) this reportedly happens below \(T_f=0.5\,\mathrm{K}\) [19]. Other types of CSLs may instead enter into an ordered phase below a transition temperature \(T_c\) (see “Hidden order” below for a possible mechanism). Either way, the relevant temperatures are expected to lie significantly below the scale set by the Curie-Weiss temperature \(|\Theta_\text{CW}|\) which provides a rough estimate for the ordering temperature in unfrustrated systems. \(\Theta_\text{CW}\) can be determined from the asymptotic high-temperature behavior of the magnetic susceptibility, \(\chi^{-1}\sim (T - \Theta_\text{CW})\). The frustration-induced CSL behavior thus takes hold in the regime \(T_c\)<\(T\)<\(|\Theta_\text{CW}|\) and its extent is commonly quantified by the frustration parameter \(f=|\Theta_\text{CW}|/T_c\) (or \(f=|\Theta_\text{CW}|/T_f\) in case of freezing). While \(f\sim 5\) may otherwise still occur, frustration can easily result in \(f\gg 100\) [20].

Materials with small atomic spins might, however, display an entirely different behavior at the lowest temperatures: quantum fluctuations due to a nonvanishing zero-point energy may allow for the formation of a quantum spin liquid (QSL) which persists down to \(T=0\), corresponding to \(f=\infty\).

The energy between any two antiferromagnetically coupled spins is locally minimized by a singlet. One may naively assume that the ground state thus consists of a product of such valence bond singlets, periodically tiled over the bonds of the lattice. Such a valence bond solid (VBS) has a vanishing total spin and is hence nonmagnetic, yet by choosing a specific dimer covering, it breaks lattice symmetries. Anderson proposed that a system might rather form a superposition of all possible dimer coverings of spins into valence bonds on the lattice [21–23], thereby retaining the lattice symmetry. In the language of quantum chemistry, such a state would exhibit valence bonds which constantly fluctuate amongst each other, but do so in a phase-coherent (highly entangled) way, thus coining the name resonating valence bond (RVB) state.

The RVB state is the archetype of QSLs, but a superposition of dimer coverings is not the only possible microscopic realization of a QSL state and a consensus on the defining characteristics of a QSL was not reached until recently (and even that is debateable). Quite generally, however, a “true” QSL would be expected to host fractionalized excitations [20,24]. This makes them attractive for quantum computation as it allows for the development of topological error correction codes, as exemplified by Kitaev’s toric code [25,26]. Unfortunately, as of yet, not a single QSL has been experimentally identified in an unambiguous way, despite tremendous effort over the past decade. Extensive reviews of the state of the art of experiments into both CSLs and QSL candidates are provided in Refs. 24 and 27.

Hidden order

The experimental identification of spin liquids, both classical and quantum, typically has to resort to a negative definition, i.e. ruling out the presence of any symmetry-breaking order, in lieu of experimentally accessible genuine spin-liquid characteristics. This is further complicated by the fact that such orders in frustrated lattice geometries may too elude common experimental probes as they do not give rise to a macroscopically observable magnetization. For this reason, they are referred to as “hidden” orders [28–33].

Indeed, even in Monte Carlo simulations of classical spin models where one has access to the full microscopic spin configuration, identifying the presence of hidden orders remains a highly nontrivial task. This is due to their multipolar nature: in contrast to dipolar orders whose symmetry-breaking is characterized by a nonvanishing vector-like (rank-1) order parameter such as the (staggered) magnetization in the case of (anti)ferromagnetism, frustrated lattice geometries may favor orders which only break part of the full spin-rotational symmetry while staying disordered with respect to the remaining symmetry, giving rise to order parameter tensors of higher rank such as matrices (quadrupolar order) or third-rank tensors (octupolar order). Examples can be found in spin nematic orders [34–45]. Conventional numeric probes then often suffer the same fate as their experimental counterparts and one has to resort to (weak) signatures in thermodynamic properties such as the heat capacity to pin down the presence of a phase transition. Even then, this does not yield any insight into the nature of the tentative phase.

It may seem paradoxical at first that a spin system whose ground state manifold is defined by constraints, which in and of themselves do not break any symmetries, would develop an ordered phase at low temperatures. One mechanism to facilitate symmetry-breaking in classical systems was first described by Villain et al. [46]. While by definition all ground states have the same energy, some of them may be entropically selected for their lower free energy. This is the case when a certain subset of ground state configurations admits thermal fluctuations into a vast region of phase space surrounding these ground states at small energy expenditure by means of soft modes¹. The phenomenon was coined order-by-disorder [8] and famously accounts–among other cases [47]—for the selection of coplanar spin order in the Heisenberg antiferromagnet on the kagome lattice which was postulated by Chalker et al. in 1992 [48]. However, his initial description in terms of a quadrupolar order parameter was later recognized as incomplete and rather called for an additional octupolar order parameter [49–51].

Premise of my PhD thesis

The study of frustrated magnets, particularly the quest for spin liquids—both classical and quantum—remains an active field of research in both theory and experiment. While QSLs have proved more elusive, the occurrence and stability of CSLs, especially as compared to spin nematic phases, is far from understood. Advances in experimental techniques over the past decade have accelerated the pace of the synthesis and charaterization of new materials to the point where it has become a matter of months, not years. Meanwhile the process of piecing together the phase diagram of each new model remains a laborious and manual process which heavily depends on the ingenuity and intuition of individual researchers, rendering it a serious bottleneck.

Devising a machine learning scheme to aid this process, inspired by the recent sprawl of activity, thus seemed like a worthwhile endeavor. However, merely recognizing different phases in frustrated models—while useful—would not have sufficed; rather, a highly interpretable machine is in demand which allows for the reconstruction of the physical order parameter. For this reason, we turned to kernel methods and proposed a tensorial kernel (TK) function. As the name suggests, its functional form was chosen to be capable of expressing tensorial order parameters like those characteristic of multipolar order, while not imposing any further restrictions other than locality. Its design thus does not require the problem to be already “solved”, but covers the realm of multipolar tensor order parameters exhaustively. When combined with a support vector machine, it is jointly referred to as TK-SVM, but the use in conjunction with kernel principal component analysis (kPCA) has also been demonstrated.

In my thesis, the TK is applied to the infamous case of the aforementioned Heisenberg model on the kagome lattice as well as the XXZ model on the pyrochlore lattice which features a diverse phase diagram, including a spin nematic phase and three types of CSLs [52,53]. Indeed, the order parameter tensors of both the spin nematic phase in the case of the XXZ pyrochlore model and the complete characterization of the hidden order in the kagome model have been identified by TK-SVM.

Serendipitously, while the original design of the TK was aimed at expressing multipolar order, it turned out to be also capable of expressing the emergent constraints which characterize the ground-state manifold of CSLs and underpin their gauge-theoretical description. In that regard, the method went above and beyond expectations and reconstructed the phase diagram of the XXZ pyrochlore model, including the location of the crossover regimes between different types of CSLs, with little human guidance.

References

[1] J. D. Bernal and R. H. Fowler. A Theory of Water and Ionic Solution, with Particular Reference to Hydrogen and Hydroxyl Ions. J. Chem. Phys. 1, 515–548 (1933).
[2] Linus Pauling. The Structure and Entropy of Ice and of Other Crystals with Some Randomness of Atomic Arrangement. J. Am. Chem. Soc. 57, 2680–2684 (1935).
[3] M. J. Harris, S. T. Bramwell, D. F. McMorrow, T. Zeiske, and K. W. Godfrey. Geometrical Frustration in the Ferromagnetic Pyrochlore Ho₂Ti₂O₇. Phys. Rev. Lett. 79, 2554–2557 (1997).
[4] Steven T. Bramwell and Michel J. P. Gingras. Spin Ice State in Frustrated Magnetic Pyrochlore Materials. Science 294, 1495–1501 (2001).
[5] Jason S. Gardner, Michel J. P. Gingras, and John E. Greedan. Magnetic pyrochlore oxides. Rev. Mod. Phys. 82, 53–107 (2010).
[6] A. P. Ramirez, A. Hayashi, R. J. Cava, R. Siddharthan, and B. S. Shastry. Zero-point entropy in ‘spin ice’. Nature 399, 333–335 ((1999).).
[7] Claudio Castelnovo, Roderich Moessner, and Shivaji L. Sondhi. Magnetic monopoles in spin ice. Nature 451, 42–45 (2008).
[8] John T. Chalker. Geometrically Frustrated Antiferromagnets: Statistical Mechanics and Dynamics. In Claudine Lacroix, Philippe Mendels, and Frédéric Mila, editors, Introduction to Frustrated Magnetism, chapter 1. Springer Berlin Heidelberg (2011). ISBN 978-3-642-10588-3.
[9] Christopher L. Henley. Power-law spin correlations in pyrochlore antiferromagnets. Phys. Rev. B 71, 014424 (2005).
[10] Christopher L. Henley. The “Coulomb Phase” in Frustrated Systems. Annu. Rev. Condens. Matter Phys. 1, 179–210 (2010).
[11] T. Fennell, P. P. Deen, A. R. Wildes, K. Schmalzl, D. Prabhakaran, A. T. Boothroyd, R. J. Aldus, D. F. McMorrow, and S. T. Bramwell. Magnetic Coulomb Phase in the Spin Ice Ho₂Ti₂O₇. Science 326, 415–417 (2009).
[12] Ivan A. Ryzhkin. Magnetic relaxation in rare-earth oxide pyrochlores. J. Exp. Theor. Phys. 101, 481–486 (2005).
[13] Claudio Castelnovo, Roderich Moessner, and Shivaji L. Sondhi. Spin Ice, Fractionalization, and Topological Order. Annu. Rev. Condens. Matter Phys. 3, 35–55 (2012).
[14] Ludovic D. C. Jaubert and Peter C. W. Holdsworth. Signature of magnetic monopole and Dirac string dynamics in spin ice. Nat. Phys. 5, 258–261 (2009).
[15] D. J. P. Morris, D. A. Tennant, S. A. Grigera, B. Klemke, C. Castelnovo, R. Moessner, C. Czternasty, M. Meissner, K. C. Rule, J.-U. Hoffmann, K. Kiefer, S. Gerischer, D. Slobinsky, and R. S. Perry. Dirac Strings and Magnetic Monopoles in the Spin Ice Dy₂Ti₂O₇. Science 326, 411–414 (2009).
[16] Sean R. Giblin, Steven T. Bramwell, Peter C. W. Holdsworth, Dharmalingam Prabhakaran, and Ian Terry. Creation and measurement of long-lived magnetic monopole currents in spin ice. Nat. Phys. 7, 252–258 (2011).
[17] Bruno Tomasello, Claudio Castelnovo, Roderich Moessner, and Jorge Quintanilla. Correlated Quantum Tunneling of Monopoles in Spin Ice. Phys. Rev. Lett. 123, 067204 (2019).
[18] Yann Perrin, Benjamin Canals, and Nicolas Rougemaille. Extensive degeneracy, Coulomb phase and magnetic monopoles in artificial square ice. Nature 540, 410–413 (2016).
[19] H. Fukazawa, R. G. Melko, R. Higashinaka, Y. Maeno, and M. J. P. Gingras. Magnetic anisotropy of the spin-ice compound Dy₂Ti₂O₇. Phys. Rev. B 65, 054410 (2002).
[20] Leon Balents. Spin liquids in frustrated magnets. Nature 464, 199–208 (2010).
[21] G. Baskaran, Z. Zou, and P. W. Anderson. The resonating valence bond state and high-T_c superconductivity — A mean field theory. Solid State Commun. 63, 973–976 (1987).
[22] P. W. Anderson, G. Baskaran, Z. Zou, and T. Hsu. Resonating-valence-bond theory of phase transitions and superconductivity in La₂CuO₄-based compounds. Phys. Rev. Lett. 58, 2790–2793 (1987).
[23] G. Baskaran and P. W. Anderson. Gauge theory of high-temperature superconductors and strongly correlated Fermi systems. Phys. Rev. B 37, 580–583 (1988).
[24] Lucile Savary and Leon Balents. Quantum spin liquids: a review. Rep. Prog. Phys. 80, 016502 (2017).
[25] Alexei Yu. Kitaev. Fault-tolerant quantum computation by anyons. Ann. Phys. (N. Y.) 303, 2–30 (2003).
[26] Alexei Kitaev and Chris Laumann. Topological quantum phases and quantum computation. In Jesper Jacobsen, Stephane Ouvry, Vincent Pasquier, Didina Serban, and Leticia Cugliandolo, editors, Exact Methods in Low-dimensional Statistical Physics and Quantum Computing, volume 89 of Lecture Notes of the Les Houches Summer School, chapter 4. Oxford University Press, Oxford, U.K. (2008), arXiv:0904.2771.
[27] Yi Zhou, Kazushi Kanoda, and Tai-Kai Ng. Quantum spin liquid states. Rev. Mod. Phys. 89, 025003 (2017).
[28] Nic Shannon, Tsutomu Momoi, and Philippe Sindzingre. Nematic Order in Square Lattice Frustrated Ferromagnets. Phys. Rev. Lett. 96, 027213 (2006).
[29] John A. Mydosh and Peter M. Oppeneer. Colloquium: Hidden order, superconductivity, and magnetism: The unsolved case of URu₂Si₂. Rev. Mod. Phys. 83, 1301–1322 (2011).
[30] Joseph A. M. Paddison, Henrik Jacobsen, Oleg A. Petrenko, Maria Teresa Fernández-Díaz, Pascale P. Deen, and Andrew L. Goodwin. Hidden order in spin-liquid Gd₃Ga₅O₁₂. Science 350, 179–181 (2015).
[31] Yao-Dong Li, Xiaoqun Wang, and Gang Chen. Hidden multipolar orders of dipole-octupole doublets on a triangular lattice. Phys. Rev. B 94, 201114 (2016).
[32] H. Takatsu, S. Onoda, S. Kittaka, A. Kasahara, Y. Kono, T. Sakakibara, Y. Kato, B. Fåk, J. Ollivier, J. W. Lynn, T. Taniguchi, M. Wakita, and H. Kadowaki. Quadrupole Order in the Frustrated Pyrochlore Tb_2+xTi_2-xO_7+y. Phys. Rev. Lett. 116, 217201 (2016).
[33] Qiang Luo, Shijie Hu, Bin Xi, Jize Zhao, and Xiaoqun Wang. Ground-state phase diagram of an anisotropic spin-½ model on the triangular lattice. Phys. Rev. B 95, 165110 (2017).
[34] A. F. Andreev and I. A. Grishchuk. Spin Nematics. J. Exp. Theor. Phys. 87, 467–475 (1984).
[35] Andrey V. Chubukov. Fluctuations in spin nematics. J. Phys.: Condens. Matter 2, 1593 (1990).
[36] Tsutomu Momoi, Philippe Sindzingre, and Nic Shannon. Octupolar Order in the Multiple Spin Exchange Model on a Triangular Lattice. Phys. Rev. Lett. 97, 257204 (2006).
[37] Tsutomu Momoi, Philippe Sindzingre, and Kenn Kubo. Spin Nematic Order in Multiple-Spin Exchange Models on the Triangular Lattice. Phys. Rev. Lett. 108, 057206 (2012).
[38] Roderich Moessner and John T. Chalker. Low-temperature properties of classical geometrically frustrated antiferromagnets. Phys. Rev. B 58, 12049–12062 (1998).
[39] Andreas Läuchli, Frédéric Mila, and Karlo Penc. Quadrupolar Phases of the S=1 Bilinear-Biquadratic Heisenberg Model on the Triangular Lattice. Phys. Rev. Lett. 97, 087205 (2006).
[40] Congjun Wu. Orbital Ordering and Frustration of p-Band Mott Insulators. Phys. Rev. Lett. 100, 200406 (2008).
[41] J. Yamaura, K. Ohgushi, H. Ohsumi, T. Hasegawa, I. Yamauchi, K. Sugimoto, S. Takeshita, A. Tokuda, M. Takata, M. Udagawa, M. Takigawa, H. Harima, T. Arima, and Z. Hiroi. Tetrahedral Magnetic Order and the Metal-Insulator Transition in the Pyrochlore Lattice of Cd₂Os₂O₇. Phys. Rev. Lett. 108, 247205 (2012).
[42] M. Mourigal, M. Enderle, B. Fåk, R. K. Kremer, J. M. Law, A. Schneidewind, A. Hiess, and A. Prokofiev. Evidence of a Bond-Nematic Phase in LiCuVO₄. Phys. Rev. Lett. 109, 027203 (2012).
[43] O. Janson, J. Richter, P. Sindzingre, and H. Rosner. Coupled frustrated quantum spin-½ chains with orbital order in volborthite Cu₃V₂O₇(OH)₂ · 2H₂O. Phys. Rev. B 82, 104434 (2010).
[44] R. Wawrzyńczak, Y. Tanaka, M. Yoshida, Y. Okamoto, P. Manuel, N. Casati, Z. Hiroi, M. Takigawa, and G. J. Nilsen. Classical Spin Nematic Transition in LiGa_0.95In_0.05Cr₄O₈. Phys. Rev. Lett. 119, 087201 (2017).
[45] A. Orlova, E. L. Green, J. M. Law, D. I. Gorbunov, G. Chanda, S. Krämer, M. Horvatić, R. K. Kremer, J. Wosnitza, and G. L. J. A. Rikken. Nuclear Magnetic Resonance Signature of the Spin-Nematic Phase in LiCuVO₄ at High Magnetic Fields. Phys. Rev. Lett. 118, 247201 (2017).
[46] Jacques Villain, R. Bidaux, J.-P. Carton, and R. Conte. Order as an effect of disorder. J. Phys. France 41, 1263–1272 (1980).
[47] Doron Bergman, Jason Alicea, Emanuel Gull, Simon Trebst, and Leon Balents. Order-by-disorder and spiral spin-liquid in frustrated diamond-lattice antiferromagnets. Nat. Phys. 3, 487–491 (2007).
[48] John T. Chalker, Peter C. W. Holdsworth, and E. F. Shender. Hidden order in a frustrated system: Properties of the Heisenberg Kagomé antiferromagnet. Phys. Rev. Lett. 68, 855–858 (1992).
[49] I. Ritchey, P. Chandra, and P. Coleman. Spin folding in the two-dimensional Heisenberg kagomé antiferromagnet. Phys. Rev. B 47, 15342–15345 (1993).
[50] Michael E. Zhitomirsky. Field-Induced Transitions in a Kagomé Antiferromagnet. Phys. Rev. Lett. 88, 057204 (2002).
[51] Michael E. Zhitomirsky. Octupolar ordering of classical kagome antiferromagnets in two and three dimensions. Phys. Rev. B 78, 094423 (2008).
[52] Mathieu Taillefumier, Owen Benton, Han Yan, L. D. C. Jaubert, and Nic Shannon. Competing Spin Liquids and Hidden Spin-Nematic Order in Spin Ice with Frustrated Transverse Exchange. Phys. Rev. X 7, 041057 (2017).
[53] Owen Benton, Ludovic D. C. Jaubert, Rajiv R. P. Singh, Jaan Oitmaa, and Nic Shannon. Quantum Spin Ice with Frustrated Transverse Exchange: From a π-Flux Phase to a Nematic Quantum Spin Liquid. Phys. Rev. Lett. 121, 067201 (2018).

The term “soft mode” usually refers to any kind of gapless mode, including those with linearly vanishing dispersions; here, modes need to be even “softer”, with at-most quadratic dispersion, to fluctuate appreciably down to the low temperatures required for order to emerge. ↩

Thesis handed in 🥳

Fri, 30 Aug 2019 13:43:40 +0000

Over the past few month, I have been busy finishing yet another SVM-related paper (more on that in an upcoming post) but also writing my PhD thesis which I am happy to have handed in last week.

As you do, I tried to shove as much of my research into it as possible and the final couple of weeks in particular have been quite stressful. It is thus with great relieve that this chapter of my career has (almost – pending the defense) come to a close.

At the same time, August is the last month of my working at LMU and also marks the end of my full-time scientific career as I have decided not to seek out any post-doc positions. Rather, I’m now on the look out for attractive jobs in industry, as a software engineer or the like. While I am somewhat saddened to abandon physics in general, and our work on frustrated magnetism in particular, I’m all the more excited to face the new challenges which lay ahead.

There’s still a bit of “legacy work” to be done on the TK-SVM project. For one, I will update the published code to a new version containing additional tools developed during the analysis of the XXZ pyrochlore model for the recent preprint. ~~I will also put out another blog post or two on a WebAssembly-based interactive browser version of the graph analysis.~~¹ Finally, I’m going to publish some excerpts from the introduction of my thesis on this blog. ~~The full thesis will also eventually be published somewhere on here after the defense.~~ Update: the thesis is now published.

I might still be involved with some of the future research revolving around our TK-SVM method down the line in a less active capacity in my spare time. For now, I look forward to shifting my attention away from that and to gather experience in both new tech and as pertaining to the non-academic workplace.

Update: I’ve not yet come around to do so and I’m not sure I will any time soon. The interactive browser version is however available here without further information. It is hopefully pretty self-explanatory when compared to the corresponding figures in the paper. ↩

Two papers published in PRB

Sun, 10 Mar 2019 17:10:34 +0000

It’s my pleasure to annouce that as of last week, both of the papers we worked on last year have been published in Phys. Rev. B:

The Rapid Communication was even selected as an Editors’ Suggestion, giving it a few days of exposure on PRB’s home page:

Screenshot of the PRB home page; Feb 11, 2019

Along with the second paper which investigates the use of multiclassification, we have made the corresponding source codes openly available under the terms of the GNU General Public License version 3. An extensive README file explains how to build, use, and extend our codes to reproduce our findings, or even adapt the framework to your own simulations. (If you intend to do the latter, please feel free to reach out to us, though.)

Source Code on GitLab Source Code on GitHub

Recursive visitors from fixed-point combinators

Sun, 03 Feb 2019 15:34:57 +0000

Variadically inheriting from lambdas

In the previous post, we left off with a simple visitor functor Printer which provides two overloads for operator() which are called by std::visit depending on the type realized in the variant.

#include <iostream>
#include <string>
#include <variant>

using Data = std::variant<int, std::string>;

struct Printer {
    void operator()(int i) const {
        std::cout << "got an int: " << i << std::endl;
    }
    void operator()(std::string const& s) const {
        std::cout << "got a string: " << s << std::endl;
    }
};

int main() {
    Data d[2] = {42, "Hello, world!"};
    std::visit(Printer{}, d[0]); // 'got an int: 42'
    std::visit(Printer{}, d[1]); // 'got a string: Hello, world!'
}

This is easy enough, but there’s an even simpler way of achieving the same that was recently featured by Jason Turner on C++ Weekly Ep. 134: we define a generic functor visitor which variadically inherits from a bunch of lambdas:

template <typename... Bases>
struct visitor : Bases... {
    using Bases::operator()...;
};

template <typename... Bases>
visitor(Bases...) -> visitor<Bases...>;

The struct merely contains a variadic using declaration (C++17) which introduces all the call operators of the base classes into the derived class definition. Lastly, we declare a template parameter deduction guide. This allows us to construct a visitor through aggregate initialization and have the template parameters inferred. This is non-optional if we want to inherit from inline lambdas whose type cannot be expressed in closed form. If you want to know more about the subtleties of this, I highly recommend watching Jason’s video.

Thus, we can use visitor to quickly define a one-time-use visitor:

using Data = std::variant<int, std::string>;

int main() {
    Data d[2] = {42, "Hello, world!"};
    for (Data & x : d)
        std::visit(visitor {
                [] (int i) {
                    std::cout << "got an int: " << i << '\n';
                },
                [] (std::string const& s) {
                    std::cout << "got a string: " << s << '\n';
                }
            }, x);
}

The advantages of this approach are basically those of using lambdas in place of regular functions in general: we increase readability by keeping the logic in the place of its (one-time) use. Another upside is the ability to capture variables from the local scope.

The visitor template obviously needs to be defined only once. Its definition is simple enough to stash it into some utility header. In case you a using (a fairly recent version of) Boost anyway, the new meta-programming library Boost Hana offers a definition called boost::hana::overload straight out of the box.

Recursive visitors

One problem arises when we want to call the visitor recursively. Consider the following example of a variant that’s supposed to represent a value in a JSON file which can be either a number, a string, or an array or ‘object’ (a.k.a. dictionary or map) of JSON values themselves. JSON also allows null and Boolean values, which are omitted here for brevity.

namespace json {
    struct array;  // forward declaration
    struct object; // forward declaration

    using value = std::variant<int, std::string, array, object>;

    struct array : std::vector<value> {
        using std::vector<value>::vector;
    };

    struct object : std::map<std::string, value> {
        using std::map<std::string, value>::map;
    };
}

With this, we can list-initialize a nested value object rather elegantly:

int main() {
    json::value val = json::object{
        {"title", "Can Quantum-Mechanical Description of Physical"
                  " Reality Be Considered Complete?"},
        {"year", 1935},
        {"authors", json::array{
                "A. Einstein",
                "B. Podolsky",
                "N. Rosen"
            }}
    };
    std::cout << val << std::endl; // to be implemented
}

In order to serialize a json::value object into valid JSON, we again resort to the visitor pattern. As a fully-fledged functor class, the visitor might look like this:

namespace json {
    struct printer {
        std::ostream & os;

        std::ostream& operator()(int x) const {
            return os << x;
        }
        std::ostream& operator()(std::string const& s) const {
            return os << std::quoted(s);
        }
        std::ostream& operator()(array const& a) const {
            os << '[';
            for (auto const& v : a)
                std::visit(*this, v) << ',';
            return os << ']';
        }
        std::ostream& operator()(object const& obj) const {
            os << '{';
            for (auto const& [k, v] : obj) {
                os << std::quoted(k) << ':';
                std::visit(*this, v) << ',';
            }
            return os << '}';
        }
    };

    std::ostream& operator<<(std::ostream& os, value const& val) {
        return std::visit(printer{os}, val);
    }
}

For the above main() function, this will produce the output:

{"authors":["A. Einstein","B. Podolsky","N. Rosen",],"title":"Can Quantum-Mechanical Description of Physical Reality Be Considered Complete","year":1935,}

which is valid JSON when disregarding the occurrence of trailing commas (which are technically not allowed).

Note the use of recursion in the overloads for array and object: the visitor passes itself on to std::visit which in turn calls its appropriate overloads for the array elements and values contained in the object. When attempting to realize the same kind of visitor by inheriting from lambdas, we however run into a problem:

namespace json {
    std::ostream& operator<<(std::ostream& os, value const& val) {
        return std::visit(visitor{
                [&](int x) -> std::ostream& { return os << x; },
                [&](std::string const& s) -> std::ostream& {
                    return os << std::quoted(s);
                },
                [&](array const& a) -> std::ostream& {
                    os << '[';
                    for (auto const& v : a) {
                        // std::visit(*this, v) << ',';
                    }
                    return os << ']';
                },
                [&](object const& obj) -> std::ostream& {
                    os << '{';
                    for (auto const& [k, v] : obj) {
                        os << std::quoted(k) << ':';
                        // std::visit(*this, v) << ',';
                    }
                    return os << '}';
                }
            }, val);
    }
}

While the overloads for int and std::string are straight-forwardly implemented (streaming to os which is captured by reference), we have no means of invoking the visitor recursively. Passing *this to std::visit (as illustrated in the comments) is bound to fail: the lambdas are defined outside of any class so there is no this to be captured. Further, before the lambdas are fully defined, the derived visitor type is incomplete and could not even be forward-declared because its Bases... parameter pack cannot be specified in closed form.

This makes a naive implementation through inheritance from lambdas impossible. Fortunately, the situation can be salvaged using a concept from theoretical computer science that has major implication for recursion in general: the fixed-point combinator.

Lambda calculus

Before we introduce the fixed-point combinator, let’s get acquainted with the weird notation known as lambda calculus. The function of one variable that squares its argument would traditionally be written as \(f(x)=x^2\), or more mathematically, \(f: \mathbb{R}\to\mathbb{R}, x\mapsto x^2\). In lambda calculus, this becomes \(f = \lambda x\,.\,x^2\). Note that the expression on the right-hand side of the equality sign completely defines the function and it is not even necessary to give it a name (\(f\)). For this reason, lambdas are often referred to as anonymous functions. Further, the name of the argument is just a placeholder, i.e. \(\lambda x\,.\,x^2=\lambda y\,.\,y^2\).

When a lambda is invoked, i.e. evaluated for a specific value of its argument, the parentheses may be omitted if this does not cause confusion, e.g. \((\lambda x\,.\,x^2)\,5=5^2=25\).

A function of two variables, say \(f(x,y)=y^x\), can be written as \(\lambda (x,y)\,.\,y^x\), but in many cases it is more convenient to express the same as a higher-order function:

\[f = \lambda x\,.\,\lambda y\,.\,y^x\]

This is to be understood as a function of one variable (\(x\)), returning functions of another variable (\(y\)). This procedure of going from one function of two variables to a higher-order function (one returning functions) of one variable, is known as Currying.

The fixed-point combinator

Say, we wanted to define the factorial function \(n! = n\times(n-1)\times\dots\times 2\times 1\) recursively. In traditional function notation, we’d write

\[f(n) = \begin{cases} n\times f(n-1), & n > 0,\\ 1, & n = 0. \end{cases}\]

However, this definition is self-referential: we are using the function \(f\) in its own definition. We run into deep water when trying to write down the corresponding lambda expression: lambdas are anonymous, so we don’t have a name to refer to the thing we are trying to define. Straightforward recursion is not possible in lambda calculus.

What we can do, however, is define a helper function \(g\) of two arguments: a function \(f\) that we think of as our sought-after factorial function and the integer \(n\):

\[g(f, n) = \begin{cases} n\,f(n-1), & n > 0,\\ 1, & n = 0. \end{cases}\]

There is no recursion happening here, so this may be written as a lambda expression:

\[g = \lambda f\,.\,\lambda n\,.\,\begin{cases} n\,f(n-1), & n > 0,\\ 1, & n = 0. \end{cases}\]

This alone does not constitute a solution, since in order to define the factorial function itself, we still need to invoke some sort of recursion:

\[f(n) = g(f, n).\]

If we omit the argument \(n\) for a moment (through currying), this reduces to \(f = g(f)\) and is called a fixed-point equation. Solutions for \(f\) that satisfy this equation are called fixed points since \(g\) maps those to themselves. Thus, the factorial function \(f\) is a fixed point of the helper function \(g\).

How does one find a fixed point of a function? Turns out that within the limits of lambda calculus, one can construct a lambda function that maps functions to (one of) their fixed-point(s). Such a function is called a fixed-point combinator. One particular construction is the so-called Y combinator which was discovered by Haskell Curry (who already has a programming language and the Currying procedure named after him). The lambda expression for the Y combinator looks like this:

\[\mathsf{Y} = \lambda f \,.\, (\lambda x \,.\, f(x\ x))(\lambda x \,.\, f(x\ x)).\]

This may look intimidating at first, but honestly it’s quite simple. To verify that it in fact works as advertized, we first apply it to some function \(g\),

\[\mathsf{Y}g = (\lambda x \,.\, g(x\ x))(\lambda x \,.\, g(x\ x)),\]

where we just replaced the “independent variable” \(f\) with the concrete function \(g\) we’re acting upon. We follow the same pattern in evaluating the right-hand side: the first pair of parentheses defines a lambda function of \(x\) which is then evaluated at the point given by the second pair of parentheses, \(\lambda x\,.\, g(x\ x)\),

\[\mathsf{Y}g = g((\lambda x \,.\, g(x\ x))(\lambda x \,.\, g(x\ x))) = g(\mathsf{Y}g).\]

In the last equality, we have just recovered the expression for \(\mathsf{Y}g\) from the previous line. Hence, \(\mathsf{Y}g\) is indeed a fixed point of \(g\).

This immediately yields the solution to our problem of defining the factorial function \(f\) in lambda calculus: it is simply given by \(f = \mathsf{Y}g\). The fixed point in this case is not a number, but a function (of \(n\)), but that is not a problem. (In fact, numbers are functions in lambda calculus.)

Thus, the Y combinator allows the introduction of recursion to lambda calculus without changing its axioms or explicitly introducing some sense of self-referentiality into the formalism. In fact, lambda calculus has been proven to be Turing complete, i.e. any program can be expressed as a lambda expression. To learn more, I recommend the videos on lambda calculus in general and the Y combinator in particular on the Computerphile Youtube channel.

Using the fixed-point combinator in C++

When we tried to define the recursive visitor to serialize JSON, we faced a similar problem to the one that lambda calculus faced conceptually when it comes to recursion. This raises the question of whether we can also solve it by similar means; the answer to which is of course ‘yes’.

We can write a C++ version of the fixed-point combinator:

#include <utility>

template <typename G>
struct Y {
    template <typename... X>
    decltype(auto) operator()(X &&... x) const &
    {
        return g(*this, std::forward<X>(x)...);
    }
    G g;
};

template <typename G>
Y(G) -> Y<G>;

Albeit I called it affectionally Y for brevity, it does not follow the same construction as the Y combinator, but rather it is actually implemented in a self-referential way, invoking g with itself as first argument and then forwarding any other arguments in the parameter pack X.

For example, to realize the factorial function without any recursion or captures, we can write:

auto g = [](auto f, int n) -> int {
    if (n > 0)
        return n * f(n - 1);
    else
        return 1;
};

auto f = Y{g};

std::cout << f(5) << std::endl; // outputs 120

Note that we used auto as the argument type in the definition of \(g\), making this a generic lambda. Thus, the return type cannot be inferred and needs to be specified with trailing return type syntax.

The above code compiles with g++ 7 or newer, as well as clang++ 5 or newer. Clang actually evaluates the expression f(5) at compile time with optimization level -O3. GCC does not, but can be forced to do so by declaring the variables g and f, as well as the Y::operator() function constexpr.

Boost provides a similar implementation for the fixed-point combinator in the new Hana library called boost::hana::fix.

Recursive serialization of JSON

Finally, let’s bring it all together and implement the serialization of JSON using a variant visitor derived from lambdas, and by reintroducing recursion using the fixed-point combinator.

namespace json {
    std::ostream& operator<<(std::ostream& os, value const& val) {
        return std::visit(Y{visitor{
                [&](auto, int x) -> std::ostream& {
	                return os << x;
	            },
                [&](auto, std::string const& s) -> std::ostream& {
                    return os << std::quoted(s);
                },
                [&](auto self, array const& a) -> std::ostream& {
                    os << '[';
                    for (auto const& v : a) {
                        std::visit(self, v) << ',';
                    }
                    return os << ']';
                },
                [&](auto self, object const& obj) -> std::ostream&
                {
                    os << '{';
                    for (auto const& [k, v] : obj) {
                        os << std::quoted(k) << ':';
                        std::visit(self, v) << ',';
                    }
                    return os << '}';
                }
            }}, val);
    }
}

Note the changes compared to the version at the beginning of this post: the individual lambda overloads have an additional first argument auto self and the whole visitor is wrapped in a Y combinator.

While the contents of this post are certainly a lot to take in, especially so if lambda calculus is new to you, the resulting solutions are quite simple to use and I’ve found myself using them loads since. It’s a case where concepts from theoretical computer science can be applied to real code.

Type safety, variants, and visitors

Sun, 21 Oct 2018 19:47:08 +0000

Variants vs. unions

C++17 came with library support for type-safe unions in the form of std::variant. A variant will hold exactly one instance of its template parameter types. For example, objects of type

using foo = std::variant<int, std::string>;

can hold either an int, or a std::string. In plain old C, one would use a union type in this situation:

union bar {
    int i;
    std::string s;
};

A variable of type bar could hence be accessed as an int by using the i member and as a std::string by using s, implicitly performing an reinterpret_cast of the data. reinterpret_casts are frowned upon, and rightly so, as they open the door to undefined behavior, and this extends to unions. It is up to the programmer to keep track of the realization that is used. For member types with non-trivial constructors or destructors (such as std::string), one has to carefully provide those explicitly to not risk memory leaks or segfaults. In practice, one will almost always create a tagged union, i.e. associate the union with a tag (index) to indicate the realized alternative.

The std::variant is in essence such a tagged union. This is also apparent from the sizeof the types: on a 64-bit machine sizeof(bar) is 32 bytes which is identical to sizeof(std::string), the int alternative being significantly smaller at 4 bytes. In contrast, sizeof(foo) yields 40 bytes, where the additional 8 bytes are reserved for the index (or tag) which is itself a std::size_t. Thus, the variant knows which alternative it holds, lets us test against it, and provides safe constructors and destructors. It is still possible to attempt to access the wrong alternative, but this will be caught at run-time and an exception will be thrown.

foo f = "Hello, world";   // realizes the std::string alternative
int i = std::get<int>(f); // throws std::bad_variant_access

Thus, i will not be assigned with the first four bytes of the std::string object; no undefined behavior can arise. This renders std::variant a type-safe replacement of unions.

When the realized alternative is not apparent from the context, one will often end up with code that tests for each of the realizations and conditionally executes a code branch:

if (std::holds_alternative<int>(f)) {
    std::cout << "got an int: " << std::get<int>(f) << std::endl;
} else {
    std::cout << "got a string: " << std::get<std::string>(f)
              << std::endl;
}

This can get hairy when a lot of alternatives exist. If additional alternatives are added to the variant, the above code would execute the else branch for any new non-int type. This is not a big deal since std::get would throw if used improperly; still, it would be preferable if the compiler had a way of checking for an exhaustive treatment of all possible alternatives. Visitors can achieve just that.

The visitor pattern

The main goal of the visitor pattern is to achieve a separation between code that defines a data structure and that which operates on the data. This makes it well-suited to variants, since one would typically not derive directly from the variant, but work with the generic variant type, but still be able to perform arbitrary operations one the data contained in the variant.

The visitor pattern however predates std::variant or even boost::variant. It originates from object-oriented programming where dynamic dispatch is used to select the proper overload. Consider the following program:

#include <iostream>
#include <string>

struct Int;    // forward declaration
struct String; // forward declaration

// Abstract Visitor interface
struct Visitor {
    virtual void operator()(Int & d) = 0;
    virtual void operator()(String & d) = 0;
};

struct Data {
    virtual void visit(Visitor && v) = 0;
};

struct Int : Data {
    int i;
    Int(int i) : i(i) {}
    void visit(Visitor && v) override {
        v(*this);
    }
};

struct String : Data {
    std::string s;
    String(std::string const& s) : s(s) {}
    void visit(Visitor && v) override {
        v(*this);
    }
};

struct Printer : Visitor {
    void operator()(Int & d) override {
        std::cout << "got an int: " << d.i << std::endl;
    }
    void operator()(String & d) override {
        std::cout << "got a string: " << d.s << std::endl;
    }
};

int main() {
    Int i {42};
    String s {"Hello, world!"};
    Data *d[2] = {&i, &s};
    d[0]->visit(Printer{}); // 'got an int: 42'
    d[1]->visit(Printer{}); // 'got a string: Hello, world!'
}

Data is the common abstract base class of two data “structures”, Int and String. These must implement a visit member function, invoking the call operator on a Visitor functor that is passed along. The bodies of Int::visit and String::visit may look alike but in fact these invoke different overloads of operator() since *this has a different type (Int& vs. String&). The concrete visitor class Printer in turn derives from the interface Visitor.

Crucially, the data classes Int and String don’t need any knowledge of Printer. The user may implement arbitrary visitors by deriving from Visitor and handling each of the alternatives in a separate overload of the call operator. No explicit type checks and no downcasts are required which makes this pattern quite elegant. On the downside, the whole thing relies on run-time polymorphism and dynamic dispatch and the associated vtable lookups incur a significant performance cost (which may be partly negated if devirtualization optimization can be used). The derived classes will typically also need to be allocated dynamically, adding an additional level of indirection and breaking memory locality compared to variants.

Visitation of `std::variant`

Rather than relying on dynamic polymorphism, std::variant uses the visitor pattern to achieve the same thing with static polymorphism (i.e. generic programming). std::visit is called on an arbitrary variant and a visitor functor which similarly provides overloads of the call operator (but is not derived from any interface). Internally, std::visit will use holds_alternative successively and call the visitor with a reference to its contents. This ensures that the visitor handles all alternatives of the variant, giving a hard compiler error should any overload be missing. The call of the visitor is dispatched statically, meaning no vtable lookups are necessary, the function bodies can be inlined and branch prediction and vectorization can be used.

The equivalent to the above example program, realized with variants, becomes much simpler:

#include <iostream>
#include <string>
#include <variant>

using Data = std::variant<int, std::string>;

struct Printer {
    void operator()(int i) const {
        std::cout << "got an int: " << i << std::endl;
    }
    void operator()(std::string const& s) const {
        std::cout << "got a string: " << s << std::endl;
    }
};

int main() {
    Data d[2] = {42, "Hello, world!"};
    std::visit(Printer{}, d[0]); // 'got an int: 42'
    std::visit(Printer{}, d[1]); // 'got a string: Hello, world!'
}

TL;DR Don’t use unions anymore. Variants offer type safety and better compiler diagnostics with less boilerplate. std::visit makes it easy to apply the visitor pattern without setting up intricate class hierarchies, while achieving data/algorithm separation.

Jonas Greitemann

The C++ range adaptor pipe operator is associative

Tina’s sliding_mean example

Generalizing the function to return ranges

Generalizing function arguments to accept ranges

Composite range adaptors

EuroRust 2022 Trip Report

Integration and interop with other languages

Rust and the Web

Case studies

Governance and Organizations

C++ on Sea 2022 Trip Report

Highlights

Honourable mentions

Good overview talks

Mateusz Pusz: Sneak Peek C++23

Closing remarks

Joining MVTec

Version 3 release of TK-SVM — Wrapping up

Frustrated magnetism: Thesis motivation

From water to spin ice

Gauge theoretical description and magnetic monopoles

Classical and quantum spin liquids

Hidden order

Premise of my PhD thesis

References

Thesis handed in 🥳

Two papers published in PRB

Recursive visitors from fixed-point combinators

Variadically inheriting from lambdas

Recursive visitors

Lambda calculus

The fixed-point combinator

Using the fixed-point combinator in C++

Recursive serialization of JSON

Type safety, variants, and visitors

Variants vs. unions

The visitor pattern

Visitation of std::variant

Tina’s `sliding_mean` example

Visitation of `std::variant`