The past few days have seen my fMRI analysis server taken over by a Linux virtual machine. I have installed FSL, and have been using MELODIC to plough my way through ICA analyses of fcMRI data, a first for me.
One of the annoyances I have had to deal with as part of this project has been the difference in input data required for SPM, for which my preprocessing stream is targeted, and FSL, for which it is not. Specifically, this difference has necessitated the conversion of data runs from 3D NIFTI files to a single 4d NIFTI file. FSL has a utility for this (fslmerge), but being the Linux novice that I am, I have struggled to script the merging within the virtual machine.
Thankfully, SPM has a semi-hidden utility for this conversion.
The GUI is located within the Batch Editor’s SPM>Util menu, and be default saves the specified 3D NIFTI images to a single 4D NIFTI image within the same directory. It doesn’t gzip the output image, like the fslmerge script, but, it’s scriptable using the ‘View>Show .m Code’ menu option, and it’s good enough for me.
Which brings me to why I sought out Codecademy in the first place (thanks to @m_wall for the twitter-solicited tip-off) – I am preparing to teach Psychology undergrads how to code. From 2012/2013 onwards, my academic life is going to be a little more ‘balanced’. As well as the research, admin and small-group teaching I currently enjoy, I’m also going to be doing some large-group teaching. Although I have plenty to say to undergraduates on cognitive neuroscience and cognitive psychology, I think giving them some coding skills will actually be much more useful to most. As my experience with Codecademy has recently reinforced to me, coding basics are the fundamental building-blocks of programming in any language. They will hold you in good stead whatever dialect you end up speaking to your computer in. What’s more, they will hold you in good stead whatever you end up doing, as long as it involves a computer: coding is the most versatile of transferable skills to be imparting to psychology graduates who (rightly) believe they are leaving university with the most versatile of degrees.
In what feels like a former life, I did a fair amount of research on déjà vu. In fact, it’s the domain in which I cut my psychological teeth, learned about the importance of good experiment design, and was eventually awarded a PhD.
One of the sadnesses of déjà vu research is that, although the sensation is so utterly intriguing, it is very difficult to experimentally generate (though see Anne Cleary’s work, particularly this paper). This has led people interested in déjà vu to try coming at it from a few different angles, including hypnosis, caloric stimulation* and, of course, drugs, drugs and more drugs. But, given its infrequent occurrence and its fairly memorable nature (a blessing and a curse, see below), the most consistently successful approach to studying the experience has been to use questionnaires.
Christine Wells, a collaborator and friend of mine at the University of Leeds is currently looking for people to complete her online questionnaire on anxiety, dissociative experiences and déjà vu. One of the nice departures from the standard questionnaire format, afforded by its online administration, is that you fill in Part 1 at your leisure, and the much shorter Part 2 as soon as possible after your next déjà vu experience. This is a really neat feature of the research, as it goes some way towards minimising the clichés that may be swamping our memories of déjà vu experiences, when assessed weeks and months after we have had them.
If you would like to take part in the research and are aged 18 or over, the following links may be of use:
Sure, filling in the questionnaires won’t leave you feeling anything like this guy, but that’s probably a good thing ( I wouldn’t wish an experience I could liken to the movie Hellraiser on anyone!). What it will do, is contribute to scientific understanding by telling us a little bit more about how people evaluate their déjà vu experiences.
* that’s ‘squirting water in someone’s ear’ to the layman
I heard Andrew Bird play his new album Break it Yourself at the Barbican on Monday. Having previewed it on NPR’s First Listen the previous week, I was familiar with the gist, but the show game me opportunity to scrutinise it. One rather important detail I had previously missed was the subject of the sixth album track ‘Lazy Projector.’
The song explores the fallible impermanence of memory:
It’s all in the hands of a lazy projector,
That forgetting, embellishing, lying machine.
As artistic interpretations of memory go, this isn’t ground-breaking, but the preceding lyrics set a context that belies a man who has thought about the purpose and mechanism of this fallibility.
If memory serves us, then who owns the master?
How do we know who’s projecting this reel?
The awareness that we can be fully conscious of ourselves, with our own psychological interests to protect, yet still be unaware of the source (and often the presence) of the unconscious reconstructions of memory is an insight into a paradox of memory. Bad memories hurt less the less we ruminate on them, but we aren’t able to actively, effortfully forget them. If we could, the projector would have no need to hide himself from the rememberer – they would be the same part of the same person working to attain the same goal. As it is, distraction, the passage of time, and all of the multitude of things that happen after a bad event give the projector opportunity to work undercover, in the only conditions in which he can work. These conditions give him the opportunity to get his alterations made before the rememberer has the chance to interrogate his memory and discover, to his relief, that it has softened.
It’s a lovely insight into memory, metacognition and the self and an example of why I appreciate Andrews Bird’s music.
I think the Raspberry Pi is going to be fantastic, for reasons summed up very nicely by David McGloin – the availability of such a cheap and versatile barebones technology will kickstart a new generation of tinkerers and coders.
It’s worth mentioning that this kickstart wouldn’t just be limited to the newest generation currently going through their primary and secondary school educations. Should my hands-on experience of the device live up to my expectations (and the expectations of those who have bought all the units that went on sale this morning), I will be ordering a couple for each PhD student I take on. After all, what’s the point in using an expensive desktop computer running expensive software on an expensive OS to run simple psychology experiments that have hardly changed in the past 15 years? What’s the point when technology like the Raspberry PI is available for £22? Moreover, if you can get researchers to present experiments using a medium that has also helped them pick up some of the most desirable employment skills within and outwith academia, expertise with and practical experience in programming, then I think that’s a fairly compelling argument that it would be irresponsible not to.
But won’t I have missed a critical period in my students’ development from technology consumers into technology hackers?
Every psychology student can and should learn how to code (courtesy of Matt Wall), and it’s never too late. I learned to code properly in my twenties, during my postdoc. The reason it took me so long was that I had never needed to code in any serious goal-driven way before this time. Until the end of my PhD, Superlab and E-Prime had been perfectly passable vehicles by which I could present my experiments to participants. My frustration with the attempts of these experiment presentation packages to make things ‘easy’, which ended up making things sub-optimal, led me to learn how to use the much ‘harder’ Matlab and Psychophysics Toolbox to present my experiments. Most importantly, I was given license to immerse myself in the learning process by my boss. This is what I hope giving a PhD student a couple of Raspberry Pis will do, bypassing the tyranny of the GUI-driven experiment design package in the process. Short-term pain, long-term gain.
In a few years, my behavioural testing lab-space could simply be a number of rooms equipped with HDMI monitors, keyboards and mice. Just before testing participants, students and postdocswill connect these peripherals to their own code-loaded Raspberry Pis, avoiding the annoyances of changed hardware settings, missing dongles and unre
liable network licenses. It could be brilliant, but whatever it is, it will be cheap.
This isn’t a comprehensive list by any means (that sort of thing can be found on Lifehacker, as you might expect), but over the past few years, I have tweeted and blogged about this a bit, so I’m simply tying up some of the odds and ends in one place.
I ran into the following error when trying to use a script to make Marsbar extract betas
Error in pr_stat_compute at 34
Indices too large for contrast structure
This problem occurred when I was trying to extract the betas for an unusual participant who had an empty bin for one condition, and for whom I had therefore had to manually alter the set of contrasts. In doing this, it turns out that I had inadvertently duplicated one contrast vector. Although the names were different, the number of contrasts had been amended to reflect the number of unique contrast vectors in SPM.xCon but not in Marsbar’s D, meaning that pr_stat_compute’s ‘xCon = SPM.xCon’ (line 23), did not return the same value as my own script’s ‘xCon = get_contrasts(D)’. This was causing the two xCons to differ in their length and the resultant error in pr_stat_compute.
The solution lay in removing the duplicate contrasts from the contrast specification for that participant.
In the blog, Dalcanton suggests a method for a) overcoming the scary blank-page and b) vetting grant proposal ideas at the earliest possible stage. as follows:
…I start a stupid ASCII file with two sections:
Potential Weaknesses to Shore Up
I then start filling out each with short bullet points listing every possible argument for or against what I’m proposing.
Dalcanton suggests working on this ascii file for half a day or so and then doing something that would never have crossed my mind – sending it to the experts and collaborators from whom you might normally solicit feedback at a much later stage.
Get their feedback about what they think the strongest selling points are, what their additional concerns are, and what arguments they would use to shore up weaknesses. Expand the file accordingly, so you have a record of everything that you think needs to go into the proposal. You’ll probably find that it’s a huge time savings to get this to your collaborators in this form, before you have a 10 page latex file with embedded figures.
This is brilliant. You seek feedback on the core idea, so you don’t have to write proposals that simply won’t appeal to reviewers. Now it’s obvious that this is what I should be trying to do with grant proposal ideas anyway, but the ascii file provides a way of seeking peer-review at this early stage and overcoming the myopic optimism can all to easily cloud judgement and drive a great deal of personal investment in an idea that simply won’t fly.