5 ms·
Is there a python implementation of it as well?
by aashu_dwivedi 9y ago
Is there a python implementation of it as well?
- SEJeff 9y agohttps://github.com/stanford-futuredata/ASAP/blob/master/ASAP.py https://github.com/stanford-futuredata/ASAP/blob/master/ASAP...
- aashu_dwivedi 9y agoJust tried it. I was using the seasonal_decompose from statsmodel in python for a project. I have to say ASAP looks great!
- SEJeff 9y agoIt really is a gem for analysis of time series data. I was lucky enough to watch Kexin's talk live @ Monitorama on ASAP. Really great stuff.
- jnordwick 9y agoDoes he explain how this is better than any other methods?
- SEJeff 9y agoI don't believe she did. She investigated the specific problem of helping users to identify deviations in time series by applying smoothing. Here is a link to her presentation: https://vimeo.com/221062931 https://vimeo.com/221062931 It is pretty fascinating, I do recommend giving it a watch.
- krong 9y agoThanks!
- srean 9y agoI upvoted the authors comment linking the Arxiv paper, that said, I think the presentation oversold the claim that smoothing is always a good thing to do. In particular, showing that excel, grafana, graphite etc, do not smooth by default, (apparently because it is a hard) looked like a low point of the talk, sorry. Smoothing has its uses but its hardly the panacea. What is an appropriate smoothing is very context sensitive and I would like the consumer of the plots be in charge of that. Sometimes smoothing away the high frequencies or transients are exactly the wrong thing to do (for example, when you care about transient spikes) I have seen more than enough damage done by plotting tools sneaking in a smoothing without informing the consumer. Especially so in the monitoring space. When the user expects raw plots it better be raw, and raw is a good default. Smoothening should be invoked explicitly.
- krong 9y agoThanks for the comment. I strongly agree that smoothing is not always beneficial and that the users should be informed and have control of the amount of the smoothing that is being applied to their plots. We developed ASAP with the intend to complement, instead of replacing the raw plots. We view ASAP more as a "smart default" - if you were to expose a slide bar of different moving average window sizes that users could apply to their visualizations, where should a reasonable default be on that slide bar? In addition, ASAP does not always choose to smooth the visualizations. In some cases (e.g. Figure C.1 in the arXiv paper) where the raw plots already have a few well-defined outlying regions and smoothing would only decrease the extent of such deviations, ASAP leaves the visualization unsmoothed.
- srean 9y agoThat sounds very sensible.
- jnordwick 9y agoThanks! Update: Hi Jeff!
- SEJeff 9y agoSmall world buddy! Shoot me an email (from the github link on my profile)
- krong 9y agoHi, thanks for the interest. I am one the of the authors of the paper. To clarify, the main goal of ASAP is to automatically select a reasonable smoothing parameter for time-series. Moving average is already widely used for time-series visualization and dashboards, but setting the width of the window is a usually manual process. If you're interested, our extended version of the paper (https://arxiv.org/pdf/1703.00983.pdf https://arxiv.org/pdf/1703.00983.pdf) contains some empirical comparisons of the moving average function with other smoothing functions like FFT and the Savitzky–Golay filter.
- jnordwick 9y agoThe examples series given have seasonal/periodic effects. An MA seems like the wrong tool and the data should be deseasoned first. The MA in these cases isn't removing noise it would seem.