From 115d8142cc8777e0caa26867c6eb1b292bd60cf3 Mon Sep 17 00:00:00 2001 From: Blaise Thompson Date: Mon, 2 Apr 2018 20:56:06 -0500 Subject: 2018-04-02 20:56 --- software/chapter.tex | 102 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file 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 -- cgit v1.2.3