#### Important ####

Clean up docstrings so it's all on the same level.  Either include
math in docstrings or don't.  Either use matrix or vector space
notation, maybe depending on arrays or handles implementations.  Maybe
include an "algorithms" section like matlab.

Allow for larger col chunks if extra memory.

Remove requirements for having arguments be lists. This is not
pythonic.

Generalize the parallelization so that users can have parallel Vector
classes.  That is, modred would work in units of larger groups of
processors/nodes, MPI communicators, and the lower level
user-implemented parts would operate within one of these
communicators. The user-defined Vector class could then have its
memory distributed amongst multiple nodes within one communicator.
This would completely eliminate any size restrictions on the data and
make modred amazingly useful for huge datasets. It wouldn't be that
hard either, one needs to generalize the node/processor current
paradigm to communicators, and mpi4py already has the hard stuff
implemented.

#### Less important ####

Make the formatting at line breaks better, do not break at '.'s. Talk
to Clancy about possible solutions to our many line breaks.  Find a
better, more natural, way to deal with line continuation/breaks. As it
is, the code is chopped to bits and hard to read.  It's completely
imposed and unnatural currently.

Make a style guide for future developers.

Automatically detect the max_vecs_per_node.  Or in the future,
max_vecs_per_communicator.  This would require some fancier things,
like determining the available RAM and the size of a vector object. It
might not be possible since some memory is used by the vector objects
when doing inner products, etc. We could leave a safety factor though,
and maybe leave space for 1-2 vecs/modes for scratch space for the
user's functions.

