cl-ana is a free (GPL) library of Common Lisp code for doing data
analysis via either straightforward programming or dependency oriented
programming. It aims to be a general purpose framework for analyzing
small and large scale datasets, including binned data analysis and
visualization. Much effort has been made to ensure modularity so that
individual components may be used/re-used for a new purpose.
cl-ana is available via quicklisp (http://www.quicklisp.org/beta/);
for other dependencies see below.
Example code for using some of the functionality is contained in
various test.lisp files throughout the project; the full documentation
is located on the wiki page: http://github.com/ghollisjr/cl-ana/wiki
There is a Matrix live chat for cl-ana located here:
https://matrix.to/#/!cANztuGawRmRSdyLhu:matrix.org?via=matrix.org
Public address: #cl-ana:matrix.org
Whenever possible, features are implemented via generic functions so
that users can extend cl-ana to whatever they want to do.
The functionality of this framework is divided into two layers. The
lower layer provides basic libraries for the following:
* Tabulated data: Supports data tables read-from and written-to HDF5
files (buffered read-write), ntuples (like CERN's PAW uses), comma
separated value (CSV) files, and plists for all-in-memory operation.
Adding a new table type is as easy as extending the table class and
defining 4 functions for the table type. (The libraries cl-csv and
GSLL provide the backbone for the CSV and ntuple tables; the HDF5
table access is completely new.)
* Histograms: Supports categorical, contiguous, and sparse histograms
of arbitrary dimensions. Provides functional access to histograms
via mapping (which allows reducing) and filtering.
* Nonlinear least squares fitting: Allows plain-old lisp functions to
be fitted to data using the GNU Scientific Library (GSL); infers the
number of fit parameters the function takes from the initial
parameter guess. Can fit against alists of data & histograms and is
easily extended to allow fitting against other types by defining a
single function for the new type.
* Plotting: Uses gnuplot to plot histograms, data samples, plain-old
lisp functions, and strings interpreted as formulae.
* Generic math: Common Lisp doesn't provide user-extendable math
functions; cl-ana provides its own versions of the basic math
functions CL gives you but with the ability to extend them for
whatever types you want. Also provides use-gmath which easily adds
generic-math's symbols to a package even if you already use the
common-lisp package. Already provided are extensions to the generic
math functions for error propogation, quantities (values with
units), and treating CL sequences as tensors with all the usual math
functions being applied element-by-element in a MATLAB/GNU Octave
fashion.
The higher layer provides dependency oriented programming. Dependency
oriented programming is my own term for defining your program in terms
of targets needing execution as opposed to an explicit computation.
It is a hybrid of imperative and declarative programming. The target
table can be transformed to allow for optimizations. Provided
optimizations include table pass merge and collapse which minimize the
number of passes over source datasets.
Also included are various utilities which have use in a variety of
places.
The main principles of the project are:
1. Conceptual clarity and documentation. These are often neglected in
software development, to the point where reading code can cause one
to drink. Conceptual clarity refers to the way in which code is
written and the way in which algorithms are implemented: A slightly
slower but easier to understand implementation is favored above a
labyrinth of bit shifts. Documentation should always be provided
for any feature along with example usages--ESPECIALLY with example
usages, as these are sometimes more helpful than the actual
documentation.
2. Modularity/Bottom-up design. Whenever two components have a common
feature/function/dependency, this commonality should be placed in a
separate sublibrary. To limit sublibrary number explosion, this
should be done in conjunction with point 1 preserving conceptual
clarity. For example list utilities should be a sublibrary for
general purpose list functions. Further: If a feature can be
provided by either a set of utility functions or a type heirarchy,
strong preference should be given to the utility functions
approach; i.e. one should have to argue long and hard before
stratifying things into classes.
3. Lispyness. Whenever possible, already established motifs from Lisp
programming practices should be used. This goes for naming
conventions, access macros, and the general desire to provide at
least functional access to things.
Each sublibrary should go in its own directory and come with its own
.asdf file so that one can choose any subset of functionality to use
from the library.
As you will see in reading the code, I've tried to keep everything
well documented. I place a high emphasis on documentation since I
know how easy it is to fall out of practice. The last thing I want is
for the usual cargo-cult around old code to emerge.
Disclaimer: much of the code I've written has been part of my own
personal development as a Lisp programmer; this is my first
non-trivial project with Lisp, and coming from a C++ background I've
had to learn quite a few things along the way. This means that there
may be some dark corners of the code which need help from more
experienced coders/myself at a later time. In addition, I haven't
used any general testing framework. (To be honest I haven't needed
one either as I've done the development in a highly bottom-up way,
testing everything as I write it.) In short this is a work in
progress.
The code tries to be self documented, but I'm working on a
tutorial/user's guide on the github wiki page to explain how to use
the software to best effect.
The dependencies for this project are:
* HDF5 (http://www.hdfgroup.org/HDF5/)
* GSL (http://www.gnu.org/software/gsl/)
* CFFI (http://common-lisp.net/project/cffi/)
* GSLL (http://common-lisp.net/project/gsll/)
* Alexandria (http://common-lisp.net/project/alexandria/)
* iterate (http://common-lisp.net/project/iterate/)
* antik (http://www.common-lisp.net/project/antik/)
* closer-mop (http://common-lisp.net/project/closer/closer-mop.html)
* cl-csv (https://github.com/AccelerationNet/cl-csv)
* gnuplot (http://www.gnuplot.info/)
* cl-fad (http://weitz.de/cl-fad/)
* external-program (http://github.com/sellout/external-program)
All of the Lisp dependencies can be installed via quicklisp
(http://www.quicklisp.org/).
I copied the API for using gnuplot from gnuplot_i
(http://ndevilla.free.fr/gnuplot/). gnuplot_i was written by
N. Devillard <[email protected]>, released to the public domain, and is
a no-nonsense gnuplot session manager written in C.
I use SBCL (http://www.sbcl.org/) almost exclusively; however, I also
intentionally try to ensure that all the code only assumes what the CL
standard provides. Anytime implementation-specific functionality is
needed I try to use third party libraries for this.
