[SciPy-dev] RFR: fixing scipy.special.orthogonal
Charles R Harris
charlesr.harris@gmail....
Sun Oct 25 21:19:11 CDT 2009
On Sun, Oct 25, 2009 at 7:48 PM, David Cournapeau <cournape@gmail.com>wrote:
> On Mon, Oct 26, 2009 at 10:23 AM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> >
> >
> > On Sun, Oct 25, 2009 at 6:56 PM, Pauli Virtanen <pav@iki.fi> wrote:
> >>
> >> Hi,
> >>
> >> http://codereview.appspot.com/140053
> >>
> >> The orthogonal polynomial routines in scipy.special.orthogonal are
> >> cumbersome to use if you only want *values* of the polynomials at a few
> >> points.
> >>
> >
> > I'm not familiar with these routines. In what way is the evaluation at a
> few
> > points cumbersome?
> >
> >>
> >> This patch adds separate vectorized eval_* routines for them.
> >>
> >> What is more controversial, it also hooks these routines in orthopoly1d,
> >> so that
> >>
> >> >>> special.chebyt(100)(0.98)
> >> 0.37728975480815219
> >>
> >> instead of the current
> >>
> >> >>> special.chebyt(100)(0.98)
> >> -5.2908451051968135e+20
> >>
> >
> > Well, the first certainly looks like an improvement ;) I'm about to
> commit a
> > chebyshev class in numpy, along with a revised polynomial class. At the
> > moment they need more documentation and testing.
> >
> > Apropos that commit in general, I was going to put them in their own
> > directory, "polynomial", at the same level as fft etc., but not have them
> > automatically loaded when numpy is imported. That is, one would have to
> > explicitly do import numpy.polynomial. The modules also generate the
> class
> > on the fly using a standard string.Template class.
>
> I have not followed the polynomial discussion - why was it decided
> that it would be included in numpy ? I thought that new features for
> numpy should be avoided ?
>
>
Well, there is the polynomial class already, and really folks should be
using Chebyshev polynomials for many of those things, they are just one of
the numerical basics. I also wanted them for returning L_inf fits from some
scipy routines I am also going to commit "real soon now". I got sidetracked
;) Speaking of which, where do you think the generalized remez algorithm
should go? It has more uses than filter design for signal processing and
might should go into optimize. Although if there was a "fitting" directory I
would put it there.
> Otherwise, even if they are included in numpy, they should not be
> loaded automatically - fft is loaded automatically for compatibility
> with numarray/numeric IIRC.
>
>
Yeah, that's what I figured. I also wanted to avoid conflicts with the
current polynomial stuff.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091025/f9a7b3f6/attachment.html
More information about the Scipy-dev
mailing list