General issues using MATLAB

1. General issues using MATLAB Markus Bauer

2. 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)

3. 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 lower than alpha Go the next image Increase image contrast End of images? yes Calculate overall time, save result, end

4. 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 • 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)

5. Tips for programming

6. 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 • 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) • Keep the structure of the functions similar (e.g. input/output format)

7. 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 • 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) • Keep the structure of the functions similar (e.g. input/output format) • Think carefully of the data-format

8. 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

9. 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

10. 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

11. 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)

12. 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