I do research and development in applied mathematics for digital art matters, mostly photography, typically involving some physics and computer programming. With the maths models I built, I design end-user software and applications. For the applications I built, I design websites, write documentations and shoot educational videos. For the (scattered) documentations I wrote, I designed an (unified) AI-driven search engine.

I’m one of the very few open-source developers who write down the maths before opening their IDE to code anything silly. I have lost too much time because someone (sometimes me) tried hack something quickly and validated it on a non-significant sample where “it worked”. From cursory reading of such code, I can nowadays typically predict in which cases the hacks will fail, but without being able to propose a fix, because you can’t fix something that doesn’t state its goal in maths terms (especially since it gets buried into contextual technicalities as soon as computers are involved). Theory and abstraction win over inductivism  and should be used from the inception of the project if you want to make good use of your time.

Engineering is the art of designing solutions supported by scientific knowledge and optimized by numerical simulation.

Designing is deciding, deciding is choosing priorities, and no amount of science will ever tell what you should rather choose: it is a discussion between you and your values. What science tells engineers is how to achieve a goal, not which goal to pick. What engineers sometimes forget is they are only fooling themselves when they hide behind numbers to make their choices look more objective. What non-engineers don’t know is design is not just bending technology to deliver something ASAP: technology is only one mean to an end, not the only one, not always the best one. What both — engineers or not — often overlook is it’s often better, and usually simpler, to fix workflows rather than to fix tools, which involves understanding the needs (past the requests), educating, communicating and changing habits but little to no design.1 Nevertheless, since those are typically not the forte of the guys enjoying science, technology and technics, everyone stays in their silo of expertise, looks for solutions under the lamp post , and when you have a hammer, everything looks like a nail.

Design stems from a definite goal, clearly understood, expressed in technical terms, and objectively measurable. From there, means are unrolled and tuned until we reach optimality of the solution under the given set of constraints. Hacks are thoughtless happy accidents guaranteed to backfire because they start and end with “doing”. You can’t improve on hacks, at best you can add alternative hacks. Since open-source is made of saturday-afternoon pet projects, that’s all you will get for your money though.

This is where I publish those maths, to serve as addendum to my code, and other research or reflections on design and software.

Trained in applied physics, then metrology and finally mechanical engineering, I’m only interested in scientific computation and numerical simulation of physical processes. I had to step on software engineer’s feet because it seems they can’t be entrusted neither with end-user applications nor with vector algebra2. In the process, I have grown an acquired taste for end-user interfaces design.

I only use computers to solve real-world problems that require math processing, don’t mistake me for a technophile. My super-power is I hate programming, which makes me favour lean and simple solutions requiring the least amount of code, libs, deps, tech stacks and therefore the least amount of maintenance.

In a typical day, I write C, OpenCL and Python. I had to become proficient in PHP, Javascript, LaTeX and CSS for my websites and documentations. Since I moved all my websites to Hugo and had to build a custom template from scratch, I started writing a bit of Go as well.

I am very concerned by the inflationary spiral that is software and IT : there is no concept of “enough” software, we always need another layer and it’s often to work around the problems created by the previous layer. It also turns out that the next layer will often be more CPU-hungry than the previous.

That only leads to more energy consumption, device obsolescence, and yet fails to make workers more efficient (or people happier): they have to battle against more ever-changing tools and fix more post-upgrade messes. “One-size-fits-all” ACME  frameworks are to blame here, along with the don’t reinvent the wheel dogma : people will install sprawling toolkits and bloated plugins, only to use a few features that could be replaced by 5-15 lines of custom code, just to avoid writing code themselves (or paying someone to do it). I find that people overestimate the burden that is maintaining their own simple code and underestimate the burden of debugging their whole third-party software stack through possibly-incompatible upgrades.

  1. Of course, in an economy based on selling products and in a world where people hate change, it’s more lucrative to fix tools and sell upgrades. Loop over that for 10 years and that’s how you get madness-triggering software, only good for feature fatigue ↩︎

  2. Brains shutdown when equations show up – maybe one day I will understand why –, but it’s a shame because to avoid a couple of equations, coding monkeys get dozens of PDF pages explaining what they should implement mindlessly, which give them no chance to understand when it would be good to move away from the specifications they are reading. ↩︎

 ◉ 

Latest posts

Color saturation control for the 21th century

75 min.
The saturation control of pretty much all image processing software is an unfortunate misnomer, to say the least. It actually controls either the chroma in Ych-like spaces (computed from CIE Yxy 1931, Yuv or YCbCr spaces), or some remote idea of saturation as used by HSL spaces, which are essentially a polar rewriting of RGB coordinates (usually expressed in sRGB space). The “saturation” as defined by the HSL space has been proven times and times again to hold no perceptual meaning and finds its origin into the first GUI of limited computers doing integer arithmetic.
Lire la suite →

WebP is so great… except it's not

10 min.
I’m a responsible web designer, and as such, since WordPress (finally) accepts media uploads of image/webp MIME type and since all web browsers  newer than september 2020 (even Apple Safari \o/) can display it, I have been moving my photos library to WebP . After all, when you create content, the least you can do is to also provide the smoothest user experience around it. WebP falls close to magical: lookie those file weights !
Lire la suite →

The sRGB book of color

1 min.
This page is inspired by the Munsell book of color. It aims at showing the sRGB gamut volume (all the visible colors that can be encoded as sRGB triplets), projected into a perceptually uniform lightness/chroma space (using JzAzBz color space1), and sliced across hue planes. The sRGB space is the lowest common denominator of all general-audience screens, and is deemed fit to choose colors for GUI, logos and drawings that should sit correctly on any display.
Lire la suite →

WP Scholar

27 min.
WP Scholar provides a clutter-free, direct and fast typing experience for the heavy-duty writers who type a lot every day (technical writers, engineers, analysts, journalists, researchers, scientists, etc.) and are stuck with WordPress as a CMS. It supports equations, footnotes, table of contents, code highlighting, charts drawing, interactive plots and Jupyter notebooks includes, through a direct access to the Markdown and LaTeX code. Then, it refines the typography by converting arrows, quotes and fractions to proper HTML entities, and inserts unbreakable and thin spaces where they belong.
Lire la suite →

Rotation-invariant Laplacian for 2D grids

14 min.
The Laplacian operator $\Delta u$ is the divergence of the gradient, that is the sum of the second-order partial derivatives $\nabla^2 u$ of a multivariate function, which represents the local curvature of this function. This operator is widely used for edge-detection1, as well as in partial-differential equations (Poisson, etc.), and other problems of machine-learning minimisation. For numerical applications in orthogonal graphs, sampled only at integer coordinates (like pixels in an image), a discrete Laplacian has to be used, and several approaches are available, that will be detailed hereafter.
Lire la suite →

Pages :
 ◉ 
 ◉ 


Profile picture

Patrons Income Goal

I use computers to solve real-world problems that require physical simulation and math processing with some user interface on top. My super-power is I hate programming, meaning my programs are simple, lean and to-the-point. I code mostly open-source but my days of free-software advocate ended when I started contributing to said software and realized the average open-source developer is a clueless amateur. I'm done with FLOSS "communities", birthing 5-legged sheeps nobody else wants to use, failing to see the difference between democracy and design by commitee. There is no collective intelligence where there is no structure to organize it between individually-skilled persons, and that's a strong assumption on people's invidual intelligence in a development model where having freetime is the foremost skill.


This website uses neither cookies, nor personal data tracking system, nor advertising service. Multimedia players embedded on pages can use their own cookies and trackers.