[SciPy-Dev] schedule for scipy 0.9.0 [scipy.interpolate]
Fri Nov 12 14:09:35 CST 2010
On Fri, Nov 12, 2010 at 12:25 PM, Charles R Harris
> On Fri, Nov 12, 2010 at 9:48 AM, <email@example.com> wrote:
>> On Fri, Nov 12, 2010 at 11:21 AM, Pauli Virtanen <firstname.lastname@example.org> wrote:
>> > Fri, 12 Nov 2010 23:45:39 +0800, Ralf Gommers wrote:
>> >> I'm interested to hear what you think about releasing scipy 0.9.0 in
>> >> the
>> >> near future, and if you have any things that should go in or be fixed
>> >> for 0.9.0. If we want to keep to a ~6 month release schedule then we
>> >> should branch around the end of this month and have a final release in
>> >> January.
>> > Sounds OK to me. I think we should try to time it so that it gets in
>> > Ubuntu.
>> > Some tasks that would be nice to do before that in scipy.interpolate:
>> > - Write a interpolation routine for N-d *structured* interpolation.
>> > (ndimage.map_coordinates is difficult to find, so it would be useful
>> > to have an interpolation-oriented routine for that in
>> > scipy.interpolate).
>> > - Deprecate interp2d, as it does not work well for most problems,
>> > and its calling convention is a bit wonky. People should use either
>> > `griddata` or splines depending on what they want to do.
>> > - Clean up the spline routines:
>> > - We have two incompatible implementations for 1-D splines there,
>> > on from FITPACK, and a pure-Python one by Travis. I don't remember
>> > if one of them has an advantage over the other.
>> > I think that either `splmake` the one should be deprecated, or
>> > the spline representation it uses made compatible with FITPACK.
>> > - Deprecate the bispl* and spl* routines, leaving only the
>> > object-oriented interface.
>> These are in some cases more robust and give better control, the
>> classes look a bit "messy". I would only depreciate them if the
>> classes get some makeover.
> Which classes? If the ones in interpolate, I agree that they are a bit
interpolate UnivariateSpline, and BivariateSpline classes (or family
of classes) which are supposed to be the successor or frontend to the
bispl* and spl* routines.
> The simple case of running a 1-d spline through a set of points, with some
> provision for handling the boundaty conditions, is often done without using
> b-splines. Doing tricky things with varying degrees of discontinuity at the
> knot points or generating least squares fits is better done with b-splines.
> If we are going to use just one package I would stick with fitpack, or an
> equivalent subset of opennurbs. The latter is a large package in c++
> intended for CAD with the usual tangle of inter-dependencies, but the core
> bits don't look like too much trouble to disintangle and convert to simple
> SciPy-Dev mailing list
More information about the SciPy-Dev