Jonathan Merritt's Blog

Observations, Hypotheses and Models: The importance (and lack of) model-based approaches in biology and the life sciences.

2012-01-31T14:08:00.020+11:00

Recently, I've been thinking about how I view scientific literature and the process of doing science. I have a particular view, but I have no idea whether my view is right or wrong, or if it matches the consensus. Nobody really talks about these things, so I thought I'd blog about my ideas to see if there are (any) reactions. I'd like to hear from my fellow scientists, especially from anyone who strongly disagrees with me. I've written in terms of my own experiences, since they are my main point of reference, but hopefully people from other fields will understand me.

Broadly, I tend to think of scientific literature belonging in three, somewhat overlapping groups:

Observational studies ("hypothesis-free" science)
Hypothesis-based studies
Model-based studies

Observational studies don't tend to have strong hypotheses. They are characterised by questions like: "Does X happen?", or "How much does X happen?" Epidemiological studies fall into this category. Hypothesis-based studies then tend to be looking for links between variables, but without strongly addressing a mechanism. They ask questions like: "Does Y influence X?" Finally, there are model-based studies, which wonder: "How does Y influence X?" Model-based studies posit a definite, formal mechanism, which then yields a relationship between variables or events that matches reality in some way. I should add that many (most?) hypothesis-based studies do involve a mechanism that the authors have in mind. However, the mechanism isn't formalised: it is a kind of background idea, which ends up in the Introduction and Discussion sections of published literature, rather than being part of the Methods or Results. Also, when I write "model" here, the word could probably just as well be replaced by "theory". I use "model" only because I have in mind some kind of formal description; a mathematical relationship or well-defined procedure, and not a hand-wavy explanation without a formal framework.

Now it's time for an example. Hang on to your seats, because this is quite involved. I'll look at the sclerotic changes which occur in the equine carpal bones during fast exercise. When horses undergo fast exercise training, the dorsal parts of their carpal bones increase in density much more than the palmar parts (Firth et al. 2000, Firth and Rogers 2005). Because bone typically responds to mechanical stimulus by increasing in density, this suggests that the dorsal parts experience higher stresses. Indeed, under one type of simulated loading, the third carpal bone did experience higher contact pressures on the dorsal articular surfaces than the palmar ones (Palmer et al. 1994). It seems that there may be a pattern of higher dorsal stresses in these bones, which has been seen in both a simulated loading study and in the response of the bones themselves to exercise.

If we run with this premise, then the next obvious question is: "How does this higher dorsal load occur?" Notice that this is framed as a model-type question: we're not asking whether it occurs, but by what possible mechanism. If the carpus were loaded only in compression, as we might conclude from various equine limb models, then it would make sense that a fairly uniform load would exist across the bones within the carpus, modulated only by their anatomical details. Instead, we see an apparent dorsal concentration of stress, which doesn't seem to be anatomically modulated: it's not as though we can explain this readily from the anatomy alone! So, I proposed a mechanism for this effect: that the carpus as a unit supports not only compression, but also a type of loading called a "bending moment", which causes increased dorsal compression. This is now a model: a mechanism by which we might have increased dorsal compression. The model is based in something called beam theory, with straightforward connections to the overall mechanics of locomotion.

We now reach the main problem with any model-based study: validation. There's a brilliant quote from physicist Richard Feynman from his Lectures in Physics:

"There is also a more subtle problem. When you have put a lot of ideas together to make an elaborate theory, you want to make sure, when explaining what it fits, that those things it fits are not just the things that gave you the idea for the theory; but that the finished theory makes something else come out right, in addition."

In the case of my bending moment model, it fits the observations of bone loading and bone changes, but of course, those are the things which gave me the idea in the first place. So what else can "come out right?" Well, this is where we hit pay dirt with a formal model rather than an isolated hypothesis. Mechanically, if the carpus is supporting a bending moment, then this load must also be transferred to (or "supported by") the metacarpus. If this is happening, then the metacarpus must also have a particular pattern of loading, called a cantilever, which I could look for. And that's precisely what I did: I went and looked at the bone changes which occur during Thoroughbred race training and found exactly the changes I would expect from a cantilever loading of the metacarpus (Merritt and Davies, 2010). There are also other types of validation that are in-press at the moment, so I can't discuss them, but they follow a similar approach: using the formal nature of the model to make solid, required predictions which can then be tested.

Now; back to the broader discussion. I think that model-based science is the way to go, because I think it provides the most insight.

The first benefit of a model is that it often provides other predictions, which can then be tested in their own right (like the metacarpal loading described above). This is superior to a stand-alone hypothesis, which can only be tested on larger and larger groups, and cannot be extended formally. Of course, we can informally link hypotheses, via verbal reasoning or simple logic, and this is very common in biology. However, such informal reasoning is limited by its scope to outcomes that are more straightforward than those which might arise from a more structured model. For example, without a mechanical model that I could draw and discuss on paper, I don't think that the link between carpal and metacarpal loading is very obvious at all. Certainly, you couldn't make numerical predictions about it or know the pattern of metacarpal bone changes that would confirm the model. Importantly, model predictions can also be invalidated by experiment. I would have had a good reason to doubt the model if its predictions were not seen in reality. However, this kind of invalidation is less likely to occur with informally-linked hypotheses, where the invalidation of one may not be linked in a formal way to the invalidation of another.

A second key benefit of a model is that, knowing the mechanism, we can intervene more intelligently. For example, if we want to decrease dorsal carpal loading, we have only to decrease the magnitude of the bending moment. We can easily predict methods for achieving that outcome (based - you guessed it - on other musculoskeletal models), which could then be tested.

You may already have realised that what I'm describing here is broadly the way that the discipline of Physics works. In Physics, there are people who specialise in experimental work, and people who specialise in theoretical work. They both depend upon each other. Without good solid theories to invalidate, the experimentalists would be stuck in the more observational end of the spectrum, unable to link their observations into a wider world view. Without experimentalists, the theorists could invent anything they wanted.

In biology and life sciences, however, it seems that we are dominated by the experimentalists. Few people concentrate on formal theories. Those that do tend to be "computer modelers" or "computational biologists", and seem largely to be shunned by the mainstream. I can think of three major reasons for this, in my area at least:

If you're working on theory, you'll publish less. This is because you're doing twice the work: you need to develop both the formal framework of a theory and confirm it by experiment. By contrast, if you're instead working from hypothesis to hypothesis, you don't need to develop your theories formally: you can focus primarily on experiments and publish more. The life sciences publish at a frenetic rate, so anything that leads to slower publication is "full of fail", particularly in the case of an early-career researcher, even if it leads to greater insight.
People in life sciences are not encouraged to develop skills that will help with formal models. In physics, for example, the skills for developing formal models are considered critical. Most physicists have a solid undergraduate background in math and computation, simply because they couldn't proceed to graduate level without them. What is it, then, that makes this so critical for physics but not for biology? What possible reason could there be? In reality, biological systems are, if anything, more complicated than most systems which are currently widely-studied in physics, so you would think that superior analytical skills would be essential.
Life-sciences literature does not currently provide many venues for theoretical development that will be read by experimentalists. For example, if you read my paper on cantilever bending in the metacarpus (Merritt and Davies, 2010), you'll be doing extremely well if you realize that it has anything whatsoever to do with the carpus! The paper is full of the descriptions of assumptions and models used, forever qualifying itself at deeper and deeper levels, so that its main statement is justified. There's nowhere I know of in which I could publish a purely theoretical paper which links all of this together (in the equine biomechanics field at least). Consequently, theoretical developments in life-sciences literature are poorly described, and are often not apparent to people working in experimental areas. This, in turn, means that the experimentalists cannot perform their main function, which is to design experiments to invalidate and reject the theoretical models.

This is the point that I have reached in my ponderings. I could continue to rant, but I think I'll stop here to see if anyone has any comments. :-) I'll close by saying that I don't think I'm alone in my desire for more solid theory behind biology and the life sciences. Places such as the Broad Institute of MIT and Harvard and the Auckland Bioengineering Institute are solidly based on the concept. However, in my particular field (equine biomechanics), I don't know of a group who have taken this approach, and I don't see it happening.

Firth EC, Rogers CW and Jopson N (2000) Effects of racetrack exercise on third metacarpal and carpal bone of New Zealand Thoroughbred horses. Journal of Musculoskeletal and Neuronal Interactions, 1(2):145-147.

Firth EC and Rogers CW (2005) Musculoskeletal response of 2-year-old Thoroughbred horses to early training. 7. Bone and articular cartilage response in the carpus. New Zealand Veterinary Journal, 53(2):113-122.

Merritt JS and Davies HMS (2010) Metacarpal geometry changes during Thoroughbred race training are compatible with sagittal-plane cantilever bending. Equine Veterinary Journal, Supplement 38:407-411.

Palmer JL, Bertone AL and Litsky AS (1994) Contact area and pressure distribution changes of the equine third carpal bone during loading. Equine Veterinary Journal, 26(3):197-202.

Universities: Research or Development?

2011-12-23T12:42:00.000+11:00

Worrying Success...

If you're an Australian tax payer, you might be wondering how your hard-earned tax dollars are being spent in Australia's universities. As a post-graduate researcher, I wonder the same thing. I don't have any hard figures, but I do have a story behind one of my own projects which increasingly concerns me.

I'm part of a group who are developing a sensor for use on horses. I won't tell you what the sensor is, because it's rather IP-encumbered, and I don't want to be accused of giving anything away (that's a big red flag, right there: you see me waving it?). As an “early career researcher”, this particular project has been a gold mine for grants. We currently have about $45,000 in direct funding---about half from the University of Melbourne, half from another Commonwealth Government agency---and about $150,000 from “in-kind” contributions. I wrote the grant applications myself, and not a single one was rejected.

So, why does this success worry me? Well, because we're not doing any actual science. What we're doing is development.

I'd better define those two uncertain terms before going any further. For the scope of this blog post, I'm defining “development” as “engineering”: the safe, pragmatic application of known scientific principles to solve a given problem. I'm definining “science” and “research” interchangably as: the generation and testing of falsifiable hypotheses, many of which may be wrong, but which will increase the body of human knowledge. In the case of this sensor project, we don't really have a hypothesis. Our hypothesis is that “the device will work as expected”, which will be upheld if we produce a “successful development” as opposed to an unsuccessful one. (Trust me: it's going to be successful, it's a really safe bet.)

This all bothers me because I personally think that a University should be a place in which research is conducted, not development. If development happens, it should be in support of research, and not the other way around. However, my recent grant-winning success makes me concerned that few in the decision-making nether-regions of The System agree. And mine is not a unique experience. It's well understood that projects with an “industrial focus”, solving “real world” problems are preferred, even if their actual science content is utterly negligible. Why do you think I spent the time on those grant applications in the first place?

I should also mention at this point that I'm only interested in developing this particular sensor in order to do science with it in the future. That was clearly described in the grant applications. However, no actual science is taking place as part of these grants themselves. Once the sensor has been developed and commercialised, I sincerely doubt that I will have much luck applying for grants which address the science I actually want to do. The things I'm really interested in are “basic science” questions, which definitely don't address any of the immediate needs of the equine industry. (Unlike the sensor: that will sell like hot-cakes!)

Why Bother with Abstract Science?

So, if we have a lot of productive developments like mine happening in universities, addressing real-world issues, then where is the problem? Isn't that what the public want from a university anyway? Maybe the answer is yes, but it really shouldn't be. To explain why not, I can tell the story of the birth of microbiology. This is the story as far as I understand it; I'm very open to corrections from actual historians.

Microbiology is a major area of modern science. It under-pins much of modern biology and medicine. It's probably connected with most of the science that is done today. However, the entire field seems to have arisen as a kind of accident, cropping up from chance discoveries made by people who were interested in other things (or at least: they weren't specifically biologists per se).

Microbiology depended upon the microscope, without which scientists were unable to observe things like bacteria directly. The details of the invention of the microscope are uncertain, but it seems to have occurred circa 1590, and is attributed to both Hans Lippershey and Sacharias Jansen, who were Dutch spectacle makers. They also invented some early telescopes. These two inventors appear to have been driven by commercial interests, in that they left it to others to document what they saw by actually looking through these early instruments.

Roughly 50 years after the invention of the microscope, we have records of the observations made by Robert Hooke in his 1665 book, Micrographia. Despite its name, Micrographia also contains illustrations of Hooke's observations through a telescope. Like many of his contemporaries, Hooke was a polymath who had an interest in many different areas of science. He gave us Hooke's Law of linear elasticity, and is one of three scientists (the others were Wren and Halley) that Isaac Newton credited as the originators of the inverse square law of gravity in his Philosophiae Naturalis Principia Mathematica. Hooke observed plant cells, and even coined the term “cell”. One of the avid fans of Hooke's Micrographia was Antonie van Leeuwenhoek, who developed his own microscope using a novel lens-making technique. van Leeuwenhoek's microscope was more powerful, and in 1676 he was the first to observe a bacterium.

This story has always fascinated me, and I think it contains parallels to the modern world. There were the Dutch spectacle makers; business men, not scientists, who had a new invention to flog. It's scientific use wasn't at all obvious at the time, so it took 50 years before it became popular. Many more advances were made with the telescope in the intervening period. Hooke was the grumpy impoverished scientist (at least before Micrographia), who had dozens of different interests, and popularised microscopy through his role at the Royal Society. Then van Leeuwenhoek took an interest, spurred on by his fascination with Micrographia, to develop better equipment and make the key discoveries which founded microbiology.

There's another part to the story though, which is important for my point: at the time of Hooke and van Leeuwenhoek, one of the prevailing theories for the source of disease was the “Miasma Theory”. This was a classic case of “correlation is not causation”. Basically, the miasma proponents, going way back to antiquity, saw that bad smells were associated with disease, and they made the jump to say that bad smells must therefore cause disease. It sounds like an amusing mistake in today's world, but it was taken very seriously. Famously, large amounts of money were spent in London on the quest to remove bad smells. As a side effect, those measures improved drainage, which actually did reduce the incidence and severity of outbreaks of several diseases!

This is all quite interesting, but I often wonder: what would have happened if modern university funding practices applied at the time? We can imagine Hooke, without patronage or other assistance, sitting in his office wondering how he's going to raise any money to do research. The answer, for him and all his colleagues, would be the same as it is today: grant money! Clearly, abstract observations of planetary bodies are out of the question: what practical problems would that solve? Consequently, Hooke doesn't bother to investigate his telescope or microscope any further: they're just toys that he hopes he'll have some time for one day. We can imagine that, following the prevailing trends and the advice of his mentors, he would perhaps apply for a grant to study miasmas, since they were clearly the most promising avenue of research into epidemic diseases. Sadder still is the fact that he would almost certainly have been awarded such a grant! He might well have been thought successful by his colleagues!

What's the Solution?

I try to make myself as much a polymath as possible. I've been involved with teaching in Veterinary Science and Mechanical Engineering: two faculties which have very little in common. I also like to think I have enough background to do a decent job teaching introductory subjects in Computer Science. However, my knowledge of different subject areas has been a personal quest: I've had no formal support, despite seeking it out as much as possible. I even investigated doing a second PhD in Physics following the completion of my PhD in Vet, but sadly there's no option of a Commonwealth Government scholarship to do a second PhD. Suffice to say that formal support for “polymath training” in Australia doesn't really exist. (No, a double undergraduate degree does not make you a polymath, at least not at the depth I'm talking about here. Yes, I do have a double undergraduate degree.)

I see colleagues who have taken up positions as Lecturers at the University of Melbourne, and their job is not one I want. They seem to spend the vast majority of their time teaching undergraduates, and what little research they are able to conduct is supported no better than my own. I even have the advantage of enough spare time, and enough sleep, to actually think about a problem once in a while.

As far as I can tell, my solution may well involve moving overseas (to the USA), to a better-supported post-doc position in which I can focus purely on research and not have to concern myself with grants that have no science content, or with teaching undergraduates. Having visited a US lab for several months, I know that that kind of environment suits me: I was many times more productive during that visit than I am in Australia. Focus really helps. In the longer term, I will try to join an established group which can support research activity at a high level with only minimal teaching work. I'm not sure how feasible that is, with grant money for Real Science (TM) appearing to dry up everywhere, but it seems to be my best bet.

Of course, I could just leave academia, enter the Engineering industry, and earn five times as much overnight. (Yes, my current annual earnings are about $25,000. Yes, that includes all my teaching work. Yes, it is sad.). Industry is an ever-present option which takes some fortitude to decline.

Exciting photogrammetry developments

2011-01-09T12:59:00.004+11:00

Microsoft Photosynth made the news in March 2010 when it was released as a tool for 3D photo-tourism. However, the recent proliferation in Open Source photogrammetry tools have slipped more-or-less under the radar.

First, and most useful, I would like to draw your attention to the Bundler/CMVS/PMVS2 toolchain from the University of Washington:

In combination with MeshLab's meshing tools, even a newbie like me can produce some fairly stunning results:

Here's a quick tutorial on meshing in MeshLab: http://meshlabstuff.blogspot.com/2009/09/meshing-point-clouds.html

Also of interest are Insight3D and the libmv library. Although Insight3D can actually be used as of now (Jan 2011), it's not as immediately complete or useful as the Bundler toolchain. libmv is still in development, but may be a good long-term open source solution (since it's not clear whether the Bundler software will continue to be developed).

Charts, Linear Fits and SoMa!

2010-02-18T15:50:00.006+11:00

Oracle seems to be reticent to say when JavaFX 1.3 (code-named "SoMa") will be released. The most that we, the unwashed masses, can learn about it comes from the JavaFX bug tracker. I'm very eager for some of the proposed features in 1.3, so I've been keeping a watch over the issues list for the Runtime component of JavaFX, in the "SoMa (Fix For Version)" category. I've been watching the number of outstanding issues, by subtracting the number of resolved issues from the total number of issues. Naturally, this obsession became a prime candidate for some JavaFX plotting work.

Here are the current results:

It's difficult to host applets at blogger.com, so I've uploaded the applet here: http://merrittmechanical.com/soma-issues/index.html

There's also a link to the source code on that page. (I would appreciate hints about any better hosting options...)

To create the best-fit line and the data points, I overlaid a LineChart on a ScatterChart. I didn't manage this very elegantly; I just set up both charts with the same axes and then made the axes of one chart completely transparent (relevant strokes and fills are Color.TRANSPARENT). This worked for the purpose of creating this chart, but definitely isn't ideal.

I also created a best-fit line, using a least squares method described in the Numerical Recipes textbook. The least-squares method is very simple and comes out as quite elegant FX script. Because the more recent data points in the outstanding issues list are likely to have a greater effect on the release date than older data points, I created a linear confidence distribution in which the most recent observation has twice as much confidence attached to it as the oldest observation. This is very arbitrary, of course. The code for the linear best fit is included with the example above. The linear fit was then projected to find the point at which the Outstanding Issues would reach zero; assuming this to coincide with the release date. That date is then computed and displayed.

Of course, all of this is a bit of a pointless exercise. Not all issues are of the same magnitude, and developers don't work in a linear fashion anyway. However, it is still fun to watch the issue list shrink over time and to guess about when this release will happen. I hope it arrives quickly!

JavaFX Blogs and Links

2010-02-08T08:57:00.005+11:00

Many years ago, I wrote an app for strain gauge data acquisition and real time display. The app has been used for a number of published journal articles, but it's now getting very old. Originally, it was written using the Microsoft Foundation Classes, but I've long since moved away from the Microsoft space. Consequently, now that it's time to update the application, I'm doing a re-write in JavaFX and Scala.

I've been a fan of Scala for the last two years, but my decision to use JavaFX was a more difficult one. I'm a big fan of Swing, and Scala Swing in particular. I also like Ingo Maier's work on ScalaFX, and the way that his functional reactive core integrates so well with the rest of Scala. So I was hoping to find a pure Scala solution for the graphical components I need. These components draw things like scales and time-series data. I looked at the existing plotting libraries, like JFreeChart (which I've also used for other projects), but none of those seem to fit my need for real-time, interactive display. I have previously created custom components in Swing, but going down that road again for the 5 or 6 components I need was not appealing. Although Maier is a genius, nobody seems to have been able to pin down his development and release schedule for ScalaFX. Although I don't need a stable API, I at least look for a first release before using it on something that I'm expected to support for fellow academics.

When I originally investigated JavaFX, I found that I had an instant hatred for JavaFX script, which was based primarily upon the monolithic examples on the JavaFX website. I thought that the language simply wouldn't scale, and that Sun had abandoned key principles like data hiding and encapsulation. However, my impression of the language has improved substantially with a little use. I've come to realise that really nothing has been lost, and that it's possible to write components in JavaFX that are vastly superior to Swing components, while retaining everything I need: particularly a clear separation of model and view / controller. My improved opinion of JavaFX arose primarily from two sources: the JFXtras code and the structure of the javafx.scene.control hierarchy. Jonathan Giles gives a very good introduction to creating custom controls within that hierarchy here, but bear in mind that he only superficially addresses many of the problems of a "real" custom control. I'll write up my custom control experiences once JavaFX 1.3 is released and I can address theming them properly for Caspian (which is the emerging L&F for JavaFX).

In summary, I've transitioned from hating JavaFX to becoming an advocate for it within the space of about two weeks. Not knowing any better, I believed much of the scepticism that was initially expressed about it on the web: that it's hopeless for desktop work and far behind its competitors in the RIA space, and my own impression of the scripting language was far from positive. However, I would now encourage anyone still holding those opinions to really spend a few days using the language and APIs. They're better than you think (and I say that as someone who's done some projects in Scala, which is a much richer language!).

So, I thought I'd leave some links for JavaFX blogs and projects that I've found useful...

http://www.javafx.com/ - The main website.
http://learnjavafx.typepad.com/ - James Weaver's blog. You can't go two steps in the JavaFX world without bumping in to this guy! He has the best resources for a beginner outside of the main website, but if you've done a lot of GUI work, you'll find that you already know (or expect) 95% of what he discusses. However, his stuff is always worth checking out, since there are often new things in there, even if you're a veteran.
http://jfxtras.org/ - Some extra stuff for JavaFX. The source code is a far better resource than the website, btw. They also host the MiGLayout component for JavaFX, which will Do What You Want (TM) when the built-in layouts get too clumsy (I find that happens real quick).
http://fxexperience.com/ - The JavaFX Experience blog. This is written by some Snoracle employees, but they also have weekly links articles.
Amy Fowler's Talk on JavaFX Layouts - The content of this talk will become absolutely critical once you've done some layout work. It really helps to confirm what you think you know and explain what you don't - brilliant resource in that respect.
http://www.projectmaitai.org/ - A larger JavaFX app written by Joshua Marinacci, who has recently left Snoracle for Palm. It's very sad that he's leaving - I recognise his name from the Java Posse podcast, even though I'm a JavaFX newbie.

That's all for now. Back to the code...

Rant: Door-to-Door Utility Companies

2009-11-06T16:28:00.004+11:00

I live in Werribee: the jewel of the Western Suburbs of Melbourne. I live on a very quiet street, less than 1 km from a supermarket and the local train station. The one complaint I have about where I live are the sheer number of people door-knocking on behalf of the utility companies (gas and electricity), trying to sell me things. Just lately, it has become incessant: there has been at least one representative per month for the last 6 months!

I don't mind people knocking on my door, but the problem is that they refuse to leave. When you tell them: "I'm sorry; I'm not interested, and don't have time to listen to your offer..." they will respond with something like: "But it's not an offer; we're only trying to save you money..." or some other rubbish. If I then ask for documentation regarding their offer: a letter, or a pamphlet, or a website, I get a response along the lines of: "well, that's what I'm here for: to explain it to you... look, here are the forms for you to fill out." That kind of response and lack of material from which a person could make a rational decision is just not good enough. The very worst is when you actually ask them to leave ("I'm sorry; can you please leave.") and they still refuse!!

It's time for utility companies to stop this sales approach.

Biologists: Vectorize Thyselves

2009-07-09T23:17:00.011+10:00

I'm currently investigating strains recorded from equine hooves. In this case, I wasn't directly involved with the experiment, but I'm helping out with the analysis. The analysis itself fits a common pattern: lots of trials of a similar type that all need to be processed in the same way.

Biologists often tackle this kind of work using spreadsheet programs. The advantages of a spreadsheet include the fact that your analysis is quite accessible, and it's computed in real-time. The main disadvantage (in this case, but also in many others I've seen) is that there is a lot of book-keeping required to synchronize the analysis that is performed on each dataset. The book-keeping introduces plenty of opportunity for error.

My solution to this problem is to take a "vectorized" approach. A good solution is a single program that can process each dataset in turn, and perform the analysis automatically. Thus, the amount of work required for the analysis is de-coupled from the sample size of the experiment. There is no book-keeping work to keep the analysis from each spreadsheet in-sync. It sounds simple enough, but few biologists either understand or implement this idea. The main (only?) drawback of this approach is its somewhat greater complexity; you need a real program to perform the analysis, rather than using a spreadsheet. That's really not much of a drawback though, once your experiment is sufficiently large.

Thanks to this work, I've also had the pleasure of using the excellent Python plotting library matplotlib. Once you get used to the basics, this library makes plotting using a spreadsheet feel like a terrible kludge.

Functional Programming

2009-06-30T10:41:00.002+10:00

This post is mainly an excuse for me to link to a blog I came across:

http://biosimilarity.blogspot.com/

I have been starting to use Scala over the last year. Initially I was drawn to the language purely by the functional programming experiences I had in Python: using map, filter, and list comprehensions. Scala promised similar tools, but with much better performance, and objects that just "feel" more robust than those in Python. In short, I began using it for very pragmatic reasons that had nothing to do with any underlying theory. However, over the last year, I have started to become more interested in the more theoretical aspects of functional programming, to the point where I'm now starting to reach out and trying to read blogs like the one above.

All of this reminds me of the kind of mind-bending experience I had when I first started to learn about C++ templates... they were a level of abstraction that I couldn't immediately translate to "mental bytecode", but that promised a massive amount of power and versatility. Admittedly, I was only about 13 when I started playing with C++ templates, but these new kinds of logic analyses are equally confusing now! It's all very interesting, even if it's not exactly approachable.

Analysis of Strains from a 45-Degree Rosette

2009-06-21T17:35:00.005+10:00

45 degree strain gauge rosettes are commonly used for measurement of strains. These rosette arrangements measure normal strains in three separate directions. From this data, the so-called "principal" strain state can be obtained. The principal strain state is just the orientation in which the shear strain is zero. At this orientation of zero shear strain, the two normal strains are called principal normal strains.

It can be quite tricky to obtain the principal strain state from the three gauge strains in a 45-degree rosette. Numerous textbooks provide equations for the principal normal strains, and generally these "just work". However, the angle of the principal strain state is often quite ambiguous. It's often difficult to figure out whether the angle is clockwise or anti-clockwise, which gauge it is relative to, and to which of the two principal normal strains it refers.

I have recently done some work on this problem in the context of measuring strains on the equine hoof wall. I have written a short description of the Analysis of Strains from a 45-Degree Rosette (PDF file; 47.9 KB). Please feel free to use this document (with an appropriate link to my blog), and please contact me regarding any corrections.

Blog link!

2009-06-12T01:31:00.003+10:00

I'd like to say thank you to Fran Jurga for publicizing a video that I created during my PhD. She wrote about it on her HoofBlog website, and since that time it has received a lot of attention.

It's great to see that something I worked on during my PhD has been so immediately useful for people. My PhD involved a lot of "basic science" work, which rarely has immediate influence. It helps a lot with motivation to find that people are so enthusiastic about it.

Getting started with PIC microcontroller programming under Mac OS X

2009-06-06T21:23:00.013+10:00

I recently started experimenting with PIC microcontrollers. Microcontrollers are small chips that contain all of the essential components of a whole computer. They can function as the embedded "brains" of any electronics project.

I found a lot of information online about programming PIC microcontrollers under both Microsoft Windows and various types of Linux. However, the information relating directly to Mac OS X was quite sparse. I began by working with both Linux and Windows under VMWare Fusion, but eventually migrated to OS X when the overhead of continually running VMWare just for PIC stuff became too much.

In this blog post, I'll explain how I set up my toolchain under OS X. My setup is still in its infancy, but I thought I'd share the information early.

1. Obtain a programmer

The first step was to obtain the required hardware - a programming device that can upload your program to the microcontroller chip. There are various programming kits available online and from electronics stores, but to be safe, I ordered a PICkit 2 programmer directly from Microchip Inc. It connects to the computer via a standard USB cable:

The PICkit 2 cost AU$54.70, which included shipping to Melbourne, Australia. It also came with a demo board, which included a PIC PIC16F887:

To get started, this was the only financial outlay (given that I already owned a modern Mac computer running OS X!).

2. Download and compile GPUTILS

GPUTILS provides programs to deal with compiling PIC assembly code. I used gputils-0.13.7 and compiled it using the standard commands:


$ ./configure
$ make
$ sudo make install

3. Download and compile SDCC

The next stage was to obtain a compiler. The compiler takes human-readable programs and converts them to machine code. I wanted to use the C programming language for my work, so I began using the Small Device C Compiler (SDCC).

I downloaded the source code for SDCC and compiled it using gcc. For this step, you need to have the OS X developer tools installed. I obtained SDCC from their subversion directory (read their documentation to learn about this), and then compiled it from the command line using the standard commands:


$ ./configure
$ make
$ sudo make install

4. Compile the SDCC PIC libraries

Inside the SDCC source directory, we now have to compile libraries for SDCC on the PIC16 architecture. This is done as follows:


$ cd device/lib/pic
$ ./configure
$ make
$ sudo make install
$ cd ../pic16
$ ./configure
$ make
$ sudo make install
$ cd ../
$ make
$ sudo make install

5. Download and compile PK2CMD

Microchip Inc. have provided source code for a program called pk2cmd which can be compiled under OS X and Linux. This program communicates with the PICkit 2 programmer. The idea is that once your code has been compiled by SDCC, pk2cmd controls the PICkit 2 programmer to program the chip.

I obtained the pk2cmd source code from the Microchip website. The required package (at the time of writing) is listed about 3/4 of the way down the page and is called "PK2CMD V1.20 Linux & Mac OS X Source Code with Makefile". After extracting the package, I compiled it for OS X 10.5.7 and installed it as follows:


$ make mac105
$ sudo make install

Take note of the makefile target that had to be used for OS X 10.5 (mac105). There is more information in the makefile included with pk2cmd.

6. Try a test program

The final stage is to check that your toolchain is working. The simplest way to do that is to try out a test program with the 44-pin demo board that comes with the PICkit 2 programmer. The test program below works for me:
With this code in a file called test.c, it can be compiled and uploaded to the demo board as follows:


$ sdcc -mpic14 -p16f887 test.c
$ pk2cmd -B/usr/share/pk2 -P -T -M -Ftest.hex

If everything is successful, you should see the LEDs on the board winking from left to right.

Semenggoh Wildlife Centre

2009-02-08T02:06:00.005+11:00

The Semenggoh Wildlife Centre was originally established to rehabilitate animals and birds who had been held in captivity by humans. Often, these animals were kept as pets by the local population, and later confiscated by Sarawak Forestry. Many of the animals at this centre were successfully prepared for life back in the wild, and subsequently released. This original mission of rehabilitation has since been moved to the nearby Matang Wildlife Centre. In present times, Semenggoh hosts a group of 24 Orang Utans (the Borneo species; Pongo pygmaeus), who inhabit an area of 650 hectares of primary rainforest.

Map of Semenggoh Wildlife Centre
View Larger Map
The Orang Utans of Semenggoh are semi-wild. They were introduced into the reserve after their rescue from humans. Since that time, several of the female Orang Utans have given birth within Semenggoh itself. Due to its relatively small size, the reserve is unable naturally to support the number of Orang Utans who live there, and so they are fed twice each day from wooden platforms. These feeding times present an opportunity for visitors to see the primates first hand.

During feeding times, the keepers of the reserve call the Orang Utans, and they descend to their food platforms by brachiation along a suspended network of ropes and cables. At a morning feeding, we initially saw several young Orang Utans, and were warned to stay well clear of them because they are known to throw things at human visitors. The young Orang Utans tended to stuff as much food as possible into their mouths before retreating higher into the trees to eat. Later, we saw the dominant male Orang Utan, called Ritchie, who appeared to be more relaxed, and remained on the feeding platform to eat some bananas.

After the feeding time, we paid to go on a hike around Semenggoh with one of the Orang Utan keepers, called Dominick. Dominick led us on a trail which passed cages that were previously used to quarantine birds, Orang Utans and gibbons, after their rescue from humans. It was also on this trail that we saw our first pitcher plants in Borneo. As usual, I sweated a lot in the high tropical humidity, and was quickly soaking from head to toe. It was a fantastic experience, and the only down-side (if it can be called one) was being attacked by tremendously voracious leeches. The leeches found their way throughout my shoes and socks, but I was able to remove most of them safely (safe for both myself and the leeches). The only leech to leave a mark was one that attached itself to the inside of my right upper arm. Trying to remove this one was a mistake, since it had already started feeding. The anti-coagulant it had released left the wound bleeding for a couple of hours, and produced a red circular mark which is still visible 3 days later!

Orang Utans and humans share a long period of post-natal maternal care. Orang Utan mothers take care of their young for a period of around 4 to 5 years after birth, and will only reproduce again when their offspring are independent. Naturally, Orang Utans are semi-solitary animals, and the crowded state of the Semenggoh reserve is only maintained through human assistance. Even with regular feeding times, the 650 hectares of the reserve is only enough room for a single dominant male; currently Ritchie. I wondered how genetic diversity will be maintained in the successfully-breeding captive population, but haven’t yet found out what plans are in place to achieve this. The only mention made of transporting Orang Utans was that Sarawak Forestry supplies them to the zoos in Western Malaysia.

Overall, Semenggoh Wildlife Centre was a great place to visit. We were lucky in seeing so many Orang Utans at the feeding platform. Several guide books mention that sightings are not guaranteed, and that it is worth setting aside a whole day in order to see both morning and afternoon feeding times. The keepers told us that the Orang Utans were more likely to attend feedings when the local plants were not fruiting, so it would be worth checking when this period occurs.

Don’t forget that more pictures of my journey are available online at my Flickr Photostream: http://www.flickr.com/photos/28808691@N05/

Sarawak Cultural Village

2009-02-07T17:55:00.016+11:00

The Sarawak Cultural Village is located at the Pantai Damai (Damai Beach) resort area, about 40 minutes’ drive from the city of Kuching. The village contains examples of the types of houses that are characteristic of those built by the ethnic groups that inhabit Sarawak. Upon entry to the village, visitors are given a “Village Passport” which contains information about the local people. This passport has a section in which tourists can collect stamps from each of the village houses that they visit.

A map of the Sarawak Cultural Village and Damai Beach
View Larger Map
The current population of Sarawak consists mainly of the indigenous Iban people, and immigrant Chinese and Malays. The Iban traditionally lived in groups in the lowlands, in longhouses that were built to last around twenty years. Although they were farmers, the Iban gained notoriety among early European travelers as head-hunters. In some social groups, Iban men were not considered worthy for marriage until they had brought home the head of an enemy from battle. The descendants of the Iban account for around 30% of the current population of Sarawak.

Longhouses were a kind of miniature “village within a house”. Limited privacy was afforded by segmenting the longhouse into rooms that were used for different activities. The effort expended in constructing the longhouse could thus be shared by all of the people that would inhabit it. In particular, providing shelter from the rains of Borneo would have been a great incentive for cooperation in the construction of the common roof.

In more mountainous regions, another ethnic group, the Bidayuh, also traditionally lived in longhouses. The Bidayuh consist of several sub-groups; namely the Jagoi, Biatah, Bukar-Sadong, Selakau and Lara peoples. The Bidayuh were often more gentle than the Iban, although they still collected the heads of their enemy in battle and hung them to smoke above the fire. Among their technological achievements, the Bidayuh invented indoor plumbing! The mountainous terrain on which they lived allowed them to dam rivers up-stream from their houses and use a gravity-fed system of bamboo conduits to supply water. The Bidayuh account for around 8.4% of the current Sarawak population.

The Melanau people built large houses in coastal regions that were supported about 12 m above the ground. They preferentially ate Sago palms, instead of the rice that was usually eaten by most of the other ethnic groups. The remaining indigenous people are often categorized under a single name: the Orang Ulu, which means “up-river dwellers”. The Orang Ulu comprise the Penan, Kayan, Kenyah, Kelabit and Lun Bawang. Among these groups, the Penan, who live in the dense jungles of Central Borneo, are often noted for their use of blowpipes in hunting.

The Cultural Village has an auditorium, at which dance performances are held twice each day. These dances are quite varied and show off the spectacular traditional dress of each of the ethnic groups. Having done some jungle trekking, I often had pause to wonder whether the long, elaborate traditional costumes were worn during daily life or only for special celebrations. Unfortunately, I never had that particular question answered. We visited in the late monsoon season, and the wet weather had apparently scared away most tourists from the village. The houses themselves were quite empty for most of our visit, with the exception of the very friendly Bidayuh longhouse, at which we were warmly welcomed.

My impression was that the Cultural Village was very much set up to cater to tourists. I think that it represented a good attempt to convey a superficial sense of the culture of the region, but that it was lacking depth in some areas. Aside from the village passport and some posters which were hung in each of the houses, there was little educational material available.

European culture was forced upon Sarawak by James Brooke, an unsuccessful trader, who arrived there in August 1838 after inheriting a sum of £30,000. When he arrived, a Bidayuh uprising was in progress against the Sultan of Brunei, who ruled Sarawak at that time. He helped to induce a peaceful settlement to the uprising and was granted the title of Rajah by the Sultan; thus becoming the first White Rajah.

Don't forget that more pictures of my journey are available online at my Flickr Photostream: http://www.flickr.com/photos/28808691@N05/

Arrival in Borneo!

2009-02-02T02:01:00.008+11:00

The first thing that I noticed when coming to Malaysia from Australia was the tropical weather. It hasn’t been extremely hot by Australian standards; maximum temperatures have been around 38°C. However, the humidity has been close to 100% during this first part of my trip. The high humidity means that it’s like living in a sauna. If you sweat, it doesn’t evaporate. The sweat just stays there, soaks your clothes, and makes you feel like you’re wearing a wet-suit. Difficult though it is to spend long hours outside, I've been forcing myself to, and I think that I’m gradually acclimatizing.

My girlfriend and I arrived in the city of Kuching, on the western coast of the island of Borneo, at 11:30 am yesterday. Borneo itself is split among three nations: Indonesia, Malaysia and Brunei. There are two states in the Malaysian portion; Sabah in the south west and Sarawak (of which Kuching is the capital) in the north west.

Literally translated, Kuching means “cat” in the Malay language. There are several cat monuments on traffic islands in the city, some complete with whiskers! The city also hosts many stray cats who seem somewhat more outgoing than those that inhabit Kuala Lumpur.

When we arrived at Kuching Airport yesterday, my girlfriend and I were met by a friend of her family; Mr Pei. We visited Mr Pei’s house to have lunch, and were serenaded by some of the family with an impromptu karaoke performance in Hokkien Chinese. From there, we went on to check in at the Harbor View hotel, situated near the Kuching waterfront on the Sarawak River.

Yesterday afternoon, we were met by another family friend, Uncle Loo, who is a native of Kuching. He took us to visit the weekend market on Jalan Satok (Satok road). Uncle Loo informed us that many of the stall-holders at this market are native river-dwelling people who live further inland than Kuching, and travel to the city only for the weekend market. They sleep on the streets of the market or in their cars. It would be interesting to follow some of these market gardeners back to their homes to see how they live, but that will probably have to wait for a future visit.

Today we visited the Kuching waterfront and collected some supplies for later in the week. We had planned to visit Fort Margherita, which lies across the Sarawak River from Kuching. Unfortunately, though, we caught the wrong boat across the river and landed at a place from which it wasn’t possible to reach the fort. The river boats are very small—maybe 3 m long—and lie low in the water. On the way back to Kuching, the captain of our small boat, with its complement of around 10 passengers, was unable to start the motor, so he paddled the boat by hand across the wide Sarawak River!

Kuching, like much of the rest of Malaysia, has extreme economic juxtaposition. Affluent, western-style shopping centers, complete with Starbucks cafes, are situated beside alleys full of crumbling houses. Dotted among the poorer houses are makeshift mounts for the dishes of satellite TV receivers. New construction work is also happening everywhere.

This year, Kuching has suffered unseasonally-long monsoon rains. The areas surrounding the city have been flooded, and local newspapers have reported that around 800 people have been displaced from their homes due to the flooding. It has rained almost continually since we arrived yesterday, but the city of Kuching itself doesn’t appear to have any flooded areas. We have also not seen any sign of the problems that the flooding has caused, but that may be due to our staying in the most affluent part of the city.

As a caucasian here, I draw some attention as a relative rarity. The Kuching population seems to be comprised of three main groups: native people, Malays, and Chinese. Caucasians are called Gwei Los by the Cantonese-speaking Chinese and Mat Salleh by the Malays.

Finally, this evening, we had dinner at a seafood area near to our hotel. I ate fried fern fronds and various other local vegetarian dishes, which were all very tasty. I eat garlic quite a lot, and the locals here also make very enthusiastic use of it in their cooking.

Tomorrow, we are going to the Sarawak Cultural Centre, and hopefully I will have time to write about it in the evening. Don't forget that more pictures of my journey are online at my Flickr photostream: http://www.flickr.com/photos/28808691@N05

Arrival in Malaysia

2009-01-31T00:53:00.003+11:00

I recently arrived in Malaysia for a one month holiday that my girlfriend and I booked early in 2008. It has been quite hot and very humid since we arrived. So far, we've visited some of Kuala Lumpur and Petaling Jaya, and are about to head out to Kuching, in Sarawak, on the island of Borneo.

Some of the pictures of my journey so far are online here: http://www.flickr.com/photos/28808691@N05

Bound properties in Scala

2008-08-28T09:38:00.008+10:00

I've been doing some GUI programming in Scala recently. Following the bean conventions in Java, I tend to require three things of each property I have on an object that will be used in a GUI:

A getter method.
A setter method.
A listener / notification mechanism for when the property changes.

The getters and setters are required for encapsulation, so that the internal representation of the properties of an object implementation can be changed without affecting the properties themselves. The notification mechanism is required for a GUI, so that one or more components that display the property can be updated when it changes.

The key problem with the ad-hoc implementation of properties (as in JavaBeans) is that they tend to make classes noisy, with all of the getX(), setX() stuff, and the listener mechanism. Things become even more complicated when properties take on the nature of collections, where multiple objects can conceptually be added or removed.

In a search for simplicity, I have been investigating JavaFX and the even more impressive ScalaFX. However, JavaFX does not yet allow bindings to properties implemented in a Java model, and ScalaFX, although very promising, is not quite ready for prime time. (It's more the potential for bugs I can't understand rather than API changes that have put me off ScalaFX for the time being.)

Until ScalaFX is ready, I have found a neat stop-gap solution. Inspired by the Scala wiki entry on Properties, I have set up my own properties as follows:
My Properties extend scala.swing.Publisher so it's possible to listenTo them for events. I defined a PropertyChanged event that is intended to be fired when a property changes. The properties also have apply() and update() methods which act as getters and setters respectively.

So, what advantages do these kinds of properties have over normal getX(), setX() and a listener mechanism?

Firstly, the contract of a property is clearly defined. There is no bean-like assumption that a setX() method on a class is related to a corresponding getX() method, nor that a particular event will be fired when a change occurs.

Secondly, each property is nicely modularized. Properties often refer directly to a value stored in a class, and it's easy to define a ValueProperty which performs this automatically. Then, for the enclosing class, you can write something like this:
Instead of something like this:
At first glance, the properties version of x may appear to break the principle of encapsulation, but it doesn't. If, in the future, I wish to change the implementation of x, I could do something like this:
Clients of the code will then be able to use the x property in the same way they always did.

This method of defining a clear contract for a property can also be extended to vector properties, in which the property contains a collection. It can be done fairly generally, so that the collection property may be backed in various ways by pre-existing collections (in the same way that you could implement a Map as a HashMap or a TreeMap or whatever).

A final advantage of these properties arises when they are bound into a GUI. For example, I have a text field derivative called BoundIntField which displays an integer value. To create an instance of this class, bound to property x I do the following:
And... that's it! The BoundIntField automatically listens for changes to x and updates itself. Also, when BoundIntField loses focus or receives an enter key press, it updates x. This is all done without breaking encapsulation, and without me having to write any duplicate glue code at all!

Ticketing - Fail

2008-08-24T23:20:00.003+10:00

Here in Melbourne, Victoria, Australia, our public transport system is far from perfect. The trains and buses that I catch to work each day are slow and unreasonably crowded. All I can really say in their favor is that they are only rarely delayed by more than 10 minutes, and only rarely are they cancelled. However, more than once, I have missed a train because I simply couldn't get through the doors due to over-crowding.

Public transport here is also expensive. As a result, our trains and stations are policed by small tribes of trench-coat-clad transit police who will gladly dispense large fines to those who are not in possession of a ticket. They are also notorious for being heavy-handed. I don't blame the individual transit police themselves; they're clearly under-staffed and over-worked. I hope readers can see that I'm describing a larger problem here.

The tickets themselves work by a process known as "validation". You insert the ticket into a machine, and the machine prints the date and time of the next expiry of the ticket. This information is also encoded in a magnetic strip that runs down the side of the ticket. Simple right? What could possibly go wrong?

A couple of weeks ago, this validation process failed me. I inserted my ticket into a machine, only to receive it back without a printed date stamp! I was fully aware that if I were to be stopped by one of the transit police, they would only see me as being in possession of a ticket that had not been validated. I would have no proof that I had actually validated the ticket and the machine had failed. Knowing this, I decided to buy a new ticket, and pay for my journey twice, rather than risking a large fine or a discussion with an unreasonable, dim-witted individual.

However, the proof of the machine failure is clearly evident in the picture of the ticket. Where the second trip (and second expiry date of the ticket) should appear, I have a blank line. I assure you that, even though I am entirely capable of it, there is no photographic trickery at work here. The machine simply failed me. Clearly, the magnetic strip encoding did not fail, and kept a record of my validation. Unfortunately, however, the transit police have no way to inspect the magnetic strip, so that would have been useless to me.

In the past, I've heard people claim that they tried to validate a ticket and it didn't work. The transit police still fined them. Now I wonder: were some of them actually telling the truth? I pay some $2500 to ride the trains each year. For that kind of money, I should have enough room at least to stand on a train when a seat is not available; I should have courteous, reasonable transit police; and I should have a ticket machine that works. So, of those three, let's see what I do have: Fail, Fail, and... oh yes, Fail.

Brushed Metal Toolbars in Java

2008-07-08T11:15:00.004+10:00

I've been working on a Swing application under OS X. I recently became a bit frustrated with the ugly, Java-style toolbars that it was using. They fit in well for Windows, but not on the Mac. So, I did a bit of searching and found the following two links for making Java applications pretty under OS X, one for Control Styles, and another for General Integration Issues.

I couldn't find any built-in solution for creating OS X Brushed Metal toolbars (like the ones in Mail, Pages, etc). However, with some layout help I was able to create a similar effect by using two buttons; one for the icon (segmentedCapsule) and the other for the text (segmentedCapsule with a null border). This is the result:

Not too bad for a Swing application, eh?

The only down side is that this is not a "proper" way to create this effect. In addition, the button text doesn't have a correct drop-shadow, and the interaction between the text and the button when you click it is not quite the same as OS X. However, it's much better than the default Java toolbar.

As a side note, I should mention that although this application uses Swing, it is written entirely in Scala.

Matrix Multiplication in Scala

2008-07-01T09:11:00.019+10:00

I recently started experimenting with the Scala programming language after hearing the JavaPosse guys raving about it. I found the online tutorials to be relatively shallow, so I went out and bought the Programming in Scala textbook. The book is a tutorial-style introduction to the language, and is quite well written. It's not yet finished, so I bought the wip PDF, and will receive the full textbook by mail when it's finally published.

Scala has a lot to like so far, although at first I found it quite daunting. I remember feeling that I was ready to get started with Python after doing the Python tutorial, but with Scala, it's clear that I have yet to learn about many of the features of the language.

For my first steps, I decided to make a simple dense matrix class, based on Scala Lists, which the textbook describes as "the workhorses of Scala". Initially, I wanted to make the matrix generic, but discovered that I would need some special voodoo to ensure that the type parametrization of the matrix would only occur for classes that had the appropriate operators (+, -, * and so on). That is way beyond me at this stage, so I went for a concrete implementation using Doubles

Here is a blow-by-blow account of the class:
The Matrix class takes a List of its rows as a parameter, and the rows are then stored in a val named elements.
Here, the number of rows and columns of the matrix are calculated from the list of elements, and we have a require directive which checks that all rows of the matrix have the same number of elements (ie. the same number of columns). The forall method returns true if a particular predicate is true for all members of a List. In this case, our predicate is constructed as the function _.length == nCols which is equivalent to the function object (x: List[Double]) => x.length == nCols.
These methods define addition and subtraction by adding rows of the matrices, while we get transpose for free from List. Again in these methods, the underscore notations are equivalent to function objects. For example, _+_ is in this case equivalent to (x: Double, y: Double) => x + y
This is a really fun way to multiply matrices. It directly implements the concept of multiplying rows of one matrix by the columns of the other. The inner yield produces a List[Double] formed from the dot products of each row of the left matrix by all of the columns of the right matrix. This produces a single row of the result matrix. The outer yield simply collects all of the rows of the result matrix.
For pretty-printing, this adds the toString method.
This object adds the ability to construct a Matrix from an array of Doubles provided to the apply method.

If the above code is in a file called Matrix.scala, then we can do the following in the Scala interpreter:
So, dense matrices with multiplication, addition, subtraction and transposition can be implemented fairly easily in Scala. The next steps could include making the Matrix class parametrizable (so we could have a Matrix[Int] or Matrix[Double]). It would also be interesting to investigate the performance of Array-based vs List-based matrix operations. I think array-based implementations would definitely win out in the case of operations that need frequent random element access (like Gaussian elimination), but may be no better than using lists for things like multiplication and addition.

iPhone Push Notification - Doesn't Solve My Problem

2008-06-24T08:55:00.001+10:00

The recent Apple WWDC heralded the arrival of Push Notification for third-party applications on the iPhone, which we can probably expect in the 2.0 release of the iPhone (and maybe the iPod Touch?) software. Much of the focus of the keynote presentation that covered this topic was the use of these notifications for social networking applications. If you have the infrastructure set up to run a server and send out these messages via Apple's exclusive link to the phone, then I think it's clear that the notifications will obviate the need for a background process. However, this only works for applications that fit one particular model.

Working in biomechanics, I'm interested in seeing the iPhone used as an activity monitor. The existence of both an accelerometer and the Core Location APIs means that the phone has all the ingredients of a basic fitness computer. Indeed, someone has already written a pedometer application, showing that this sort of functionality is possible. Whether or not it is practical is yet to be demonstrated, but unfortunately we can't properly develop fully-fledged versions of such applications anyway... read on.

Imagine some hypothetical software on your iPhone... let's say you go jogging and you use a personal fitness program designed for runners. The program uses Core Location to establish your initial position and logs your route. It uses the accelerometer to count your steps. With this information, it can give you speed, cadence and stride length statistics, it can tell you about the hills you've climbed, and even without heart-rate data it can evaluate your general fitness. The application could also log all of this data, so that you can see your training schedule and how you progress over time. All of this on a phone that fits in the palm of your hand! However, the dream ends as soon as you receive a phone call or want to listen to music while you run. If you do anything like this, you effectively end the application, and its logging will be suspended until you activate it again. Such interruptions would make the use of the program and the phone mutually exclusive of each other.

This is just one example of an application which, if it is to run on the iPhone, will need to be able to set up a true background process. You can't get around this kind of problem with push notifications. I agree with Apple that we shouldn't use background processes to listen for instant messages or to achieve background downloads. These can be done using callback mechanisms, whether they're server-pushed notifications or API hooks that Apple may provide. Also clear is the fact that an application like the one I've described above will be processor-intensive and will drain your battery relatively quickly. But just imagine how great it would be! I'm relatively sure that the iPhone battery would be able to cope with logging for the periods of time that most of us are actually capable of running. I hope Apple eventually gives us the ability to run true background processes, for times like this, when we actually need them.

Discarded Graphics - Equine Anatomy

2008-06-20T14:43:00.000+10:00

I decided I'd upload this picture online. It's a graphic that I created for a paper I've submitted, but it never made it into the final draft of the paper itself:
You can click on the image to get a larger version. A key to the image is as follows:

Bones and Joints:

R - Radius (this is fused to the ulna in the horse)
C - Carpus (like the human wrist)
M - Metacarpus (like the bones in the human hand)
S - Paired proximal sesamoid bones
F - Fetlock (metacarpophalangeal) joint
P1 - First / proximal phalanx
I - Proximal interphalangeal joint
P2 - Second / middle phalanx
D - Distal interphalangeal joint
N - Distal sesamoid (navicular) bone
P2 - Third / distal phalanx (coffin bone)

Tendons and Ligaments

CL - Distal check ligament of the tendon of the deep digital flexor muscle
DDFT - Tendon of the deep digital flexor muscle
IL - Interosseous / suspensory ligament (third interosseous muscle)
SDFT - Tendon of the superficial digital flexor muscle
EB - Extensor branches of the interosseous ligament
ECR - Tendon of the extensor carpi radialis muscle
LDE - Tendon of the lateral digital extensor muscle
CDE - Tendon of the common digital extensor muscle

Metacarpus

Red areas represent regions of attachments
T - Metacarpal tuberosity, for attachment of the tendon of the extensor carpi radialis muscle
MC2 - Second metacarpal (splint) bone
MC3 - Third metacarpal (cannon) bone
MC4 - Fourth metacarpal (splint) bone
Z - attachment zone for interosseous ligament
Cy - Metacarpal condyle
MSR - Mid-sagittal ridge of the metacarpal condyle

The image was created entirely using Open Source software, or software I created. The bones were digitized from the actual bones of a small pony, using photogrammetric software that I wrote myself. The tendons were then added on top of them "artisically", using Blender. Rendering was done using Aqsis, and labels were added using Inkscape.

I've decided to release this image under the Creative Commons Attribution License.

Publication - Always a good thing

2008-06-20T14:11:00.000+10:00

The final revision of one the papers from my PhD was recently published online. Publications are always good, but this one is particularly great because it's published in an Open Access journal. Open Access means that you get all of the benefits of a normal peer-reviewed journal, but the end users don't have to pay a subscription fee. One possible down side is that publication costs tend to be a little higher for the authors (although many closed journals cost a lot for publication too!). That wasn't a problem for me - my boss paid for it.

The paper itself is this one:

Merritt, J.S., Davies, H.M.S., Burvill, C. and Pandy, M.G. (2008) Influence of Muscle-Tendon Wrapping on Calculations of Joint Reaction Forces in the Equine Distal Forelimb. Journal of Biomedicine and Biotechnology. Article ID 165730, 9 pages, doi:10.1155/2008/165730.
This is a direct link.

Oh, and one more thing... it's published under the Creative Commons Attribution License.

New Blog

2008-06-20T14:09:00.000+10:00

OK - I'm starting yet another half-assed blog. I'm going to see what happens when I use a blogging service rather rolling my own.