On Feb 14, 2013, at 11:26 PM, Mike Jarvis <notifications@github.com> wrote:

> In galsim/base.py:
> 
> >      @param image           The Image from which to construct the object.
> >                             This may be either an Image (or ImageView) instance or a string
> >                             indicating a fits file from which to read the image.
> > -    @param interpolant     Either an Interpolant2d (or Interpolant) instance or a string indicating
> > -                           which interpolant should be used.  Options are 'nearest', 'sinc', 
> > -                           'linear', 'cubic', 'quintic', or 'lanczosN' where N should be the 
> > +    @param x_interpolant   Either an Interpolant2d (or Interpolant) instance or a string indicating
> > +                           which real-space interpolant should be used.  Options are 'nearest',
> > +                           'sinc', 'linear', 'cubic', 'quintic', or 'lanczosN' where N should be the
> > +                           integer order to use. (Default `interpolant = galsim.Quintic()`)
> > +    @param k_interpolant   Either an Interpolant2d (or Interpolant) instance or a string indicating
> > +                           which k-space interpolant should be used.  Options are 'nearest',
> > +                           'sinc', 'linear', 'cubic', 'quintic', or 'lanczosN' where N should be the
> >                             integer order to use. (Default `interpolant = galsim.Quintic()`)
> I think this needs some kind of strong warning that it should be left as Quintic, as per Gary's investigation of interpolated images, finding the quintic with pad_factor=4 was optimal.
> 
I had put "The default values for `x_interpolant`, `k_interpolant`, and `pad_factor` were chosen based on preliminary tests suggesting that they lead to a high degree of accuracy without being excessively slow.  Users should be particularly wary about changing `k_interpoland` and `pad_factor` from the defaults without careful testing. The user is given complete freedom to choose interpolants and pad factors, and no warnings are raised when the code is modified to choose some combination that is known to give significant error.  More details can be found in devel/modules/finterp.pdf, especially table 1, in the GalSim repository." in the docstring for this class.  Do you think that's not strong enough?
> I might even recommend making this and pad_factor undocumented in the docstring, with just a comment to developers that they exist for detailed investigations of different interpolation schemes.
> 
Hmmm.  Maybe that would be best.  But my concern is that someone who is savvy enough to notice those params might go wandering off doing weird things if we don't have the documentation (above) about those parameters and the warning not to randomly change them.