We're not playing dices !

Software programming and design is an amazingly complex task. Specially when it concerns numerical applications, that generally require optimization to get results in a reasonable time. For that purpose the basic pattern is usually to write the code as simple as possible, debug it and when it works to begin the optimization process. This asks for some nerves, and patience, two things I usually don't have in real life, but for programming yes.

This design pattern makes sense because we are doing things really sequentially. You first wrote some c++ class and then add some feature progressively, and when you come up with essentially different concept (I mean a concept that should be well separated from the first one), you write an other class and so on...

Usually the class-writing process follows the solving process you have in mind. For instance you have to make some initialization on your model first, then you declare some variables for the computation, the computation then follows and everything ends by post processing some (possibly) meaningful results.

So, basically, inherently, their is a sequential pre-designed pattern that you follow naively. And you always keep in mind the sentence of D. Knuth: "Early optimization is the root of Evil."

Really ? Hum, not sure. At least it is true in our sequential way of working. But if you consider primitive life, or bacteria, may be the picture is different. May be each individual tries to optimize as much as possible, but only the one who have the good genome and initial condition succeed, while the other perish. In their case, optimization and selection is the root of something that works better that whatever we may think about, and possibly the index of God (or the intelligent design maker of our messy, not messiah -bible mistranslation-, universe).

So nonetheless God actually play dices a lot but moreover he left the code programmer with the inability to do the same thing.

Such a pity.

PS: The picture from the dices is taken at the CERN, see this site. Phycisist changed their minds ?

Comments

5 Tips to work with legacy code

As engineers, we like to move things forward and, for those who have a little bit of experience (like me), having to work with legacy code can be a huge set back because we know it can be long, painful and slow-paced. But you don't have to make it harder that it needs to be for you and your team! Below are some common mistakes that occur when working with legacy code and possible ways to overcome them. 1. Should you really use it? That's probably the first and foremost question. Is it really necessary for your application to tap into this legacy code? Have you done extensive researches to see if there isn't a more modern library out there, with better licensing, design, architecture, library initialization, newest code features, documentation, unit tests, whatever than this old piece of code which is on your shelves? In case there is, ponder with caution the possible consequences of any choice, using as many criteria that you care for! Remember that this is an important cha

Shear waves, medecine and brain

Yesterday evening, too bored by what TV was proposing to me, I decided to watch a conference of Mathias Fink , a french researcher working on multidisciplinary application of waves. Specially shear waves. Here is a brief summary of his talk. In solids, waves have two principal components: compression waves (P-waves for primary) moving in the direction of propagation, and shear waves (S-waves, for secondary) that make ripples in the plane orthogonal to that direction. Since compression waves propagate in the direction of propagation, they move faster than shear waves. Usually ultrasound equipment in medicine only use compressional waves. But since human tissues have a high bulk modulus, the P-wave speed is relatively constant (around 1580 m/s). Human tissues are very stiff if you apply isotropic constraints on them (like pressure of water). However M. Fink and his colleagues proposed a new way to investigate human tissues by first sending a strong compressional wave in the tissu

Robust Stable Objects Deformation

In this entry, I'll briefly speak about computing robustly the deformation on a given object represented by a Finite Element mesh. There are a handful of methods to do that more or less robustly, and I'll just discuss them, with a speaking a little bit about their distinctive aspects. Classic lagrangian formulation The most used one in industrial commercial packages (like abaqus, ansys, etc). This is simply a linearization of Green-Lagrange strain tensor and deriving it to get the proper residual and stiffness matrix from one single Newton step. This method is absolutely rigourous, meaning that as long your mechanical behavior is well captured by the strain model you'll get reliable results. However it has two main drawbacks: first you have to be careful when applying new forces or constraints and do it incrementally otherwise you may really blow up your model. For instance applying too much force will cause some elements to invert which won't be re-inverted thanks

New Horizons

Search This Blog