General issues using MATLAB
Markus Bauer
Tips for programming
•
Before start writing code think of the goals
•
write either pseudocode or make a flowchart of the processes
that are necessary (example: fieldtrip toolbox, even – odd)
MODELLING - Examples:
Start Stim program
Type in subject number
Produce moving dots for backgroud,
100 frames
Load main task images
Start presentation
Repeat 4 times, Record response
Repeat again, Calculate mean over last 5 trials
no
Higher than alpha
Go the next image
lower than alpha
Increase image contrast
End of images?
yes
Calculate overall time, save result, end
Tips for programming
•
Before start writing code think of the goals
•
write either pseudocode or make a flowchart of the processes
that are necessary (example: fieldtrip toolbox, even – odd)
•
if the software you are writing is (part of) a bigger project, think
of how to organize the different functions
1. Modularization: which operations are needed by many
different functions of your software -> write an own function
for that (rather than include it in the main program)
Tips for programming
Tips for programming
•
Before start writing code think of the goals
•
write either pseudocode or make a flowchart of the processes
that are necessary (example: fieldtrip toolbox, even – odd)
•
if the software you are writing is (part of) a bigger project, think
of how to organize the different functions
1. Modularization: which operations are needed by many
different functions of your software -> write an own function
for that (rather than include it in the main program)
2. Keep the structure of the functions similar (e.g. input/output
format)
Tips for programming
•
Before start writing code think of the goals
•
write either pseudocode or make a flowchart of the processes
that are necessary (example: fieldtrip toolbox, even – odd)
•
if the software you are writing is (part of) a bigger project, think
of how to organize the different functions
1. Modularization: which operations are needed by many
different functions of your software -> write an own function
for that (rather than include it in the main program)
2. Keep the structure of the functions similar (e.g. input/output
format)
3. Think carefully of the data-format
Tips for programming
Within each function:
•
Give variables meaningful names, be careful using “i” (complex
number)
•
Avoid the use of loops – try to make use of matrices wherever you
can – that has consequences for the data-format you choose! (cell
arrays or structure arrays more difficult to handle…)
•
Make use of commenting – understanding code (from sb else or
years after writing it) can actually be more difficult than writing new
code
•
Trade off between ‘programming elegance’ and ‘readability’ / speed:
it is often possible to squeeze 5 lines of code done step by step into a
single line – but it is increasingly difficult to understand for humans
with limited working memory capacity  more errors, difficult to
debug + MATLAB itsself is not completely bug-free
Tips for programming
•
You may create subfunctions for repeated operations within one
function, however:
•
those will not be visible on the MATLAB path
•
Memory allocation within subfunctions is restricted – you cannot
dynamically create new variables during runtime (or debugging)
 only makes sense if an operation is repeated within only one
function, many times
Tips for programming
Process optimizing:
•
Once more: avoid loops
•
Memory allocation and fragmentation
•
even with modern computers memory is not unlimited
•
esp Windows suffers from inefficient memory-allocation, memory
becomes fragmented (LINUX much better)
http://www.mathworks.com/support/tech-notes/1100/1106.html
•
Solutions:
•
use lower bit depth (single instead of double [64bit…])
•
preallocate memory:
e.g. data = zeros(400,275,2000)*NaN;
rather than incrementally filling it
Working with data
Especially when writing a toolbox it is particularly important to think
about how you want to structure your data:
•
Which information do you want to keep? (header info,
preprocessing steps etc)
•
How shall the raw data be organized – observables (e.g. voxels
or channels) and repetitions (trials, sessions etc) – struct array,
cell array or simple matrix?
•
How are data stored? Requirement for specific directory
structure, multiple files or leave it to user?
•
How about ‘missing’ data, e.g. due to artefacts or otherwise
nonusable data points (e.g. bad channels in EEG)
Working with data
For missing data, as often found in empirical science, ‘NaN’ is a
convenient tool to fill these ‘gaps’.
Features of NaN, Inf:
•
can be included in any array (matrix), cell array etc – preserves
the regular shape of a matrix
•
can easily be retrieved with ‘isnan’ or ‘isinf’
•
for descriptive statistics ‘nanmean’, ‘nanstd’, ‘nanmedian’ exist,
that can handle NaN’s (part of statistics toolbox, but can easily
be written)
•
more advanced functions, e.g. ‘fft’, however, will crash…
Solution: eliminate observations that contain NaN’s for advanced
processing steps