Comment by gtrubetskoy | Hacker News Reader

Comment by gtrubetskoy | Hacker News Reader

Applied science, i.e. taking something from text book abstract and general to something specific is always extremely difficult. It's one thing to read about a nuclear reaction but a whole different thing to actually set one off.

To implement something you need to have a level of understanding of it that is way deeper than what is required to get a passing grade in your math class. The problem isn't mathematical notation or the programming language (I am quite competent in and have no quarrel with either).

I recently set out to implement Triple Exponential Smoothing (aka Holt-Winters method), but I didn't want to use someone else's code, I wanted to understand the algorithm so that I knew enough to compare various implementations and/or write my own. It took _months_. There is a lot of material on the subject, but it all disagrees ever so slightly on one thing or another, or skips over something essential. I don't think anyone or anything is to blame for this - that's just life.

You can read about it here, btw: http://grisha.org/blog/2016/01/29/triple-exponential-smoothi...

> There is a lot of material on the subject, but it all disagrees ever so slightly on one thing or another, or skips over something essential. I don't think anyone or anything is to blame for this - that's just life.

Isn't this precisely what you said wasn't the problem? The resources out there all differ slightly on one thing or another. I suppose you mean small semantic differences? I think when I wrote this article originally I intended superficial semantic differences in the math to count as well as notational differences. Doing math for too long has made me think of these as the same thing, since the true underlying insight doesn't depend on either.

Yes, every text used its own conventions for variable names, different words to say the same thing, etc, but no, that wasn't a problem (for me at least).

I think the point I was trying to make (not so well) is that perhaps it's not that programmers do not like math, but rather that when you learn to view everything through a programmer's eyes, i.e. "how am I going to actually build this damn thing", you tend to get very wary of abstract or generic approaches which is what scientific books are made of.

For example, if I were given a book with a chapter on Holt-Winters and told that there'd be a quiz later, I could have "mastered" it in a night probably. But when I had to write the code to actually do that, I'd find out that this book does not mention how you come up with initial values, while wikipedia does, wikipedia cites this NIST publication, but who wrote that and is it any good? Then I came across a 2014 paper that says that the forecast can be improved with a slight change in one of the formulas, only when I tried it, my results were worse; no book mentioned how to find best alpha, beta and gamma, because for that you need some kind of a gradient descent or nelder-mead method, and on and on. _That's_ what took months (and it was challenging and fun too), and I think we agree that there isn't a solution to this, it's a dilemma, not a problem. (As someone once said - avoid trying to solve dilemmas and avoid managing problems).

I think that's much the same situation as with programming.

If I were given the postgres docs, I could "master" the syntax pretty quickly. But when I had to write code that actually uses postgres in production, I realized that the docs don't carefully explain 3NF, making 3NF fast and user comprehensible, good practices on writing complex queries, etc.

Is that really a math-specific problem?

Interesting read. Thank you for sharing.

Reply on news.ycombinator.com