Closed tdhock closed 2 years ago
TLDR; Whilst a couple of years ago I was ready to remove it, I don't think it is going to be anymore.
The plan was to disappear it but I'm open to changing my mind on that. One of the reasons for it disappearing is because the others are in C and I didn't want to port SegNeigh to C. BUT a new PhD student of mine is using SegNeigh as a basis for something new so it will likely stick around longer (and move to C). I've put in a grant to create a Python version of some of these things so if I get it, I'll need SegNeigh in C for that too. Some people prefer SegNeigh because they can specify the number of changepoints directly.
Is SNIP not already available?
thanks, that would be great if you could keep a reference implementation of SegNeigh! I agree that "Some people prefer SegNeigh because they can specify the number of changepoints directly."
The R implementation which was used to create the SNIP comparison figure in the paper is here, https://r-forge.r-project.org/scm/viewvc.php/benchmark/Fig1-5/SNIP%20-%20noCP.R?view=markup&revision=50&root=opfp but I don't think there was ever a C implementation, was there @robertmaidstone ?
hi @rkillick am I correct that changepoint package will no longer support SegNeigh method? If that is the case, can we copy the old SegNeigh code to a new/different R package? (maybe as a GSOC project for next summer, which could also implement SNIP algorithm from Maidstone paper?) I realize that it is slow but for small data and number of segments it is fast enough, and useful for teaching and comparison purposes. I would like to continue using SegNeigh for teaching, because it is much easier to explain/understand than the penalized methods (PELT etc).