>>>>> Abby Spurdle >>>>> on Fri, 1 May 2020 17:21:32 +1200 writes:> I agree, the documentation gives the impression that stats::spline > would allow "monoH.FC". You are right, this is a lapsus, thank you for reporting it! > My guess is that stats::spline doesn't allow it because the function > is designed to return a list with x and y components. This doesn't > suit monotonic cubic Hermite splines because the function would also > need to return the slopes. Furthermore, additional functions may (or > may not) be required depending on what you want to do with x, y and > slope vectors. Well, not quite. AFAIR, the reasons I did not add the option for spline() were mostly - using splinefun() is uniformly more flexible than using spline() {you can always get an (x,y) coordinate list from splinefun()'s result later} - splinefun() is using's R feature of "(non-trivial) closure", i.e, it returns a *function* containing its own state - convenience (less work, notably less maintenance burden) Still, in spite of the above: If somebody provides minimal patches (keeping *elegant* code) to allow spline() to also allow method="monoH.FC", I'd consider applying that. For now, I'd rather amend the documentation (as Samuel proposes) > Note that my package kubik, provides a range of functions for working > with cubic Hermite splines. That's interesting. For years, I had wanted to add a bit more functionality to R's builtin (but not widely known !!) package 'splines', and just today a colleague asked me about spline interpolation with general 2nd derivative boundary conditions s''(x_1) = s2_1, s''(x_n) = s2_2 generalizing the usual ( "natural" ) boundary conditions s''(x_1) = 0, s''(x_n) = 0 and I'd "hope" it should really only need a few lines of R code to generalize from natural interpolating splines to such very slightly more general ones. (I don't see very quickly how to do this with 'kubik' either, but I've only looked for 5 minutes). --- Note that our CRAN package 'cobs' is really for (robust, namely quantile) regression splines where the user can also ask for monotonicity, convexity, concavity of s() and for bound constraints in different regions (and the implementation is fast for larger 'n', thanks to using sparse matrices)... which seems partly a generalization of 'kubik' as it's not only (just) for interpolation and still allows many shape and bound constraints.> citation("cobs")To cite the cobs package in publications use: Pin T. Ng and Martin Maechler (2020). COBS -- Constrained B-splines (Sparse matrix based). R package version 1.3-4. URL https://CRAN.R-project.org/package=cobs Ng P, Maechler M (2007). ?A Fast and Efficient Implementation of Qualitatively Constrained Quantile Smoothing Splines.? _Statistical Modelling_, *7*(4), 315-328. <URL:http://smj.sagepub.com/content/7/4/315.abstract>.
> and just today a colleague asked me about spline interpolation > with general 2nd derivative boundary conditions > s''(x_1) = s2_1, s''(x_n) = s2_2It should possible via cubic Hermite splines. A nontrivial design decision in my package was the computation of slopes at the endpoints. (Something which I got wrong, twice...) My guess is that I could write a function in about 60 to 90 minutes, including all the testing and calculus. However, I need to note two things: (1) Cubic Hermite splines do not have a continuous second derivative. (2) Specifying the second derivatives (at the endpoints) would prevent the user from specifying the first derivatives (aka the slopes). Could you please confirm if the function would still be of interest...? And completely diverging...> it returns a *function* containing its own stateI use function objects extensively. However, I haven't been able to find a definitive guide to terminology. The word "closure" appears to have a lisp origin, but it usage in R is a bit grey. Many of my functions have attributes. However, I recognize that the use the function environments is more popular, and has the advantage that the user can take advantage of lexical scoping, but has the disadvantage that copying function objects can have unexpected results. Recently, I've been using the terms "Self-Referencing Function Objects" and "Functions Bundled with Data", but was wondering if these terms are sub-optimal...?
Abby: Here is an article on environments/closures which might be useful to you. I was reviewing environments recently and it was a clear explanation of how environments/closures work in R. Even though it's from 2000, I'm pretty certain that everything said in it still holds. On Sun, May 3, 2020 at 12:16 AM Abby Spurdle <spurdle.a at gmail.com> wrote:> > and just today a colleague asked me about spline interpolation > > with general 2nd derivative boundary conditions > > s''(x_1) = s2_1, s''(x_n) = s2_2 > > It should possible via cubic Hermite splines. > A nontrivial design decision in my package was the computation of > slopes at the endpoints. > (Something which I got wrong, twice...) > > My guess is that I could write a function in about 60 to 90 minutes, > including all the testing and calculus. > > However, I need to note two things: > (1) Cubic Hermite splines do not have a continuous second derivative. > (2) Specifying the second derivatives (at the endpoints) would prevent > the user from specifying the first derivatives (aka the slopes). > > Could you please confirm if the function would still be of interest...? > > And completely diverging... > > it returns a *function* containing its own state > > I use function objects extensively. > However, I haven't been able to find a definitive guide to terminology. > The word "closure" appears to have a lisp origin, but it usage in R is > a bit grey. > > Many of my functions have attributes. > However, I recognize that the use the function environments is more > popular, and has the advantage that the user can take advantage of > lexical scoping, but has the disadvantage that copying function > objects can have unexpected results. > > Recently, I've been using the terms "Self-Referencing Function > Objects" and "Functions Bundled with Data", but was wondering if these > terms are sub-optimal...? > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >-------------- next part -------------- A non-text attachment was scrubbed... Name: ih_gent_lexical.pdf Type: application/pdf Size: 220482 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20200503/fe569c8d/attachment.pdf>
I just realized that note (2) is not completely correct. It would be possible to specify both the first and second derivatives at the endpoints. However, that would require subdivision of the outermost spline segments, which increases the complexity of the algorithm.
>>>>> Abby Spurdle >>>>> on Sun, 3 May 2020 16:15:17 +1200 writes:>> and just today a colleague asked me about spline interpolation >> with general 2nd derivative boundary conditions >> s''(x_1) = s2_1, s''(x_n) = s2_2 actually I was wrong... I *read* it as the above, but what he really wanted was what the wikipedia page class "clamped" boundary conditions, i.e., for the *first* derivative s'(x_1) = s1_1, s'(x_n) = s1_2 > It should possible via cubic Hermite splines. and indeed that is available via cubic Hermite splines available in R via stats package's splinefunH() {which I wrote when implementing "monoH.FC"} > A nontrivial design decision in my package was the computation of > slopes at the endpoints. > (Something which I got wrong, twice...) The "wikiversity" has a very nice small math lecture on this https://en.wikiversity.org/wiki/Cubic_Spline_Interpolation which derives *both* cases (first and 2nd derivative boundary conditions), the only draw back to quickly do it with ('base R') is that I need to "translate" that (2nd derivative values $M_i$) parametrization into either the one used into the (a,b,c,y)-parametrizat of the default spline() / splinefun() methods or the Hilbert spline form for splinefunH(x[],y[],m[]). Martin > My guess is that I could write a function in about 60 to 90 minutes, > including all the testing and calculus. > However, I need to note two things: > (1) Cubic Hermite splines do not have a continuous second derivative. well, many don't if you allow any slopes at node. However, if you only set 2 boundary conditions *instead* of the natural spline ones f''(x_1) = f''(x_1) = 0, you can still remain in C_2 (i.e. continuous 2nd derivative). (And that's also what the above wikiversity lecture provides). > (2) Specifying the second derivatives (at the endpoints) would prevent > the user from specifying the first derivatives (aka the slopes). > Could you please confirm if the function would still be of interest...? Well, as I know spent enough time reading and thinking, I'd really like to add method = "clamped" to splinefun() and also the other one where fix the 2nd derivatives (to arbitrary values instead of zero). So if you already have the R code leading up to one of the 2 "parametrizations" we use in spline() / splinefun(), I'd be grateful, if you have the time. Martin