Today I attended a talk by Dr. Florian Mannseicher on FutuRSI—an “initiative […] to conceptualise a German research software institution”. The discussion around critical challenges and concrete needs facing the research software community resonated with me—particularly because I discussed many of these same issues—still unresolved today—in 2020 in “Software Engineering as Scientific Infrastructure”. I believe FutuRSI should be the place to solve what I wrote about back then. I’ll elaborate in this post. Since 2020 our ability to talk about these issues has improved. “Research Software Engineering” (RSE) has become a widely used term. There are conferences on RSE. But the main problem has not been addressed—in my opinion.
My vision for an interdisciplinary RSE institute: how to actually help scientists
Virtual Trip Report: WG21 Kona 2025
After the CD (committee draft) is out, WG21 is in bug fixing mode. Consider NB comments as the tickets that force us to consider a resolution and provide an answer. Such issues can either be design issues or wording issues (where wording does not match stated design intent). Besides NB comments, many library issues had been filed and prioritized independently, which led to several categorized as must/should fix before the standard is finalized.
The story of regularity and std::simd
In this post I will talk about regularity and why
std::regular<std::simd<int>> needs to be false in order to preserve
regularity at the level where it matters: equational reasoning. The issue of
regularity came up repeatedly when discussing the design of std::simd for
C++26. (It also came up in 2017 for std::experimental::simd.) My goal for
this post is the exploration of options and their consequences. There’s a lot
more to be said, but this post is already too long. In any case, when talking
about regularity, we need start with “Elements of Programming”, the book that
introduced the concept:
A type is regular if and only if its basis includes equality, assignment, destructor, default constructor, copy constructor, total ordering, and underlying type. […]
Algorithms are abstract when they can be used with different models satisfying the same requirements, such as associativity. Code optimization depends on equational reasoning; unless types are known to be regular, few optimizations can be performed.
Alexander Stepanov, Paul McJones — Elements of Programming (EoP)
Data-Structure Vectorization
One of the major benefits of type-based vectorization is data-structure vectorization. I’ll introduce and hopefully motivate the pattern in this post.
Software Engineering as Scientific Infrastructure
A “brain dump” …