Symbolic representations, distance measures, and sliding windows.

[stefan-pdx]

Hi all,

I'd be interested in making contributions towards adding symbolic aggregate approximation representations (along with the other corresponding flavors), a collection of distance measures to calculate similarity between TimeSeries objects, and sliding window functionality to Nitime. I also have a couple of visualizations tools that I'd like to contribute as well.

To get the ball rolling, I threw in a sax method in the TimeSeries object to output the string representation of the TimeSeries object: stefan-pdx/nitime@be33b5c. Is there a preference where you want representational methods to be implemented? I'd prefer to have it as part of the TimeSeries object, since that would make it a bit more compatible with some of the work that I'll be doing with sliding window code, however if it would be more suitable for the utils.py file, that's fine.

Also, for implementing a variety of distance measures between TimeSeries objects, where would you recommend is the best place to place it?

Thanks!

[arokem]

Hi Stefan,

Thanks so much for your contribution. This is very interesting. I have to admit that this is the first time I have heard of sax, so I will have to read the paper you refer to in order to understand a little bit more what this actually does. The examples you wrote are helpful in this regard, but an additional way you could help me with to wrap my head around this is to flesh out use-cases for this representation in the form of tests. You can write those in this file: https://github.com/slnovak/nitime/blob/master/nitime/tests/test_timeseries.py

Once I understand a little bit better what these are, I can comment more on 'where to put this'. If you think about the sax as a transform of the data, analogous to a spectral transform, maybe a better place to put this would be in the algorithms library. I should warn you that I am currently working on a refactor of the code, which will result in a breaking up the algorithms file into several different sub-modules (see the work here: https://github.com/arokem/nitime/tree/reorganization) and better test coverage (we are close to 100% coverage for the algorithms sub-module!). We plan to continue this work, by breaking up utils.py, analysis.py, timeseries.py and viz.py into sub-modules in a similar fashion. This should eventually make it easier to contribute, but for now makes for some divergence between branches. In other words, if you want to add things to the algorithms sub-module, maybe you should branch off of the reorganization branch and we would merge your additions into that one. If that's a hassle, then don't worry about it. We can figure out a way to merge all this together eventually. Which brings me to the distance metrics - are you planning to implement the distance metrics mentioned in the Lin et al. paper? I think that it would be the best to put those in the algorithms sub-module. Maybe add a new file called 'distance' into the algorithms sub-module, in a branch off of the reorganization branch and the tests for these distance metrics under algorithms/tests/test_distance.py, or something of the sort. How does that sound?

Again - thanks a lot for your work on this!

Cheers,

Ariel