A couple of weeks ago I finally found a (tentative) solution for a problem that I have been mulling over since nearly 20 years. The stubbornness of this problem was only rivaled by its absolute pointlessness and obscurity. Let me elaborate.
RPG obsession
When I was 14 or 15 a friend of mine asked me an innocent question which turned out to have a huge impact on my life - he invited me to join his MERP group. I am not entirely sure whether I already had read Lord of the Rings at that time but I definitely had read the Hobbit, therefore although I totally did *not* get the concept of role playing games I was happy to give it a try.
This triggered an addiction-like fascination for role-playing games, Fantasy and Sci-Fi which only subsided years later. I spent countless hours reading F&SF novels (many of them crappy and most of them crappily translated) and playing MERP, Midgard, Warhammer and RoleMaster (sometimes three to four times a week). Luckily school in Germany usually ends at 13:00, therefore the amount of school hours I ended up sacrificing for my hobby were limited enough to let me get through school more or less successfully.
Reinventing
One peculiar thing about me being obsessed with something is that I usually very quickly begin to feel unsatisfied with the way things are. After a while I start to think 'this is really not good I could easily do this much better'. In many cases this is of course a blatant overestimation of my abilities (or an underestimation of the difficulty of the problem), but usually I end up spending many fun hours on some creative activity and I always learn a lot from it.
Anyways, in the case of the RPG obsession I of course immediately started wanting to design my own RPG system (I think I showed up at my third session of MERP with a new, "improved" character sheet, which was much more complicated and much less useful than the regular one) and my own fantasy world. Since starting small was never my thing this fantasy world of course had to have a complete history, its own biology, its own geology, ... you get the drift.
The problem
One problem I encountered early on was that I would have liked my hand-drawn maps to be an *exact* representation of my invented reality. I really hated the whole idea of having to live with a sub-optimal 2-dimensional projection of a 3-dimensional curved surface. There are some standard solutions to this problem - besides pragmatically accepting the imperfection of maps - such as ignoring it (usually done by fantasy authors), or assuming the world is a disk. However I wanted my world to be plausible with as little alterations to real-world physics as possible. I thought about many different solutions, from the dumb to the downright bizarre, but none of them was even close to satisfying. In the end I had to leave the problem unsolved.
The solution
Until three weeks ago, when I found this. After having believed for many years that the only way a planets shape can change with increasing angular momentum was to become an increasingly flatter oblate spheroid I learned to my utter astonishment that there are at least two other (slightly bizarre) possible shapes. Both of them would not solve my problem but greatly alleviate it. With a cigar-shaped planet the inaccuracies of the map are quite small (as long as you stay away from the ends of the cigar), but rotation speed and gravity should still occur in earth-like combinations. Outlandish but physically plausible - a great solution! Now I just have to find a way to actually calculate which combinations of rotation, density, mass and shape allow for earth-like conditions...
Parting words
As usual for me with these projects, after an initial time of furious activity my interest in my RPG world somewhat tapered off back then and the project never reached anything resembling completion (it reincarnated a while later as the setting for my own horribly complicated version of the board game Civilization). Luckily I am nowadays a bit wiser than when I was young and don't let myself be depressed by another unfinished project. I rather see fiddling around with one of them as an aimless entertaining activity which I pursue for its own sake not in order to produce something great.
And - as in this case - I usually learn something which is really obscure and pointless but fascinating.
Sunday, 30 May 2010
Tuesday, 4 May 2010
C++ sucks for simulations
Today I once again had to realize that C/C++ is really a bad language to use for numerical simulations. In two heavily scrutinized (and often used) pieces of code I found two simple, yet far-reaching bugs which would immediately have been spotted by the compiler or the run-time system, respectively, had I used a decent language.
I implemented the first version of the simulation I am currently (again) working on about six years ago. Since then I made countless changes and refinements, although the general structure remained the same (yay structured programming). In particular the core functions of the model class (which implement what the model actually does) I tend to revise quite often in an iterative process of checking results, trying to understand them and coming up with new ways to test whether what I come up with is what's actually happening.
The stable and general part of the code I am producing I usually pull into a private library (which is available from sourceforge but so much a work in progress that I won't link to it) after some time.
One of the bugs occurred in the core model, the other one in the library, both in pieces of code I have checked and re-checked dozens of times. Both bugs were really, really stupid.
I will keep the story of how I actually found these bugs in the end for another blog post, suffice it to say that one of them is a Heisenbug, i.e. it had no effect in the debug version of the program.
Bug 1:
Without going into too much detail, the basic idea behind this code is that two individuals a and b have to negotiate their "role" (roleA and roleB) in the conflict. How this negotiation happens depends on the mode of role assignment each individual prefers (sym_a and sym_b). In one particular mode (sym_random) b automatically has the opposite role of a. Therefore in line 7 it should be roleA instead of sym_a.
I know, it's just a typo and a stupid one at that (although the code shown here is slimmed down quite a bit, in the original version the mistake is a bit more difficult to spot). Still, one reason it can go unnoticed is that C++ happily let's me convert between enum, int and bool without as much as a cringe (BTW, the fact that I have to use int for sym_a and sym_b instead of an enum is due to another quirk of C++ - enums don't play well with IO).
Bug 2:
Ok, this one is slightly embarassing. In a misguided attempt at optimisation I decided to rely on the input being valid (i.e. between 0 and 1). Which was sort of fine since in the original version I had two debug asserts checking for validity. Unfortunately it turned out that if I switched on SSE* code generation in gcc values of p==1.0 (which passed the asserts) lead to silent overflows in the multiplication so that the function always returned false. After I finally found it the bug was easily fixed by bypassing the comparison for values <=0 and >=1.
These two examples demonstrate two problems of C++ which make numerical programming significantly more error prone than necessary. Implicit conversion and silent arithmetic errors are by far not the most common sources of bugs in my programs. However if they occur the resulting bugs are among the hardest to find.
Unfortunately all languages that would offer enough static and dynamic checking to avoid these types of bugs come with a strong efficiency penalty (and, yes, 50% longer runtime *is* too much). It seems for now we will just have to make do with a bad language.
I implemented the first version of the simulation I am currently (again) working on about six years ago. Since then I made countless changes and refinements, although the general structure remained the same (yay structured programming). In particular the core functions of the model class (which implement what the model actually does) I tend to revise quite often in an iterative process of checking results, trying to understand them and coming up with new ways to test whether what I come up with is what's actually happening.
The stable and general part of the code I am producing I usually pull into a private library (which is available from sourceforge but so much a work in progress that I won't link to it) after some time.
One of the bugs occurred in the core model, the other one in the library, both in pieces of code I have checked and re-checked dozens of times. Both bugs were really, really stupid.
I will keep the story of how I actually found these bugs in the end for another blog post, suffice it to say that one of them is a Heisenbug, i.e. it had no effect in the debug version of the program.
Bug 1:
1 const int sym_a = a.symmetry();
2 const int sym_b = b.symmetry();
3 enum {sym_random = 0, sym_noRoles = 1};
4
5 const bool roleA = sym_a == sym_noRoles ? true : rng(2);
6 const bool roleB = sym_b == sym_noRoles ? true :
7 (sym_a == sym_random ? !sym_a : rng(2));Without going into too much detail, the basic idea behind this code is that two individuals a and b have to negotiate their "role" (roleA and roleB) in the conflict. How this negotiation happens depends on the mode of role assignment each individual prefers (sym_a and sym_b). In one particular mode (sym_random) b automatically has the opposite role of a. Therefore in line 7 it should be roleA instead of sym_a.
I know, it's just a typo and a stupid one at that (although the code shown here is slimmed down quite a bit, in the original version the mistake is a bit more difficult to spot). Still, one reason it can go unnoticed is that C++ happily let's me convert between enum, int and bool without as much as a cringe (BTW, the fact that I have to use int for sym_a and sym_b instead of an enum is due to another quirk of C++ - enums don't play well with IO).
Bug 2:
1 /** Gives true with a probability of p. */
2 bool choice(float p)
3 {
4 return (*this)() < Type((this->getMax()) * p);
5 }
Ok, this one is slightly embarassing. In a misguided attempt at optimisation I decided to rely on the input being valid (i.e. between 0 and 1). Which was sort of fine since in the original version I had two debug asserts checking for validity. Unfortunately it turned out that if I switched on SSE* code generation in gcc values of p==1.0 (which passed the asserts) lead to silent overflows in the multiplication so that the function always returned false. After I finally found it the bug was easily fixed by bypassing the comparison for values <=0 and >=1.
These two examples demonstrate two problems of C++ which make numerical programming significantly more error prone than necessary. Implicit conversion and silent arithmetic errors are by far not the most common sources of bugs in my programs. However if they occur the resulting bugs are among the hardest to find.
Unfortunately all languages that would offer enough static and dynamic checking to avoid these types of bugs come with a strong efficiency penalty (and, yes, 50% longer runtime *is* too much). It seems for now we will just have to make do with a bad language.
Friday, 5 February 2010
Who cares about lack of evidence
One of the common strategies of creationists and proponents of 'Intelligent Design' to discredit the theory of (Darwinian) evolution is to point out the supposed lack of evidence the theory has. Aside from the obvious reason that the overwhelming majority of falsification of evidence having been brought forth by these people in the past ranged from misunderstandings to utter nonsense, this claim always bothered me on a more principal level.
I think I now understand why. Even if they were right and all the little pieces of evidence that have been collected over the years were just plain wrong - it would not really matter that much. The assumption that it would shows a deep misunderstanding of the way science works. Let me explain why.
First we have to make clear what we are talking about. The "theory of evolution" creationists et al. make so much fuss about is essentially the assumption of modern biology that evolutionary processes (in the wider sense, i.e. including drift, gene flow and extinction) are solely responsible for the emergence of the diversity of life on earth from a single ancestral life form. (Many creationists confuse that with theories on the origin of life, but that is a different matter.)
In science theories that explain something reasonably well are kept around until either they are proven invalid or a theory that gives a better explanation comes around. If anti-evolutionists want us to abandon the theory of evolution they therefore either have to prove it invalid or provide something better.
That only leaves the second option - coming up with a better theory. As with every other topic many clever people have spent their lives thinking about what constitutes a good theory. The current mainstream version goes something like this:
A good theory has to be logically consistent and able to explain the phenomenon in question. It has to be falsifiable - a theory that can not possibly be proven wrong belongs to faith and not to science. Given two good theories, the more parsimonious, i.e. the one needing fewer assumptions is considered better.
The assumption of the existence of a supreme being with limitless power does not strike me as particularly parsimonious not to mention the fact that its alleged unpredictability makes every theory based on its behaviour by definition unfalsifiable.
Therefore, even *if* creationists et al. were right concerning the lack of evidence for evolution, I have to say, given the rather lousy alternatives, I will stick with it. Feel free to prove me wrong.
I think I now understand why. Even if they were right and all the little pieces of evidence that have been collected over the years were just plain wrong - it would not really matter that much. The assumption that it would shows a deep misunderstanding of the way science works. Let me explain why.
First we have to make clear what we are talking about. The "theory of evolution" creationists et al. make so much fuss about is essentially the assumption of modern biology that evolutionary processes (in the wider sense, i.e. including drift, gene flow and extinction) are solely responsible for the emergence of the diversity of life on earth from a single ancestral life form. (Many creationists confuse that with theories on the origin of life, but that is a different matter.)
Digression I: kinds of evolutionI assume the goal of anti-evolutionists is to discredit evolutionary theory and replace it with something more to their liking such as the "theory" of Intelligent Design which involves some divine intervention.
Creationists like to distinguish between micro-evolution (changes in a population over time) and macro-evolution (appearance and disappearance of species) claiming that the two are qualitatively different phenomena. Although this disctinction is not part of mainstream biology we will keep it here just for the sake of the argument.
Anti-evolutionists usually (nowadays) have no problems with biologie's understanding of "micro-evolution". The thing they hate and that the whole debate is about is how "macro-evolution" is explained by evolutionary theory.
In science theories that explain something reasonably well are kept around until either they are proven invalid or a theory that gives a better explanation comes around. If anti-evolutionists want us to abandon the theory of evolution they therefore either have to prove it invalid or provide something better.
Digression II: kinds of theories
I think what most people have in mind when they talk about a "theory" is something like Newtonian mechanics or relativity. A clearcut, simple (as opposed to complex) mathematical model that describes some part of the "inner workings" of our world.
The theory of evolution is very different. It consists of three statements which in very simplified form look like this:
- If there is heritable variation between individuals in a population which matters for their chances of survival or reproduction then evolution will take place which ultimately also can lead to the split of populations into distinct species.
- The physiology and ecology of actual biological individuals provides reproduction/survival-relevant heritable variation so that actual populations can evolve.
- The process of evolution has occured in the past and is (solely) responsible for the diversity of life on earth.
Epistemologically these are very different kinds of statements.In short proving the theory of evolution invalid could be done by showing that the theory is logically inconsistent (i.e. that evolution a priori can not happen) or that it contradicts more fundamental laws of e.g. physics or chemistry (i.e. that evolution can not happen in our universe or on our planet).
The first part is a essentially a theory about a specific type of emergence in complex systems. It describes how given certain conditions concerning the elements of a system certain mechanisms lead to a specific behaviour of the system. In this sense the first part is entirely a logical statement and has nothing to do with reality.
The second part is the assumption that the mentioned conditions can occur in our world and that the mentioned mechanisms are compatible with the laws of physics/chemistry/etc.
The third part is the statement that these processes have actually occured in the past and are responsible for the appearance of a certain aspect of the world as we see it.
Digression III: kinds of being wrong'Lack of evidence' however (even if it would apply) does not disprove the theory of evolution, at best it weakens its explanatory success.
I usually tend towards a rather constructivist point of view but just for the sake of the argument let us for a moment assume there is some objective describable reality with respect to which our theories can actually be wrong.
The theory of evolution (and similar theories about the history of complex systems) can be wrong in three ways:
- It can be logically inconsistent, i.e. the assumed conditions do not lead to the described processes happening or the assumed mechanisms have a different outcome.
- It can be inconsistent with the laws of physics, i.e. although evolution might happen the way we describe it, it can not do so in our world since the preconditions can never be met or the mechanisms can not take place.
- It can be historically inaccurate. This means that although evolution could happen in our world it did not do so in the past or at least not on a sufficient scale to actually produce the diversity of life as we know it.
That only leaves the second option - coming up with a better theory. As with every other topic many clever people have spent their lives thinking about what constitutes a good theory. The current mainstream version goes something like this:
A good theory has to be logically consistent and able to explain the phenomenon in question. It has to be falsifiable - a theory that can not possibly be proven wrong belongs to faith and not to science. Given two good theories, the more parsimonious, i.e. the one needing fewer assumptions is considered better.
The assumption of the existence of a supreme being with limitless power does not strike me as particularly parsimonious not to mention the fact that its alleged unpredictability makes every theory based on its behaviour by definition unfalsifiable.
Therefore, even *if* creationists et al. were right concerning the lack of evidence for evolution, I have to say, given the rather lousy alternatives, I will stick with it. Feel free to prove me wrong.
Sunday, 15 November 2009
Android, Java, Eclipse
During the weekend I wrote my first little android application (Leander, a frontend for dict.leo.org). I did it mainly to earn myself an Archos 5, but beyond that I was also just curious. This was the first time I wrote something for a different platform than general purpose PC/workstation/server, it was the first time I really used Eclipse and it was the first time in at least ten years that I used Java again.
As is to be expected from a resource-limited device the SDK feels a bit constrained and decidedly non-fancy. On the other hand that makes it relatively clear and easy to pick up.
I did not like Java when I first had to use it in a graphics programming course back in the nineties and I still do not really care for it. Its verbosity and redundancy annoy me. I think Java just feels overwhelmingly pedestrian.
All the rough edges and annoyances the whole experience could have had however were muffled by Eclipses constant supervision. I do not know whether it is the progress of technology or the different attitude of the language but the last time I used an IDE (Visual C++ back in the nineties as well), I did not feel nearly as cared for as this time.
All this hand-holding makes development sort of a brainless activity - just follow the suggestions by the IDE, copy and paste a few things from the docs or online sources... done. Anyways it is fun and I am curious to see whether my app is actually going to be used by anyone ;-).
As is to be expected from a resource-limited device the SDK feels a bit constrained and decidedly non-fancy. On the other hand that makes it relatively clear and easy to pick up.
I did not like Java when I first had to use it in a graphics programming course back in the nineties and I still do not really care for it. Its verbosity and redundancy annoy me. I think Java just feels overwhelmingly pedestrian.
All the rough edges and annoyances the whole experience could have had however were muffled by Eclipses constant supervision. I do not know whether it is the progress of technology or the different attitude of the language but the last time I used an IDE (Visual C++ back in the nineties as well), I did not feel nearly as cared for as this time.
All this hand-holding makes development sort of a brainless activity - just follow the suggestions by the IDE, copy and paste a few things from the docs or online sources... done. Anyways it is fun and I am curious to see whether my app is actually going to be used by anyone ;-).
Google Go, OOP, Interfaces and Inheritance
It seems these days new programming languages and in particular "systems" programming languages aiming to replace C/C++ are sprouting like mushrooms. I like programming languages therefore for me this is fun, the general public however usually is utterly unaware of these small languages, at least until they become old and somewhat established.
Last week however a new language was presented by nobody different than Google itself. Accordingly it made quite a splash. After everybody had cooled down a bit it turned out that this new language - Go - was mostly quite unremarkable. It consists mainly of a non-daring combination of tried and true language features each of which has been around for quite a while, put together with a strong focus on the simple and non-fancy.
It seems the only feature that received a bit of lasting attention is the lack of classical OOP. Although dissing OOP is sort of a trend at the moment, presenting a new supposedly mainstream language without classes and inheritance still attracts attention.
Instead of inheritance Go promotes composition. Polymorphism is achieved by a very simple mechanism - instead of letting classes declare the conformance to an interface at the time of the declaration of a class, every type that has the right combination of methods associated with it automatically conforms to an interface.
This last feature is it that the designers of Go (and quite a few other people) seem to be most excited about.
The funny thing is - this has been one of my pet peeves for ages and is actually quite an old hat. When I started to learn C++ (coming from Objective C) one of the things that bugged me most was that which interface a class implemented (or abstract base class it derived from in C++ terminology) was practically part of its implementation details. The feeling that this was a bad idea became even stronger when I later on learned Java. There is all this nice polymorphism and reflection but if you just quickly want to make a new interface for an existing class you have to jump through all sorts of hoops.
Then I found out that gcc had this nice C++ extension called 'signatures' which worked more or less exactly like Go's interfaces. At the time when I discovered them the documentation still bravely stated that signatures were being considered as an official part of the language. As we all know, this never happened so I didn't use them (as far as I know nobody did) and instead toyed with the idea of autogenerating some kind of template-based interface-adaptor.
It turned out that I wasn't the first to do so. A language called Heron was based on the same idea and even implemented as a front end to C++. It seems the author however lost interest at some point and abandoned the language.
Further there is the greatly underappreciated and sadly abandoned language Sather which separated inheritance and polymorphism as well.
Obviously not a new idea, thus, but unfortunately one that never took. A while ago I even proposed the same feature for the D language on their mailing list - of course unsuccesfully, the feature was too alien, my explanation too bad and my reputation too non-existent.
At some point my frustration with the rigidity of OOP (and many, many other things) in C++ became so big that I did what everybody seems to do - I started working on my own programming language. Separation of code reuse and polymorphism are one of its key features (the scope of the project long since snowballed from a modest redesign of C++ to a complete start from scratch, but that's a different story).
Accordingly it gives me a bit of a stale feeling to see everybody getting all excited about this supposedly revolutionary and brilliant feature. On the other hand having the momentum of Google behind it will hopefully finally give the idea enough exposure to find out whether it is indeed a viable alternative to classical OOP.
Last week however a new language was presented by nobody different than Google itself. Accordingly it made quite a splash. After everybody had cooled down a bit it turned out that this new language - Go - was mostly quite unremarkable. It consists mainly of a non-daring combination of tried and true language features each of which has been around for quite a while, put together with a strong focus on the simple and non-fancy.
It seems the only feature that received a bit of lasting attention is the lack of classical OOP. Although dissing OOP is sort of a trend at the moment, presenting a new supposedly mainstream language without classes and inheritance still attracts attention.
Instead of inheritance Go promotes composition. Polymorphism is achieved by a very simple mechanism - instead of letting classes declare the conformance to an interface at the time of the declaration of a class, every type that has the right combination of methods associated with it automatically conforms to an interface.
This last feature is it that the designers of Go (and quite a few other people) seem to be most excited about.
The funny thing is - this has been one of my pet peeves for ages and is actually quite an old hat. When I started to learn C++ (coming from Objective C) one of the things that bugged me most was that which interface a class implemented (or abstract base class it derived from in C++ terminology) was practically part of its implementation details. The feeling that this was a bad idea became even stronger when I later on learned Java. There is all this nice polymorphism and reflection but if you just quickly want to make a new interface for an existing class you have to jump through all sorts of hoops.
Then I found out that gcc had this nice C++ extension called 'signatures' which worked more or less exactly like Go's interfaces. At the time when I discovered them the documentation still bravely stated that signatures were being considered as an official part of the language. As we all know, this never happened so I didn't use them (as far as I know nobody did) and instead toyed with the idea of autogenerating some kind of template-based interface-adaptor.
It turned out that I wasn't the first to do so. A language called Heron was based on the same idea and even implemented as a front end to C++. It seems the author however lost interest at some point and abandoned the language.
Further there is the greatly underappreciated and sadly abandoned language Sather which separated inheritance and polymorphism as well.
Obviously not a new idea, thus, but unfortunately one that never took. A while ago I even proposed the same feature for the D language on their mailing list - of course unsuccesfully, the feature was too alien, my explanation too bad and my reputation too non-existent.
At some point my frustration with the rigidity of OOP (and many, many other things) in C++ became so big that I did what everybody seems to do - I started working on my own programming language. Separation of code reuse and polymorphism are one of its key features (the scope of the project long since snowballed from a modest redesign of C++ to a complete start from scratch, but that's a different story).
Accordingly it gives me a bit of a stale feeling to see everybody getting all excited about this supposedly revolutionary and brilliant feature. On the other hand having the momentum of Google behind it will hopefully finally give the idea enough exposure to find out whether it is indeed a viable alternative to classical OOP.
Tuesday, 27 October 2009
The weirdness of male lactation
When our first child was under way, we had a few interesting lunch discussions with some friends/colleagues over this one. Recently it resurfaced but under a very different aspect.
Weird biology
One of the reasons I love biology is that it is the realm of the weird, wonderful and bizarre. For every rule in biology there is usually a weird, obscure exception (e.g. flying or land-walking fish, egg-laying mammals, herbivorous spiders, gliding snakes, diving lizards, ...). Also in general every bizarre thing one can think of has evolved at least once (e.g. infectious cancer, tongue-replacing isopod, cartwheeling spider, parasitic males, sex-changing fish, child birth through the pelvis, ...). (we could call call these the Biological Laws of Weirdness)
Surprisingly however there is only one not entirely convincing example for male lactation in mammals. This is even stranger given that a) male care (sans lactating) does occur in mammals, b) male mammals are anatomically absolutely capable of lactating and c) it is easy to come up with scenarios where it would be quite beneficial for a male mammal to be able to feed its young.
The whole thing is puzzling enough that it even deserved a paper in TREE.
Weird people
The issue came to my attention again recently when I stumbled upon a small article in a swedish online newspaper about a guy who tried to train himself to lactate (I think people fulfill the same two rules of weirdness I mentioned above). While this shows admirable determination (and imperviousness to social pressure as we will see in a moment) this is in my opinion nothing to write home about - as I said people are weird and if the guy wants to lactate, be my guest. The real eye-opener came when I started to read the comments to the article. I do not recall the exact numbers but out of 40-50 comments more than three quarters displayed negativity ranging from ridicule over denial to outright foaming, spittle-spraying rage. This reaction absolutely astonishes me. I mean, I am certainly not eager to try it myself, but come on guys, why does it bother you so much that this one swedish boy tries to squeeze some milk from his nipples?
I do not want to overinterprete the matter but I think this might be a sympton of some deep insecurities many men have concerning their gender roles. Maybe I will write a blog post about that...
Epilogue
While looking up the references for this post I found out that I have actually been in good (if not the best) company with my puzzlement. It seems John Maynard Smith asked the same question in his 1978 book "The Evolution of Sex". Thirty years and we are still left to wonder...
Weird biology
One of the reasons I love biology is that it is the realm of the weird, wonderful and bizarre. For every rule in biology there is usually a weird, obscure exception (e.g. flying or land-walking fish, egg-laying mammals, herbivorous spiders, gliding snakes, diving lizards, ...). Also in general every bizarre thing one can think of has evolved at least once (e.g. infectious cancer, tongue-replacing isopod, cartwheeling spider, parasitic males, sex-changing fish, child birth through the pelvis, ...). (we could call call these the Biological Laws of Weirdness)
Surprisingly however there is only one not entirely convincing example for male lactation in mammals. This is even stranger given that a) male care (sans lactating) does occur in mammals, b) male mammals are anatomically absolutely capable of lactating and c) it is easy to come up with scenarios where it would be quite beneficial for a male mammal to be able to feed its young.
The whole thing is puzzling enough that it even deserved a paper in TREE.
Weird people
The issue came to my attention again recently when I stumbled upon a small article in a swedish online newspaper about a guy who tried to train himself to lactate (I think people fulfill the same two rules of weirdness I mentioned above). While this shows admirable determination (and imperviousness to social pressure as we will see in a moment) this is in my opinion nothing to write home about - as I said people are weird and if the guy wants to lactate, be my guest. The real eye-opener came when I started to read the comments to the article. I do not recall the exact numbers but out of 40-50 comments more than three quarters displayed negativity ranging from ridicule over denial to outright foaming, spittle-spraying rage. This reaction absolutely astonishes me. I mean, I am certainly not eager to try it myself, but come on guys, why does it bother you so much that this one swedish boy tries to squeeze some milk from his nipples?
I do not want to overinterprete the matter but I think this might be a sympton of some deep insecurities many men have concerning their gender roles. Maybe I will write a blog post about that...
Epilogue
While looking up the references for this post I found out that I have actually been in good (if not the best) company with my puzzlement. It seems John Maynard Smith asked the same question in his 1978 book "The Evolution of Sex". Thirty years and we are still left to wonder...
Monday, 26 October 2009
Scientific versus "regular" programming - part I
A huge part of the effort (and the resulting progress) in computer science is dedicated to making it easier for people to create better programs in a shorter amount of time. To this end new tools and methodologies are developed.
However if we zoom in a bit differences between different areas of application of programming become obvious. Consequently the demands placed on the required tools and methods differ as well.
In my field (theoretical biology) and I think generally in areas of science that require the development of simulation software programming happens under very special conditions that lead to a unique set of requirements for the process of software creation.
what is a good program?
Many clever people have written whole books on the topic and I am certainly not an expert, but in a nutshell a good program in most situations has to fulfill these criteria:
However if we zoom in a bit differences between different areas of application of programming become obvious. Consequently the demands placed on the required tools and methods differ as well.
In my field (theoretical biology) and I think generally in areas of science that require the development of simulation software programming happens under very special conditions that lead to a unique set of requirements for the process of software creation.
what is a good program?
Many clever people have written whole books on the topic and I am certainly not an expert, but in a nutshell a good program in most situations has to fulfill these criteria:
- correctness - It has to do the things it is supposed to do (and only those).
- efficiency - It has to do them using a reasonable amount of resources (time, memory, etc.).
- maintainability - It has to be reasonably easy to change the program in the future.
Making it easier for people to make programs conform to these criteria (or at least find out whether they do) with a reasonable amount of effort has been the main driving force behind the development of new languages, platforms, IDEs, coding conventions, etc. Accordingly it is nowadays a *lot* easier to produce correct, efficient and maintainable code than it was, say thirty years ago.
Although similar the criteria for what makes a "good" program in a scientific context differ in important details.
efficiency
It has often been said (in many variations) that Moore's law made efficiency unimportant. This is certainly true in many areas as shown by the success of dynamic, interpreted (and horribly slow) languages such as Ruby or Python.
For someone who writes and uses simulation programs however time is always a limiting factor (disk space and memory are others but less so in recent years). Given more time (or higher execution speed) it is possible to test more parameter combinations, build in more details, run more replicates or observe more long term dynamics - all of which (might) lead to better results, which make for better publications which will bring more fame, fortune and general happiness.
execution speed is important
maintainability
The need to program in a way that makes it easy (or at least possible) to make changes to a program later on has lead to the evolution of whole industries.
In the scientific context this is only an issue for library code and tools. Most of the code written by the scientist herself is usually a one-off effort and stored in the virtual attic after publication of the corresponding paper(s).
There is a related issue of understandability and clarity of code but I will talk about this later.
maintainability is (with certain caveats) a minor problem
correctness
I think program correctness is maybe the aspect where scientific programming differs most from "mainstream" programming.
The correctness of an operating system or a game is determined by how much the respective program behaves according to specifications. Bugs are found by people running into situations where the program behaves in a way it shouldn't (crashes, rendering glitches, hangups, etc.). Observing the program is therefore ultimately the way most bugs are detected in such a situation. Luckily this also means that those bugs that have the strongest effect on program behavior tend to be the easiest to detect.
In a simulation on the other hand the behavior is the outcome of the program. The program is correct if the behavior is produced according to the specified rules. Of course simulations also have easily observable bugs (e.g. the program crashes) but these are not dangerous. Many errors however "just" lead to wrong results. These bugs are very dangerous because they can go entirely undetected while making the whole program (or at least the work done with it) effectively worthless. Especially in more complicated simulations in principle the only way to find these bugs is by rigorous examination of the source code.
correctness is essential, difficult to obtain and even more difficult to prove
clarity
This leads us directly to an additional criterion for program quality that is usually seen as a part of maintainability but in the context of scientific programming deserves in my opinion a bullet point on its own - clarity and legibility of the source code.
If some (serious) bugs can only be found by reasoning about the source code then it becomes of paramount importance to write the code in a way that makes it easy to reason about. In this sense clarity is a means to fulfill the correctness criterion.
In a scientific context however the source code of a program is more than just the intermediate stage towards producing an executable that can be used. An essential part of the way science happens is that one scientist's results have to be reproducible by other scientists. In the empirical fields that means that methods are published down to the last onerous detail. In a mathematical paper enough steps of a calculation are given that it is possible to retrace the authors' steps (for a suitable definition of 'possible'...). Given the notorious dissociation between source code and documentation the code ultimately is the authoritative source on what a simulation does (unfortunately there is no real standard for the publication of source code (yet), although usually most authors at least offer to provide the source code on request - but that is a different blog post). Source code therefore is also a means of communication between scientists and therefore should be written in a way that makes it as easy to understand as possible.
In my opinion this is a vastly underappreciated aspect of at least those programming courses for scientists that I am aware of.
clarity of source code is essential
It should be clear by now that producing a good program requires a specific approach in a scientific context. In the next part of this post I will explain which consequences the specific "socio-economic environment" has for scientific programming. Then I will explore the consequences for the design of better tools for scientific programming.
update (27/10/09 10:28)
Please also check out the interesting comments on reddit.
Although similar the criteria for what makes a "good" program in a scientific context differ in important details.
efficiency
It has often been said (in many variations) that Moore's law made efficiency unimportant. This is certainly true in many areas as shown by the success of dynamic, interpreted (and horribly slow) languages such as Ruby or Python.
For someone who writes and uses simulation programs however time is always a limiting factor (disk space and memory are others but less so in recent years). Given more time (or higher execution speed) it is possible to test more parameter combinations, build in more details, run more replicates or observe more long term dynamics - all of which (might) lead to better results, which make for better publications which will bring more fame, fortune and general happiness.
execution speed is important
maintainability
The need to program in a way that makes it easy (or at least possible) to make changes to a program later on has lead to the evolution of whole industries.
In the scientific context this is only an issue for library code and tools. Most of the code written by the scientist herself is usually a one-off effort and stored in the virtual attic after publication of the corresponding paper(s).
There is a related issue of understandability and clarity of code but I will talk about this later.
maintainability is (with certain caveats) a minor problem
correctness
I think program correctness is maybe the aspect where scientific programming differs most from "mainstream" programming.
The correctness of an operating system or a game is determined by how much the respective program behaves according to specifications. Bugs are found by people running into situations where the program behaves in a way it shouldn't (crashes, rendering glitches, hangups, etc.). Observing the program is therefore ultimately the way most bugs are detected in such a situation. Luckily this also means that those bugs that have the strongest effect on program behavior tend to be the easiest to detect.
In a simulation on the other hand the behavior is the outcome of the program. The program is correct if the behavior is produced according to the specified rules. Of course simulations also have easily observable bugs (e.g. the program crashes) but these are not dangerous. Many errors however "just" lead to wrong results. These bugs are very dangerous because they can go entirely undetected while making the whole program (or at least the work done with it) effectively worthless. Especially in more complicated simulations in principle the only way to find these bugs is by rigorous examination of the source code.
correctness is essential, difficult to obtain and even more difficult to prove
clarity
This leads us directly to an additional criterion for program quality that is usually seen as a part of maintainability but in the context of scientific programming deserves in my opinion a bullet point on its own - clarity and legibility of the source code.
If some (serious) bugs can only be found by reasoning about the source code then it becomes of paramount importance to write the code in a way that makes it easy to reason about. In this sense clarity is a means to fulfill the correctness criterion.
In a scientific context however the source code of a program is more than just the intermediate stage towards producing an executable that can be used. An essential part of the way science happens is that one scientist's results have to be reproducible by other scientists. In the empirical fields that means that methods are published down to the last onerous detail. In a mathematical paper enough steps of a calculation are given that it is possible to retrace the authors' steps (for a suitable definition of 'possible'...). Given the notorious dissociation between source code and documentation the code ultimately is the authoritative source on what a simulation does (unfortunately there is no real standard for the publication of source code (yet), although usually most authors at least offer to provide the source code on request - but that is a different blog post). Source code therefore is also a means of communication between scientists and therefore should be written in a way that makes it as easy to understand as possible.
In my opinion this is a vastly underappreciated aspect of at least those programming courses for scientists that I am aware of.
clarity of source code is essential
It should be clear by now that producing a good program requires a specific approach in a scientific context. In the next part of this post I will explain which consequences the specific "socio-economic environment" has for scientific programming. Then I will explore the consequences for the design of better tools for scientific programming.
update (27/10/09 10:28)
Please also check out the interesting comments on reddit.
Subscribe to:
Posts (Atom)