Wiki » History » Version 11

Luis Figueira, 2012-09-03 03:36 PM

1 1 Luis Figueira
h1. Wiki
2 1 Luis Figueira
3 2 Redmine Admin
h2. Requirements
4 2 Redmine Admin
5 2 Redmine Admin
Third day of a three-day Software Carpentry bootcamp. Hours are 0900-1630 approx.
6 2 Redmine Admin
7 2 Redmine Admin
Should consist of working through introductory examples of audio processing techniques in Python, with small-group exercises for self-guided learning (helpers should be available in the room). Topics of interest should include reading audio data from files, synthesising signals and playing them, saving results back to audio files, simple filters, simple analysis techniques, and interactive plotting.
8 2 Redmine Admin
9 2 Redmine Admin
The material will need to follow from the subjects covered in the first two days of the bootcamp, such as unit testing and test-driven development, writing readable code, use of version control (we'll be using Mercurial in the bootcamp but the principles should mostly be general ones), selection and use of the most appropriate existing Python modules, etc.
10 2 Redmine Admin
11 10 Luis Figueira
h3. Software Requirements
12 10 Luis Figueira
13 10 Luis Figueira
* Current Software Requirements page
14 10 Luis Figueira
15 10 Luis Figueira
* Software installation help wiki page
16 11 Luis Figueira
** [[SWCAudioDaySoftware|Audio Day Software]]
17 10 Luis Figueira
18 1 Luis Figueira
h2. Related Links
19 1 Luis Figueira
20 1 Luis Figueira
* Bootcamp announcement: http://soundsoftware.ac.uk/york2012-bootcamp
21 1 Luis Figueira
* Software carpentry site: http://software-carpentry.org
22 1 Luis Figueira
* Audio Presentation (Becky's): http://software-carpentry.org/4_0/media/audio/
23 1 Luis Figueira
 
24 2 Redmine Admin
h2. Open questions
25 2 Redmine Admin
26 2 Redmine Admin
Can we come up with some good examples of simple audio processing problems that readily admit test-driven solutions? I think there will be a lot of interest in the question of how to apply automated testing and unit tests to audio research software.
27 3 Redmine Admin
28 3 Redmine Admin
Any examples we use will need to be simple enough to be worked through by people who have not necessarily worked on that specific aspect of audio programming before, but relevant enough that they give a clue about where to begin when working on their own problems subsequently.
29 3 Redmine Admin
30 4 Redmine Admin
* "Here":https://code.soundsoftware.ac.uk/projects/cepstral-pitchtracker/repository/entry/test/TestPeakInterpolator.cpp is an example with some basic unit tests for a peak interpolation method (in C++ with Boost) -- I think we can do better, but with what?
31 4 Redmine Admin
* Other things we talked about: testing FFTs using 4 points and known inputs/outputs (e.g. pure cosine); how to unit test e.g. a low-pass filter using expected outputs
32 5 Redmine Admin
33 5 Redmine Admin
h3. Things worth bearing in mind
34 5 Redmine Admin
35 6 Redmine Admin
* Validation vs. verification. Validation is what the evaluation section of a typical paper does -- tries to establish how well the method / model reflects reality. Verification is trying to establish whether the code implements the method or model at all. Unit testing is a code verification tool.
36 1 Luis Figueira
* That means, in a sense we aren't really testing the method. We're testing the implementation and the API. We have no expectation to test using "real-world" data. Tests should be small (and take next to no time to run).
37 7 Redmine Admin
* We have to accept some limitations because of this, and make sure we test at the right level. For example, we can't meaningfully test an FFT _library_ using only 4-point FFTs, because the library may select a totally different implementation depending on the FFT size. But we _can_ do some meaningful testing of a single implementation that way, or of a wrapper library (e.g. Python module calling out to FFTW).
38 8 Redmine Admin
* A standard for whether our testing is good enough: can I swap in a totally different implementation later, and know that it still works? In some cases this may mean we don't want to test too much for exact values: for example the peak interpolator above could legitimately return different results depending on what interpolation method is used. 
39 9 Chris Cannam
40 9 Chris Cannam
h3. Misc meeting notes etc
41 9 Chris Cannam
42 9 Chris Cannam
* [[31Aug2012|31st August 2012]]