analysis:nsb2014:week0
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
analysis:nsb2014:week0 [2014/07/20 09:49] mvdm [2. Plan from Raw data to Result] |
analysis:nsb2014:week0 [2018/07/07 10:19] (current) |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| To see why this principle is critical, consider a complex multistep experimental procedure such as surgically implanting a recording probe into the brain. In this setting, the surgeon //always// verifies the success of the previous step before proceeding. One would never attempt to insert a probe without making sure dura is removed first; or apply dental cement to the skull without first making sure it is dry. Apply the same mindset to analysis and confirm the success of every step before proceeding! | To see why this principle is critical, consider a complex multistep experimental procedure such as surgically implanting a recording probe into the brain. In this setting, the surgeon //always// verifies the success of the previous step before proceeding. One would never attempt to insert a probe without making sure dura is removed first; or apply dental cement to the skull without first making sure it is dry. Apply the same mindset to analysis and confirm the success of every step before proceeding! | ||
| - | === 2. Plan from Raw data to Result === | + | === 2. Plan ahead (from raw data to result) === |
| Before the start of data collection, you should identify the steps in your data processing "pipeline" -- that is, the flow from raw data to the figures in the resulting publication. Doing this can often highlight key dependencies and potentially important controls that help you collect the data such that you will can actually test what you set out to do. | Before the start of data collection, you should identify the steps in your data processing "pipeline" -- that is, the flow from raw data to the figures in the resulting publication. Doing this can often highlight key dependencies and potentially important controls that help you collect the data such that you will can actually test what you set out to do. | ||
| Line 81: | Line 81: | ||
| Note that each analysis step is implemented by a function, with a ''cfg'' struct to specify some parameters of the transformation (e.g. the frequency band to filter). The overall workflow is accomplished by calling the appropriate functions on evolving data types. Perhaps some of the functions you need already exist, or you may need to write some of them. Either way, making the analysis steps explicit in this way provides a good starting point for writing well-organized code. | Note that each analysis step is implemented by a function, with a ''cfg'' struct to specify some parameters of the transformation (e.g. the frequency band to filter). The overall workflow is accomplished by calling the appropriate functions on evolving data types. Perhaps some of the functions you need already exist, or you may need to write some of them. Either way, making the analysis steps explicit in this way provides a good starting point for writing well-organized code. | ||
| - | === 3. Good programming practice === | + | === 3. Use good programming practice === |
| - | There are many resources and opinions on what constitutes good programming practice, but some of the most important ideas are: | + | There are [[http://stackoverflow.com/questions/550861/improving-code-readability | many]] resources and opinions on what constitutes good programming practice. A few of the most important are: |
| - | + | ||
| - | * Don't repeat yourself. Implementing each piece of functionality only once means your code will be easier to troubleshoot, re-use, and extend. | + | |
| - | * Readability. Whatever analysis you do, you will have to do it again. Maybe tomorrow, maybe next year. You might think you will remember what you did and why, but you probably won't. Even if somehow you do, it's likely someone else will have to run and understand your code. Whether or not they can will reflect on you. So, use expressive variable and function names. Comment a lot. Write example workflows. | + | |
| + | * //Don't repeat yourself//. Implementing each piece of functionality only once means your code will be easier to troubleshoot, re-use, and extend -- as well as easier to read. | ||
| + | * //Unit testing//. Provide test scenarios with key pieces of code where you know what the expected outcome is. For data analysis this commonly involves generating artificial data such as white noise or Poisson spike trains of a certain average firing rate. These tests will be extremely helpful in interpreting your data later, and to check if changes you make to the code have not broken its functionality. | ||
| + | * //Readability//. Generally, whatever analysis you are doing, you will probably have to do again. Maybe on the same data after you make a change to the code, maybe after you collect more data. Maybe tomorrow, maybe next year. It is tempting to assume you will remember what you did and why, but this will not always be the case! Plus, even if //you// do, it's likely someone else (such as your adviser, or a collaborator) will have to run and understand your code. Whether or not they can will reflect on you. | ||
| + | * //Consistency//. Use consistent naming schemes for different kinds of variables and functions; always place constants and parameters at the start of each file. | ||
| === 4. Write to share === | === 4. Write to share === | ||
analysis/nsb2014/week0.1405864183.txt.gz · Last modified: 2018/07/07 10:19 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
