[SciPy-Dev] splev

Charles R Harris charlesr.harris at gmail.com
Thu Jul 8 14:26:03 EDT 2010


On Thu, Jul 8, 2010 at 11:51 AM, Anne Archibald
<aarchiba at physics.mcgill.ca>wrote:

> On 8 July 2010 08:59, Charles R Harris <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Thu, Jul 8, 2010 at 12:02 AM, Joshua Holbrook <
> josh.holbrook at gmail.com>
> > wrote:
> >>
> >> On Wed, Jul 7, 2010 at 8:19 PM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >> >
> >> >
> >> > On Wed, Jul 7, 2010 at 10:06 PM, Anne Archibald
> >> > <aarchiba at physics.mcgill.ca>
> >> > wrote:
> >> >>
> >> >> On 7 July 2010 23:45, Charles R Harris <charlesr.harris at gmail.com>
> >> >> wrote:
> >> >> > Hi All,
> >> >> >
> >> >> > I opened ticket #1223 because the values returned by splev are not
> >> >> > zero
> >> >> > for
> >> >> > arguments outside of the interval of definition. Because splev
> >> >> > evaluates
> >> >> > b-splines, which all have compact support, I think zero is the
> >> >> > correct
> >> >> > value
> >> >> > for such arguments. However, I also find that some tests assume
> that
> >> >> > splev
> >> >> > extrapolates the interpolating polynomials defined in the first and
> >> >> > last
> >> >> > spans, which is what splev currently does.  Consequently I thought
> it
> >> >> > worth
> >> >> > bringing the topic up on the list for discussion before making the
> >> >> > commit
> >> >> > that changes the behavior.
> >> >>
> >> >> Please do not make this change. The extrapolation you get now is
> ugly,
> >> >> as polynomial extrapolation always is, but a discontinuity is
> >> >> considerably uglier. Remember that the arguments and range are both
> >> >> floating-point, so that roundoff error can easily move an argument
> >> >> outside the range; if extrapolation is used this is unimportant, but
> >> >> if the spline flatly drops to zero this will produce wildly wrong
> >> >> answers.
> >> >>
> >> >
> >> > Well, for my purposes extrapolation really screws things up. Note that
> >> > the
> >> > b-splines at the ends are in fact c_{-1}, i.e., discontinuous, and the
> >> > next
> >> > b-spline in has a discontinuous 1'st derivative, so on and so forth.
> The
> >> > discontinuities are mathematically correct, b-splines aren't
> >> > polynomials.
> >> > Maybe we can add a keyword?
> >> >
> >> > Chuck
> >> >
> >> >
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >
> >> >
> >>
> >> I personally agree with Anne. While discontinuities may be technically
> >> correct, I think the current behavior is more forgiving. If this is
> >> noted in the docs, I say things are g2g.
> >>
> >> Chuck: Is checking the interval yourself prohibitive?
> >>
> >
> > It's inconvenient and time consuming. I'm leaning towards adding a
> keyword
> > so that the user can choose one or the other behavior, say
> > extrapolation=True, which will not impact current usage.
>
> If you're going to do this it may make sense to offer a third option
> that raises an exception when outside the interval. There are again
> floating-point issues, but there are certainly times when it would be
> useful to find out right away that one had supplied bogus values.
>
>
I've got the extrapolation keyword thing done and could just let it take
values 0, 1, 2, so it shouldn't be too difficult to add the check, it can be
part of the error return. Can you think of a better word than extrapolation?

I should probably add this to the splder function also.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100708/60adac79/attachment.html>


More information about the SciPy-Dev mailing list