I use the splines in scipy.interpolate quite a bit, and I particularly
like the *UnivariateSpline and *BivariateSpline wrapper classes. However, I cannot for the life of me work out what gives with the names and documentation... As far as I can tell, the univariate splines are as follows: UnivariateSpline : A spline where the number of knots is chosen using the "smoothing factor" s LSQUnivariateSpline: A spline where the knots are explicitly specified InterpolatedUnivariateSpline: A spline with s=0 or t=[] (e.g. passes through all the fitting points) The documentation just says the second two "just have less error checking"... aren't they for very different purposes? And while I recognize that name changes at this stage might be uncalled for, the names are somewhat misleading, too... shouldn't they be "SmoothUnivariateSpline","KnotUnivariateSpline", and "InterpolatedUnivariateSpline" or something like that? It also seems there are similar versions for the *BivariateSpline classes, although it's unclear to me exactly what the raw BivariateSpline class does as compared to the SmoothBivariateSpline (and the RectBivariateSpline, at least, makes sense) _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Wed, May 20, 2009 at 9:54 PM, Erik Tollerud <[hidden email]> wrote:
> I use the splines in scipy.interpolate quite a bit, and I particularly > like the *UnivariateSpline and *BivariateSpline wrapper classes. > However, I cannot for the life of me work out what gives with the > names and documentation... As far as I can tell, the univariate > splines are as follows: > > UnivariateSpline : A spline where the number of knots is chosen using > the "smoothing factor" s > LSQUnivariateSpline: A spline where the knots are explicitly specified At least the docs need a lot of improvement, I tried out the splines for the first time a short time ago, and I only realized this for LSQUnivariateSpline after receiving exceptions when I wanted to update the knots as described in the docs. Also, the dispatch behaviour of UnivariateSpline is not described. The docs for the original wrappers, splrep, splev, sproot, spalde, splint, is more informative. I was looking at these spline classes as a replacement for the spline implementation in stats.models, but for a newbie to splines the documentation is not very helpful. But the splines produce nice pictures. Josef > InterpolatedUnivariateSpline: A spline with s=0 or t=[] (e.g. passes > through all the fitting points) > > The documentation just says the second two "just have less error > checking"... aren't they for very different purposes? And while I > recognize that name changes at this stage might be uncalled for, the > names are somewhat misleading, too... shouldn't they be > "SmoothUnivariateSpline","KnotUnivariateSpline", and > "InterpolatedUnivariateSpline" or something like that? > > It also seems there are similar versions for the *BivariateSpline > classes, although it's unclear to me exactly what the raw > BivariateSpline class does as compared to the SmoothBivariateSpline > (and the RectBivariateSpline, at least, makes sense) > _______________________________________________ > SciPy-user mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
So who has the power to update these docs, anyway? It doesn't seem
that complicated to make the necessary clarifications... On Wed, May 20, 2009 at 7:38 PM, <[hidden email]> wrote: > On Wed, May 20, 2009 at 9:54 PM, Erik Tollerud <[hidden email]> wrote: >> I use the splines in scipy.interpolate quite a bit, and I particularly >> like the *UnivariateSpline and *BivariateSpline wrapper classes. >> However, I cannot for the life of me work out what gives with the >> names and documentation... As far as I can tell, the univariate >> splines are as follows: >> >> UnivariateSpline : A spline where the number of knots is chosen using >> the "smoothing factor" s >> LSQUnivariateSpline: A spline where the knots are explicitly specified > > At least the docs need a lot of improvement, I tried out the splines > for the first time a short time ago, and I only realized this for > LSQUnivariateSpline after receiving exceptions when I wanted to update > the knots as described in the docs. Also, the dispatch behaviour of > UnivariateSpline is not described. > The docs for the original wrappers, splrep, splev, sproot, spalde, > splint, is more informative. > > I was looking at these spline classes as a replacement for the spline > implementation in stats.models, but for a newbie to splines the > documentation is not very helpful. > > But the splines produce nice pictures. > > Josef > > >> InterpolatedUnivariateSpline: A spline with s=0 or t=[] (e.g. passes >> through all the fitting points) >> >> The documentation just says the second two "just have less error >> checking"... aren't they for very different purposes? And while I >> recognize that name changes at this stage might be uncalled for, the >> names are somewhat misleading, too... shouldn't they be >> "SmoothUnivariateSpline","KnotUnivariateSpline", and >> "InterpolatedUnivariateSpline" or something like that? >> >> It also seems there are similar versions for the *BivariateSpline >> classes, although it's unclear to me exactly what the raw >> BivariateSpline class does as compared to the SmoothBivariateSpline >> (and the RectBivariateSpline, at least, makes sense) >> _______________________________________________ >> SciPy-user mailing list >> [hidden email] >> http://mail.scipy.org/mailman/listinfo/scipy-user >> > _______________________________________________ > SciPy-user mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 [hidden email] http://ps.uci.edu/~etolleru _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, May 22, 2009 at 5:57 PM, Erik Tollerud <[hidden email]> wrote:
> So who has the power to update these docs, anyway? It doesn't seem > that complicated to make the necessary clarifications... > Anyone can. You just need to register a name for the docs wiki and ping the ML to request editing rights. See here: <http://docs.scipy.org/numpy/Front%20Page/> My current understanding is that once changes are made in the documentation editor, then they are applied to the SVN source from time to time. Is this accurate? Skipper _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Fri, 22 May 2009 18:05:16 -0400, Skipper Seabold wrote:
[clip] > My current understanding is that once changes are made in the > documentation editor, then they are applied to the SVN source from time > to time. Is this accurate? Yes, they are applied manually, from time to time. Possibly not very frequently, but at least before releases. If you want to have some change applied ASAP, you can send mail to the scipy-dev and ask someone (= probably me) to commit the docs. -- Pauli Virtanen _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
What about changing the class names? Is this an unlikely proposition
for backwards compatibility? I've been using some of these classes enough that I will probably attempt to add some functionality and post a patch on scipy-dev some time in the next few weeks, and if so I will probably include updated docs, if so. On Fri, May 22, 2009 at 3:10 PM, Pauli Virtanen <[hidden email]> wrote: > Fri, 22 May 2009 18:05:16 -0400, Skipper Seabold wrote: > [clip] >> My current understanding is that once changes are made in the >> documentation editor, then they are applied to the SVN source from time >> to time. Is this accurate? > > Yes, they are applied manually, from time to time. Possibly not very > frequently, but at least before releases. > > If you want to have some change applied ASAP, you can send mail to the > scipy-dev and ask someone (= probably me) to commit the docs. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-user mailing list > [hidden email] > http://mail.scipy.org/mailman/listinfo/scipy-user > -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 [hidden email] http://ps.uci.edu/~etolleru _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, May 22, 2009 at 6:16 PM, Erik Tollerud <[hidden email]> wrote:
> What about changing the class names? Is this an unlikely proposition > for backwards compatibility? > > I've been using some of these classes enough that I will probably > attempt to add some functionality and post a patch on scipy-dev some > time in the next few weeks, and if so I will probably include updated > docs, if so. > > On Fri, May 22, 2009 at 3:10 PM, Pauli Virtanen <[hidden email]> wrote: >> Fri, 22 May 2009 18:05:16 -0400, Skipper Seabold wrote: >> [clip] >>> My current understanding is that once changes are made in the >>> documentation editor, then they are applied to the SVN source from time >>> to time. Is this accurate? >> >> Yes, they are applied manually, from time to time. Possibly not very >> frequently, but at least before releases. >> >> If you want to have some change applied ASAP, you can send mail to the >> scipy-dev and ask someone (= probably me) to commit the docs. >> There is also still the open question how we get the information of the docstrings in class.__init__ into the sphinx docs. Josef _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Fri, 22 May 2009 19:22:14 -0400, josef.pktd wrote:
[clip] > There is also still the open question how we get the information of the > docstrings in class.__init__ into the sphinx docs. The Numpy docstring standard dictated that the __init__ method should be documented in the main class docstring. I don't personally like this very much. Maybe we need to revise this? Anyway, the Sphinx dev version contains an improved version of autosummary that has features that could be used to address this. *** So I'd suggest currently just making a separate hand-written page for the interpolation class docs, making appropriate use of the autoclass:: and automethod:: directives. The main documentation page interpolate.rst could then contain the corresponding autosummary directives without the :toctree: argument. -- Pauli Virtanen _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
On Fri, May 22, 2009 at 8:24 PM, Pauli Virtanen <[hidden email]> wrote:
> Fri, 22 May 2009 19:22:14 -0400, josef.pktd wrote: > [clip] >> There is also still the open question how we get the information of the >> docstrings in class.__init__ into the sphinx docs. > > The Numpy docstring standard dictated that the __init__ method should be > documented in the main class docstring. > > I don't personally like this very much. Maybe we need to revise this? > > Anyway, the Sphinx dev version contains an improved version of > autosummary that has features that could be used to address this. > > *** > > So I'd suggest currently just making a separate hand-written page for the > interpolation class docs, making appropriate use of the autoclass:: and > automethod:: directives. > > The main documentation page interpolate.rst could then contain the > corresponding autosummary directives without the :toctree: argument. > > -- > Pauli Virtanen Pauli, do you have an example how to do this? when I tried autoclass and automethod in the doc editor then it didn't produce the intended results. For example for the KroghInterpolator: Given last years discussion a lot of information was put into the __init__ What I would find very helpful would be if the link for KroghInterpolator in http://docs.scipy.org/scipy/docs/scipy-docs/interpolate.rst/ leads to the full autodocs of the class, with all or selected automethods. I would prefer one page per class for the class based modules such as the interpolator classes. I find the docs very well structured and accessible for functions but in many cases it doesn't provide a good structure for classes. If you have an example for how this can be done, then I could fix parts of the docs. The numpy docstring doesn't really define the structure for the sphinx documentation, or does it. I still appreciate the htmhelp files for windows a lot. It's very useful to have instantaneous search and access to the docs. That's why it's bugging me when the information is not in the docs, even though it can be accessed with >>> help(classname). But currently the docs don't produce the same result. Josef _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
In reply to this post by Pauli Virtanen-3
2009/5/23 Pauli Virtanen <[hidden email]>:
> The Numpy docstring standard dictated that the __init__ method should be > documented in the main class docstring. > > I don't personally like this very much. Maybe we need to revise this? The rationale behind this was that you never call __init__ explicitly, but always construct an instance using MyClass(parameters). On the other hand, both "IPython" and "help" now show docstrings for both the class and __init__ (I can't recall whether this was always the case), so it probably won't matter much if we move it over. Regards Stéfan _______________________________________________ SciPy-user mailing list [hidden email] http://mail.scipy.org/mailman/listinfo/scipy-user |
Free forum by Nabble | Edit this page |