Navigation

Engineering

#Presentation

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

Designing an AI search engine from scratch in the 2020's

Study 19 min.
This is a follow-up on the previous Websites suck, which covered the preliminary information retrieval step. #Introduction On the open-source planet, in the 2020’s, information is scattered over many websites : scientific journals for theory, specification sheets for standards and protocols, software documentation for “how to use tool”, blogs and Youtube tutorials for “how to achieve goal”, forums and support for “how to solve problems”, Github for “what is known to break” and “why design (or lack thereof) was done this way”, sourcecode for implementation details, and books for everything considered worthy of paiement for access.
Lire la suite →

Stochastic photographic grain synthesis from crystallographic structure simulation

Study 18 min.
The silver halide film grain has an unique look that introduces some texture in smooth image areas, where digital imagery may look synthetic and too clean. Emulating this effect in digital photography cannot be done by simply adding gaussian or poissonian noise to the image, since silver halide grain has varying shapes and sizes. There are two techniques to do it : overlaying an image of natural grain sampled on scanned negatives, on top of the digital image (typically using soft-light or hard-light blend modes ), synthesizing grain from an a-priori model and the image content.
Lire la suite →

Websites suck.

Opinion 6 min.
I have spent the past month working on an AI-based search engine. When you go on darktable sub-Reddit, you will find the question “why do lighttable’s thumbnails look different from darkroom preview” asked every next week. The question is answered many times on this sub-Reddit, on various forums, and I even put the answer on the main Readme file, displayed on the Github main page of the software. To no avail.
Lire la suite →

Who are the darktable users in 2020 ?

Study 22 min.
The core basics of design are to know for whom you design, that is who are the users of your solution, what they expect and what they need. It is also necessary to assess if the actual user of your product is the one you designed it for in the first place, that is, who is missing from your user base, to avoid the survivor bias . This is unfortunately overlooked in FLOSS and it is often not well regarded to collect user data.
Lire la suite →


Pages :
 ◉ 
 ◉ 

Author

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.

Credits

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.