News for hackers. Stuff that matters.
Re:One parameter is always enough [pdf] by foob on Saturday May 26, 2018 @12:21PM (#17162827)
Their equation is cute, but this really isn't remotely surprising and the implications aren't as significant as they imply. The result relies heavily on the fact that their theta parameter has infinite precision. You can encode as much information as you want in a single real number with infinite precision. Think of it this way: a single precision float requires 4 bytes to store while a double requires 8. If all you need is single precision, then you can store two floats inside of one double variable with each occupying 4 of the 8 bytes. Now replace the double with an infinite precision number that takes infinite bytes to represent. Once you have an infinite number of bytes to work with, you can pack in as many floats of finite precision in there as you want. That's basically what they're doing here, they just have a simple closed form expression for decoding it.

The reason that the implications are a bit overblown is that their model is tremendously and chaotically dependent on the value of theta. The plots that they include in the paper require hundreds of thousands of digits of precision in the model parameter. Nobody evaluates a model based simply on how well it fits the data and its number of parameters; you also look at how well the model parameters are constrained and what the uncertainty bands on the fit are. With this model, theta would be completely unconstrained and their uncertainty bands would cover the entire range of the data that they're fitting. It simply doesn't matter how many parameters you have when that's the case, it means that your fit is useless.

Re:One parameter is always enough [pdf] by imh on Saturday May 26, 2018 @04:35PM (#17164139)
> The plots that they include in the paper require hundreds of thousands of digits of precision in the model parameter.

This is incorrect. They said "Both use r = 8 and require hundreds to thousands of digits of precision in θ." That's hundreds to thousands, not hundreds of thousands.

It's still a ton. For reference, a single precision (32 bit) float has about 6-7 decimal digits of precision, double (your typical float in most things that aren't neural nets) has 15ish, and quad has 35ish decimal digits of precision.

So it's totally impractical, yeah, but I just wanted to point out that it's not nearly as nuts as you emphasized.

Re:One parameter is always enough [pdf] by jmalicki on Saturday May 26, 2018 @06:09PM (#17164510)
"It simply doesn't matter how many parameters you have when that's the case, it means that your fit is useless." That is their entire point - that model complexity can't be measured in number of coefficients, since this model only has one coefficient, yet has model complexity as high as is possible.

This is meant as a counterexample to existing practices, not as something you should be doing.

Re:One parameter is always enough [pdf] by ajtulloch on Saturday May 26, 2018 @07:28PM (#17164734)
But since everyone (implicitly or explicitly) specifies the precision of the coefficients (eg fp32, fp64, int8, etc), it’s a complete straw man you’re arguing against.
Re:One parameter is always enough [pdf] by foob on Saturday May 26, 2018 @07:41PM (#17164770)
Nobody evaluates a model based simply on how well it fits the data and its number of parameters; you also look at how well the model parameters are constrained and what the uncertainty bands on the fit are.

The existing practice isn't to blindly look at the number of parameters in a model without considering the actual fit. It's a strawman argument to pretend that that's the case. A model that statistically overfits the data is just as suspect as one that underfits it. If you try to publish a paper about a model with a 0.01 chi-squared value being fit to some data, then it's going to be rejected. It doesn't matter if it's one parameter or one hundred parameters, it's clearly encoding information about the actual dataset rather than being a general model. The model that they present in this paper would have a chi-squared value of essentially zero, and someone would be laughed out of the room if they tried to present it at a conference.

Re:One parameter is always enough [pdf] by Eridrus on Saturday May 26, 2018 @08:55PM (#17164954)
> This is meant as a counterexample to existing practices

So, the paper mentions that their "model" has infinite VC-dimension, so you basically shouldn't expect it to generalize, so existing theory says that it's a model that won't work.

The problem is that VC-dimension (and Rademacher complexity, etc) also claim that modern neural nets are too complicated to generalize with the amount of data we have.

And yet they do. So the deep learning community has fallen back on counting parameters, not as a way to measure generalization, but as a way to compare models, based on the empirical observation that a lot of the "improvements" we see in papers disappear when you compare to equally sized models.

Re:One parameter is always enough [pdf] by ashelmire on Saturday May 26, 2018 @12:48PM (#17162967)
Spot on analysis. I assume this was intended to be a bit of a joke. Number of parameters is not really a useful metric when talking about the amount of data input to a function. What's important is how much data is encoded within the given parameters. I'm also relatively confident that there are likely a large number of functions with which you could achieve similar results (and probably without going to hundreds of thousands of digits).
Re:One parameter is always enough [pdf] by rubidium on Saturday May 26, 2018 @01:47PM (#17163302)
From the paper: "Thus, the construction shows that even a single parameter can overfit the data, and therefore it is not always preferable to use a model with fewer parameters. "

Yes the author was clearly trying to make a point.

Re:One parameter is always enough [pdf] by mlthoughts2018 on Saturday May 26, 2018 @01:54PM (#17163343)
This is just a trick of language though, because their single, hundreds-of-thousands-of-digits-of-precision “parameter” is really just a way of packing an agglomeration of other parameters into one bit bucket.

If you could take some construct and decompose it further into a bunch of independent components that separately account for the prediction behavior, then the number of parameters was really the number of components (or something close), and not “one parameter” artificially because of the way the separate parameters were packaged and decoded.

So even on this intended point, the paper’s result doesn’t really matter. In a Kolmogorov complexity sense, this “one parameter” model is more complex than many multi-parameter models that represent shorter programs, which is a way of saying this “one parameter” model is not really one parameter.

Re:One parameter is always enough [pdf] by jexah on Saturday May 26, 2018 @07:52PM (#17164798)
> "In a Kolmogorov complexity sense, this “one parameter” model is more complex than many multi-parameter models that represent shorter programs"

I'm not a mathematician, but I think the point of the exercise was to show that the number of parameters that a function requires is not a relevant indicator of the complexity of the function itself. It specifically uses a multi-parameter function converted to a very complicated single-parameter function to show this.

In the case you described where the arguments are spread into their components (as is the case in "normal" functions), the arguments can still have different precision, or more generally, different complexities. Look at a function that takes a quad, then look at a function that takes 5 bools. One is obviously more complex than the other (using the meaning of "complex" as discussed in the comments), and it has nothing to do with the number of arguments.

Disclaimer: I haven't read the article, just the comments here so please don't sue me if I'm incorrect.

Re:One parameter is always enough [pdf] by mlthoughts2018 on Saturday May 26, 2018 @09:26PM (#17165037)
This is exactly what I mean by “a trick of language” though. The superficial “number” of parameters is not important.

Think of it this way: suppose someone read this article and as a result they thought, “aha, Occam’s Razor is a sham because this shows that ‘simpler’ models (just “one” parameter!) are possibly even more susceptible to overfitting or generalization error. So I’m free to use whatever complex model I wan’t!”

Then they go and fit a 427-degree polynomial to their data set with 427 observations, and when someone says, “but using that many parameters is overly complex, you should prefer a simpler model” they’ll reply, “No way! Read this paper! It says that even simple models with a small number of parameters can have this problem.”

I know it’s a simplification, but it’s important. The notion of “a parameter” has to meaningfully capture an independent degree of freedom, and be a unit of constraint of the complexity (theoretically, Kolmogorov complexity, minimum description length of a program that models the underlying data generating process), or else it’s not a mathematical parameter, rather just a linguistic construct.

In the paper’s example, saying that the model “has one parameter” is misleading, because you need so much precision specifically to allow the “one parameter” to control many parameters worth of complexity.

So if someone had a takeaway point of “there’s not necessarily a reason to favor simpler models” that would be a big misunderstanding — yet it seems like the paper almost intentionally is set up to mislead in this way.

Re:One parameter is always enough [pdf] by jexah on Saturday June 02, 2018 @03:13PM (#17215903)
I absolutely do not disagree. My entire point is in your first paragraph.

> The superficial “number” of parameters is not important.

Whether the number of parameters is small or large does not change the complexity of the function, though if you're gonna pass 64 bools might as well call it a long long with bitwise OR to simplify the usability.

Re:One parameter is always enough [pdf] by 13of40 on Saturday May 26, 2018 @03:48PM (#17163914)
In a classic stack-based calling convention, every function takes one parameter: SP
Re:One parameter is always enough [pdf] by taneq on Saturday May 26, 2018 @01:51PM (#17163322)
It kind of seems like cheating, the same way Tupper's formula is cheating: https://en.wikipedia.org/wiki/Tupper%27s_self-referential_fo...

Edit: Dammit, userbinator's post below also mentions this an hour ago. :P

Re:One parameter is always enough [pdf] by muthdra on Saturday May 26, 2018 @03:58PM (#17163964)
I love the Tupper Formula.

I showed it to my teacher and he was immediately annoyed with it. He was like "yeah bro here, when he takes the modulo, he's basically shaving off bits from end of the the binary representation of that number. When he divides, he's shaving off bits from the start."

A humbling experience.

Once, during his class, I created a tiny python code that would let you draw monochromatically in the terminal then it would find the proper Tupper Formula Y offset that represented the image you drew.

It would simply loop over the drawing (I don't remember the directions but I believe it was bottom-to-top then left-to-right) and annotate wether there was a drawn pixel or not. This sequence was the binary representation of the Tupper Formula Y offset. "We should make something out of this", I jokingly said to my teacher. "They already did, it's called binary", he replied.

Re:One parameter is always enough [pdf] by laretluval on Saturday May 26, 2018 @08:45PM (#17164921)
> Nobody evaluates a model based simply on how well it fits the data and its number of parameters

This is standard practice in deep learning...

Re:One parameter is always enough [pdf] by AstralStorm on Saturday May 26, 2018 @12:33PM (#17162883)
Not to mention this function is not a regular parametric model - Fischer information matrix is undefined. (Not differentiable in logarithm.)
Re:One parameter is always enough [pdf] by comex on Saturday May 26, 2018 @01:27PM (#17163183)
How is it not differentiable in its logarithm? The function is just f(x) = sin^2(A * B^x), for some constants A and B (A encodes the data while B just determines the precision). The function itself is infinitely differentiable, so its logarithm will be infinitely differentiable everywhere except where f(x) = 0. However, it's not zero at the points that matter, and in any case we can avoid the issue by just adding a constant.
Re:One parameter is always enough [pdf] by AstralStorm on Sunday May 27, 2018 @04:03AM (#17165994)
Not the function itself, the log ratio of fit probabilities of any given pair of these. That is differentiable at most the Lebesgue sense and the likelihood requires something stronger. Specifically it has to be smooth everywhere to have KL divergence well defined. Adding a constant will give you a logarithm that breaks at zero still in log probability ratio.

So, both BIC and AIC are ill defined for this family of functions... Part of the reason the measure returns worthless garbage. This also happens with fits based on neural nets with tan or clipped activations. (Because sum of activations is nonsmooth as is fit probability.) But not with RBM or GMM or exponential neurons. These produce Gaussian or Pareto fit probabilities. (Polynomial probably also fail because they're not smooth functions but both measures could be corrected for nonsmoothness of likelilihood in this case.) Sum of sinc should work too as you get Wishart fit probabilities.

This funny chaotic function? I have no idea how distributed the answers are and whether the distribution is continuous.