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 <ndevilla@free.fr>, 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.