I’ve spent a frustrating day trying to drive out the bugs in one of my computer programmes. It’s a piece of computer code that is implementing equations describing how neurons talk to each other. I knew there was a bug because my modelled neurons were clearly not firing at the rate they should be. It wasn’t an easy bug to find – and on the way I ran across another one – but I got there in the end (about four hours work). Having found and fixed that bug, it’s clear that there is at least one more in there, and I’m now trying to track that one down. Although my neurons now fire at the rate I expect, my neurons don’t communicate with each other properly. This one’s proving really awkward to find. Haven’t got there yet.<\/p>\n
Finding bugs really is a slow process sometimes. It needs to be done very systematically. if you know what result you should get out for a given set of conditions, you can test every piece of the computer programme to see if it is doing what it should. Slowly you can home in on what the problem is.<\/p>\n
Often, when you find them, bugs can be really small things. Like a ‘+’ sign instead of a ‘*’ sign, or a variable name spelt incorrectly. At least the days of FORTRAN77 are over – when variable names could have a maximum of six characters. That led to many variables having very similar names and opening up a lot of potential avenues for bugs to creep in.<\/p>\n
My most difficult bug so far was a FORTRAN90 bug in a HUGE programme (thousands of lines of code) that I was working on in my previous job. (N.B. I didn’t write the programme – I was tasked with making some modifications to it.) It was clear that one piece of it wasn’t doing what it should, but finding the bug took me a week. In the end I had to work my way through the code line by line, checking calculations with a calculator, until I got it. And when I found it, it was unbelievably trivial. Just a typing mistake – a single character that shouldn’t have been there, but it altered what the line of code was telling the computer to do, and resulted in a big difference in the result of the end calculation.<\/p>\n
A lot of theoretical physics research these days is just what I’ve described. Forget analyzing strange equations describing black holes or neutrinos or quasi-fluids and predicting new phenomena – All too often what you are really doing is looking at computer code that ain’t working and pulling your hair out. <\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve spent a frustrating day trying to drive out the bugs in one of my computer programmes. It’s a piece of computer code that is implementing equations describing how neurons talk to each other. I knew there was a bug because my modelled neurons were clearly not firing at the rate they should be. It […]<\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[19,13],"yoast_head":"\n