diff options
| -rw-r--r-- | software/chapter.tex | 102 |
1 files changed, 91 insertions, 11 deletions
diff --git a/software/chapter.tex b/software/chapter.tex index 8bc81af..83fd207 100644 --- a/software/chapter.tex +++ b/software/chapter.tex @@ -119,12 +119,14 @@ of researchers and a contracted team of software engineers. % \subsection{Testing} % ---------------------------------------------------------------------------
-PrabhuPrakash2011a---lots of good stuff under ``Scientists do not rigorusly test their programs''
+PrabhuPrakash2011a---lots of good stuff under ``Scientists do not rigorously test their programs''
\subsection{Lifetime} % --------------------------------------------------------------------------
PrabhuPrakash2011a--- subsection ``long history of software development''
+Challenges with portability, and updating to ``modern standards''.
+
\subsection{Optimization} % ----------------------------------------------------------------------
PrabhuPrakash2011a: ``scientists do not optimize for the common case'', ``scientists are unaware of
@@ -132,29 +134,35 @@ parallelization paradigms'' \subsection{Maintenance} % -----------------------------------------------------------------------
+Scientific software, especially software maintained by graduate students, tends to be very hard to
+maintain. %
+This problem is compounded by the long lifetime of such software, and the poorly defined
+requirements and lack of documentation and testing. %
+Often times, scientific software ends up being a mess of layer upon layer of incongruent pieces
+written by generation upon generation of student. %
+Worse, software is sometimes abandoned or left untouched to become a crucial but arcane component
+of a scientific research project. %
+
\section{Good-enough practices} % ================================================================
In their [...] perspective, ``Good enough practices in scientific computing'', (from which this
section gets its name) [WILSON ET AL] describe a set of techniques that, in their words, ``every
researcher can and should consider adopting''. %
+\subsection{Write clearly and document often} % --------------------------------------------------
+
Let the computer do the work...
Write programs for people, not computers. %
+\subsection{Do not reinvent} % -------------------------------------------------------------------
+
Don't repeat yourself, or others (we built on top of scipy, hdf5).
-Plan for mistakes / use testing.
+\subsection{Avoid premature optimization} % ------------------------------------------------------
Write first, optimize later.
-Document document docuement.
-
-Collaborate.
-Code review...
-Issues...
-Make incremental changes...
-
\subsection{Data formats} % ----------------------------------------------------------------------
% HDF5
@@ -163,10 +171,82 @@ Make incremental changes... % OBJECT ORIENTED PROGRAMMING
-\subsection{Version control} % -------------------------------------------------------------------
+\subsection{Collaboration and version control} % -------------------------------------------------
+
+Plan for mistakes / use testing.
+
+Document document docuement.
+
+Collaborate.
+Code review...
+Issues...
+Make incremental changes...
% SOURCE CONTROL AND VERSIONING
\subsection{Licensing and distribution} % --------------------------------------------------------
-% LICENSING AND DISTRIBUTION
\ No newline at end of file +% LICENSING AND DISTRIBUTION
+
+\section{Object oriented programming} % ----------------------------------------------------------
+
+The work in this dissertation makes heavy use of object oriented programming, so some very basic
+introduction to the concept seems warranted. %
+Object oriented programming (OOP) is a \emph{programming paradigm}. %
+Other popular paradigms are procedural programming and functional programming. %
+Python is a popular programming language which allows for OOP. %
+This section will discuss OOP in the context of a Python implementation. %
+
+The basic idea of OOP is defining object types (classes) that are self-contained. %
+These classes define pieces of associated data (attributes) and associated procedures (functions)
+within themselves. %
+Once the class is defined, instances of that class are created. %
+Instances, as the name implies, are just specific ``concrete occurance'' of a given class. %
+The classic example: \python{Dog} is a class, \python{fido}, \python{spot}, and \python{duke} are
+three dogs---three instances of the dog class. %
+
+OOP is easier to demonstrate than explain, so let's have some fun with some working Python
+examples. %
+First, we will define a class. %
+\begin{codefragment}{python}
+class Person():
+
+ def __init__(self, name, favorite_food=None, hated_food=None):
+ self.name = name
+ self.favorite_food = favorite_food
+ self.hated_food = hated_food
+
+ def react_to(self, food):
+ if food == self.favorite_food:
+ return 'yum! my favorite'
+ elif food == self.hated_food:
+ return 'gross---no thank you'
+ else:
+ return 'meh'
+\end{codefragment}
+Now I can make some instances of that class, and access their attributes and methods. %
+\begin{codefragment}{python}
+>>> mary = Person(name='Mary', favorite_food='pizza', hated_food='falafel')
+>>> jane = Person(name='Jane', favorite_food='salad')
+>>> mary.react_to('falafel')
+'gross---no thank you'
+>>> jane.react_to('salad')
+'yum! my favorite'
+>>> mary.favorite_food
+'pizza'
+>>> jane.react_to(mary.favorite_food)
+'meh'
+\end{codefragment}
+To the knowledge of this author
+
+\section{Hierarchical data format} % -------------------------------------------------------------
+
+FITS
+
+HDF5
+
+CDF (Common Data Format)
+
+\section{Scientific Python} % --------------------------------------------------------------------
+
+Numpy, SciPy
\ No newline at end of file |