2018-04-02 20:56

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