1,578 karma · joined November 22, 2009
https://imurray.bsky.social/
https://mastodon.social/@imurray / @imurray@mastodon.social
https://twitter.com/driainmurray
Research interests include statistics and machine learning.
The webpage https://web.stanford.edu/~jurafsky/slp3/ links directly to the PDF, and gives context and other download options. It's not so easy to go back from the PDF to the webpage.
Mods: I'd change the link, and the title to "...3rd Edition draft".
Everyone else: please stop linking to PDFs when there is an obvious html page to link to instead.
/ -pIt's one click to get the pdf from there. But you also get a plain webpage with abstract, citation details, and so on, which you can't get back to from the PDF.
In general it's good to knock the ".pdf" off the end of all papers.nips.cc links. Similarly turn /pdf/ links on arXiv into /abs/ links, and replace "pdf?" in openreview.net links with "forum?".
Gah; that explains it. Occasionally I get a reply saying "you just sent me a blank email", while the text of my email is quoted right there in the email they've just sent me!
He has a book with supporting material here: http://www.3dprintmath.com/
You are right that a bad approximation of the surface could lead to proposals that get rejected a lot. But at least the dynamics are likely to be stable. It could be worth trying.
You can run HMC on any differentiable surrogate surface surface. It's only the accept/reject step that has to use your real model and data. You might consider that if you have a less hairy approximation to your model.
Emcee is popular in astronomy, partly because of network effects, partly because it's a really nice package, and partly because the method's a great fit for some of the posteriors you have: often unimodal-ish even if the likelihood is nasty to compute, and often in not that many dimensions. It would fall flat on its face for something like a Bayesian neural network.
Dual numbers are just the wrong approach for neural nets, which have many parameters. The amazing thing about backprop / reverse-mode differentiation is that you get the derivatives wrt all the weights in one reverse sweep through the network.
The cost of Dual numbers (a form of forward-mode differentiation) scales linearly with the number of derivatives (just like finite differencing, but more accurate). Backpropagation, or reverse-mode differentiation, is a constant factor times the cost of a function evaluation. For neural nets with millions of parameters, backpropagation is going to be millions of times faster than dual numbers.
For matrix-based code, a good note on derivative propagation is https://people.maths.ox.ac.uk/gilesm/files/NA-08-01.pdf — the symbols with dots on top are forward-propagated derivatives like dual numbers. The symbols with bars on top are back-propagated derivatives, which is what you want to compute lots of derivatives at once. "Machine learning" libraries like Theano, TensorFlow, and Autograd will compute the reverse mode operation for many linear algebra expressions automatically, and use reasonable libraries like BLAS+LAPACK or Eigen under the hood.
OpenNMT can also run amok given totally unreasonable input too (example below). I'm being unfair, but the more serious point is that translation systems might go crazy in less obvious ways. While fluency is greatly improved, they certainly don't always get the meaning correct. I'm excited to see what people will do to better diagnose when we can trust the translation.
Input: "Toll ach toll toll ach toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll toll Deutsch."
Output: "Tell me great great, great great, great great great great great great great great great love great ? ? ? great love ? ? ? ? ? ? ? great ? ? ? ? great love ? ? ? great great ? ? ? great great ? ? ? great great ? ? ? great great ? ? great great ? ? ? great great ? ? great great ? ? great love ? ? Good ? ? ? great love ? ? great love ? ? Good love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? great love ? ? Good ?"
[Each ? was a musical note glyph, but HN ate the unicode character.]
A twitter conversation reflecting some scepticism, but agreeing it would be interesting if it all checks out: https://twitter.com/fchollet/status/771862837819867136
I think it's a lucky engineer that has their end-goal defined as such a crisp mathematical task. Defining what is an optimal way to do a fit, for the surrounding application, usually requires thought. Often the reasonableness of the curve does matter, for example if it will be evaluated in locations other than the training data. Also, there may be some choice in how to set up the problem. For example, maybe we're allowed to transform the inputs with some fixed non-linear functions to create extra features. Adding these extra features to the design matrix will improve fit, so an engineer might consider it, but they'll need to be careful about over-fitting if they care about a surrounding application.
Regression is a statistical term. If it's going to be used for an application involving data and real decisions, not understanding the statistical issues is irresponsible. That's not at odds with viewing it as a procedure to minimize square errors.
To clarify: There are probabilistic models (involving Gaussians and stuff) where some interpretations suggest least-squares estimation. That wasn't the distinction I was trying to make. Statisticians who hate probabilistic models will still say that it's important to think about what you put in X and y before you do X\y, and to be careful about what you can conclude from the result.
w_fit = X \ yy; % Matlab/Octave, X is NxD, yy is Nx1
w_fit = np.linalg.lstsq(X, yy)[0] # NumPy equivalent
Knowing how to construct the "design matrix" X is the important bit. What are your features, how will they be pre-processed, and given what you've done, should you trust w_fit to be meaningful, or just useful for prediction?If you've thrown in lots of features, hoping to get good predictions, you may want to do "regularization". The computation is no harder for simple versions. One way to do "L2 regularization" is to add some extra rows to X and yy before fitting the weights:
% Matlab/Octave... the NumPy is nearly as simple.
[N, D] = size(X);
lambda = 1; % regularization constant
X = [X; eye(D)*sqrt(lambda)];
y = [yy; zeros(D,1)]
Or you could use an actual stats package like R's libraries that will contain a lot more care. Again, you need to understand the statistics, for example how you should select lambda. Then you'll want to know how to diagnose your model and whether you should trust it.It's fun to work out the least squares maths and implement these things from scratch. But it has been done, and it's not what matters for most applications.
EDIT: a discussion with good links on linear models and beyond from the other day https://news.ycombinator.com/item?id=12237998
Thinning is a good idea if the samples are strongly correlated, and the computation to process them all would be better spent on running the chain for longer. Or if you don't know what computation you want in advance, and you can't afford to store everything.
(Also, as someone points out in the comments, the implementation of the Metropolis algorithm in this post is wrong.)
That said, there are also whole papers, even collected volumes, on initialization and other practical details.
Textbooks aren't always up-to-date with the latest practical knowledge, as deep-learning practice is moving quickly. Or they simply don't want to clutter their high-level maths descriptions with code-level implementation details. Teaching stuff is all about tradeoffs. I'm sure several books do mention the scale of weights for simple feed-forward weights though, as it's not an implementation-level detail, and it's probably been well known since the 1980s.
It's also worth checking out existing neural net code-bases to see what tricks they have. The fine details usually aren't in papers, and they're not all in the text-books either.
The first potential problem that jumped out at me in this code was the initialization:
self.weights = [np.array([0])] + [np.random.randn(y, x)
for y, x in zip(sizes[1:], sizes[:-1])]
If the number of units in a layer is H, the typical size of the input into the layer above will be √(H). For large H, the sigmoid will usually saturate, and the gradients will underflow to zero, making it impossible to learn anything. There are some tricks to avoid the numerical problems, but even if you avoid numerical-underflow, things probably aren't going to work well.I'd multiply those initial weights by a small constant divided by the square-root of weights going into the same neuron. For multiple layers you might consider layer-by-layer pre-training. For other architectures, like recurrent nets, definitely find a reference on how to do the initialization.
PS I would definitely add a test routine to check that the gradients from back-propagation agree with a finite difference approximation. It's so easy to get gradient code wrong, and it's so easy to test.
No it wasn't literally painful. But frustrating. Nearly as frustrating as people not accepting that people legitimately use software in different ways.
I found this fix, which made quick uses of GIMP less painful for me: http://shallowsky.com/software/gimp-save/
I'm assuming the new save behavior persists in Gimp 2.9.x, but I don't know.
That statement applies equally to Matlab/Octave. You can link C/C++/Fortran routines into Matlab code using its "mex" interface. Octave also supports this interface.
Python is more flexible, but less simple to start out with because it has a more complicated ecosystem. For example, there are many different ways to link in fast code (ctypes/cffi/cython/numba/weave/f2py/...). Moreover, the data in a numpy array can be stored in memory in different ways (C or Fortran order, not necessarily contiguous, ...), which requires some care when passing it to external routines.
I deliberately don't use Autograders for my assignments though. I want students to be able to figure out for themselves whether to be satisfied with an answer, and work out how to test it. And I suspect many employers want the same. If a student asks me "is that right", I try to remember not to tell them, but to ask questions that will help them figure it out for themselves. Similarly, providing a test-rig that answers whether a piece of code is right is sometimes inappropriate.