Hacker News Reader

Comment by mochomocha | Hacker News Reader

Fun fact: if you don't care about the auto-regressive aspect of NeuralProphet (it's turned off by default), you can implement the core of NeuralProphet/Prophet (piecewise linear trend + Fourier on weekly/daily seasonality) in about 60 LOCs with no other dependency than either torch or numpy+scipy.optimize, and without having to deal with Stan or the very poorly chosen heuristics of neuralprophet.

Another thing that both NeuralProphet and Prophet do extremely wrong by default is uncertainty estimation. The coverage probabilities are way off.

View on HN

Do you have an example implementation of reimplementing the core of these?

It's literally what I did at work last week, which is why I found this submission timely. I'd have to check with my employer if it can be made public. I don't see any reason why not, there's not much to it.

What did you use to implement the regularization of the trend breakpoints? Prophet by default uses a regular grid and thins them out with STAN. I couldn't find a quick regularization replacement in numpy/scipy/statsmodels with equivalent performance. (I don't want to drag in another huge dependency with Torch or TF).

Why is STAN viewed negatively in this light? I am curious why bayesian libraries are the black sheep.

I am curious too. I have used Stan extensively. I found it extremely polished and pleasant to use.

It generated very efficient samplers for particularly weird (and enormous!) hierarchical models I had. Documentation is also great.

It is also worth reading Andrew Gelman's post about Prophet: https://statmodeling.stat.columbia.edu/2017/03/01/facebooks-...

I think he just means that it can be an incredible pain to install.

Not directly from machine learning perspective, rather touching stability of use in production setup. We at VictoriaMetrics allow Prophet to be one of the models to use for time series anomaly detection in vmanomaly product. When it comes to cloud environment, Prophet, which uses `cmdstanpy` under the hood, allows little to no control over the backend, thus, resulting in unexpected crashes for read-only filesystems like Red Hat OpenShift, after the backend attempts to create assets in /tmp directory during model fit stage, so such dependencies may limit usage of a product in real-world scenarios.

This is interesting to me. Do you use a library to estimate the fourier series of a data series or have you implemented it from scratch? I've searched for this in the past but always got results RE. Fourier transforms, not series.

Reply on news.ycombinator.com