remove superfluous files

cleanup.sh

-find . -name "*.pyc" -delete
-find . -name "__pycache__" -exec rm -rf {} \; 2> /dev/null
-rm -rf build dist oprofile_data
-rm -rf *.egg-info .eggs
-rm -f log.log*
-rm -f *.pdf *.png
-rm -rf nifty2go
-find . -type d -empty -delete
-rm -rf docs/build docs/source/mod

differences

-Significant differences between NIFTy3 and nifty4
-=================================================
-
-1) Field domains in nifty4 are stored in DomainTuple objects, which makes
-   comparisons between domains and computation of axis indices etc. much simpler
-   and more efficient.
-   No impact on the user ... these objects are generated whenever needed and
-   have all necessary functions to make them look like tuples of spaces.
-
-2) In nifty4 an operator's domain and target refer to the _full_ domains of
-   the input and output fields read/written by times(), adjoint_times() etc.
-   In NIFTy nightly, domain and target only refer to the (sub-)domain on
-   which the operator actually acts. This leads to complications like the need
-   for the "default_spaces" argument in the operator constructor and the
-   "spaces" keywords in all operator calls.
-   Advantages of the nifty4 approach:
-    - less error-prone and easier to understand; less code overall
-    - operators have more knowledge and may tune themselves better
-    - difficulties with the design of ComposedOperator (issue 152) resolve
-      themselves automatically
-   Disadvantages:
-    - operators cannot be used as flexibly as before; in a few circumstances
-      it will be necessary to create more operator objects than with the current
-      approach.
-      However, I have not found any such situation in the current code base, so
-      it appears to be rare.
-
-3) nifty4 uses one of two different "data_object" modules for array
-   storage instead of D2O.
-   A "data_object" module consists of a class called "data_object" which
-   provides a subset of the numpy.ndarray interface, plus a few additional
-   functions for manipulating these data objects.
-   If no MPI support is found on the system, or if a computation is run on a
-   single task, nifty4 automatically loads a minimalistic "data_object"
-   module where the data_object class is simply identical to numpy.ndarray.
-   The support functions are mostly trivial as well.
-   If MPI is required, another module is loaded, which supports parallel
-   array operations; this module is in a working state, but not polished and
-   tuned yet.
-
-4) Spaces no longer have a weight() method; it has been replaced by
-   scalar_dvol() and dvol() methods, which return the scalar volume element,
-   if available, or a numpy array with all volume elements for the respective
-   space.
-   By using scalar_dvol() whenever possible, one can save quite some
-   time when computing Field.weight().
-
-5) renamings:
-   get_distance_array -> get_k_length_array
-   get_unique_distances -> get_unique_k_lengths
-   (to be specific which "distances" are meant and to make more clear why this
-   only exists for harmonic spaces)
-   kindex -> k_lengths
-   (because this is not an index)
-
-6) In nifty4, PowerSpace is not a harmonic space.
-
-7) In nifty4, parallel probing should work (needs systematic testing)
-
-9) Many default arguments have been removed in nifty4, wherever there is no
-   sensible default (in my opinion). My personal impression is that this has
-   actually made the demos more readable, but I'm sure not everyone will agree
-   :)
-
-10) Plotting has been replaced by something very minimalistic but usable.
-   Currently supported output formats are PDF and PNG.
-
-11) Co-domains are now obtained directly from the corresponding Space
-   objects via the method "get_default_codomain()". This is implemented for
-   RGSpace, LMSpace, HPSpace and GLSpace.
-
-12) Instead of inheriting from "InvertibleOperatorMixin", support for numerical
-   inversion is now added via the "InversionEnabler" class, which takes the
-   original operator as a constructor argument.
-
-13) External dependencies are only loaded when they are really needed: e.g.
-   pyHealpix is only imported within the spherical harmonic transform functions,
-   and pyfftw is only loaded within the RG transforms.
-   So there are no mandatory dependencies besides numpy (well, pyfftw is
-   more or less always needed).
-
-14) A new approach is used for FFTs along axes that are distributed among
-   MPI tasks. As a consequence, nifty4 works well with the standard version
-   of pyfftw and does not need the MPI-enabled fork.
-
-15) Arithmetic functions working on Fields have been moved from
-   basic_arithmetics.py to field.py.
-
-16) Operators can be comined via "*", "+" and "-", resulting in new combined
-   operators.
-
-17) Every operator has the properties ".adjoint" and ".inverse", which return
-   its adjoint and inverse, respectively.
-
-18) Handling of volume factors has been changed completely.