Outside of the UI/UX issues it's a great idea, and I would probably play all the levels if those were fixed.
628 karma · joined November 8, 2014
Outside of the UI/UX issues it's a great idea, and I would probably play all the levels if those were fixed.
1. Things that are the result of a very large number of small perturbations follow a Gaussian distribution.
1a. Word embeddings are the result of millions/billions/trillions of small perturbations (i.e. gradient descent)
2. As you increase the dimension, d, of a multivariate Gaussian distribution, the actual mass of the data is increasingly concentrated in the thin spherical shell. For MVN distributions with standardized marginal dimensions, this is on the sphere of radius \sqrt{d}.
In fact when I searched "Gaussian curse of dimensionality" I got this at the top result: [1] which shows this phenomena perfectly. Or this one with pretty interactive pictures [2]
[1]: https://www.miryusupov.com/blog/posts/thin-shells/index.html
[2]: https://aseemrb.me/blog/high-dimensional-gaussians-on-a-sphe...
What exactly do you mean by this? Speed? Portability? Ease of use?
I really do think it’s a good idea to explore! Sometimes I feel crazy because I’m the only one in my department that prefers to just write SQL to deal with our DBs instead of fiddling with a python/R connector that always has its own quirks.
However, I don't see what the benefits of this are (other than having a simple DSL, but that creates the yet another DSL problme) over ggplot2. What do I gain by using this over ggplot2 in R?
The only problem, and the only reason I ever leave ggplot2 for visualizations, is how difficult it is to do anything "non-standard" that hasn't already had a geom created in the ggplot ecosystem. When you want to do something "different" it's way easier to drop into the primitive drawing operations of whatever you're using than it is to try to write the ggplot-friendly adapter.
Even wrapping common "partial specificiations" as a function (which should "just work" imo) is difficult depending on whether you're trying to wrap something that composes with the rest of the spec via `+` or via pipe (`|>`, the operator formerly known as `%>%`)
Fuck Parkinson's.
The pain points around getting a sampler/model pairing working in a reasonable timeframe is definitely a valid complaint. In my experience, inference methods in Bayesian stats are much less forgiving of poorly specified models (or said another way, don’t let you get away with ignoring important structural components of the phenomena of interest). A poorly performing model (in terms of sampler speed/mixing) is often a sign of a problem with the geometry of the parameter space. Frustratingly this can sometimes be a result of conceptually equivalent, but computationally different parameterizations (e.g. centered vs non-centered multi level effects).
The struggles are worth it IMO because it is helpful feedback that helps guide design, and the ease with which I can compute meaningful uncertainty bounds on pretty much any quantity of interest is invaluable.
I also recommend Gelman’s (one of the authors of the linked book) Regression and Other Stories as a more approachable text for this content.
Think Bayes and Bayesian Methods for Hackers are introductory books from a beginner coming from a programming background.
If you want something more from the ML world that heavily emphasizes the benefits of probabilistic (Bayesian) methods, I highly recommend Kevin Murphy’s Probabilistic Machine Learning. I have only read the first edition before he split it into two volumes and expanded it, but I’ve only heard good things about the new volumes too.
I feel like Breiman sets up a strawman that I've never encountered when I work with my colleagues that are trained in the statistics community. That doesn't mean it didn't exist 25 years ago when he wrote it. I concede that we are sometimes willing to make simplifying assumptions in order to state something particular, but it's almost like we've been culturally conditioned to steep everything we say with every caveat possible.
Whereas I am constantly having to point out the poor feedback we've had about some of the XGBoost models despite the fact that they're clearly the most "predictive" when evaluated naively.
That's the funny thing about the idea of meaningful things. It is solely determined by what you think is meaningful. Personally, just sitting and making something is an extremely meaningful activity to me.
I've had a lot of success with Numpyro (a JAX library), and used quite a lot of tools that are simpler interfaces to Stan. I've also had to write quite a few model-specific things from scratch by hand (more for sequential Monte Carlo than MCMC). I'm very excited for a world where PPLs become scalable and easier to use /customize.
> I think there is a good chance that normalizing flow-based variational inference will displace MCMC as the go-to method for Bayesian posterior inference as soon as everyone gets access to good GPUs.
Wow. This is incredibly surprising. I'm only tangentially aware of normalizing flows, but apparently I need to look at the intersection of them and Bayesian statistics now! Any sources from anyone would be most appreciated!
If anyone has a YT video or a detailed article, please show me!
As far as the wiki: It's not hosted. It's just on my local machine. You basically just drop the minified JS library in a tiddler and then create a custom widget type and a ViewTemplate to automatically display the widget when the content-type is the correct one.
I used http://whatfettle.com/2008/05/TiddlyProcessing/ as the basis (although it's old) and the main docs on creating a custom widget (https://tiddlywiki.com/dev/#Javascript%20Widget%20Tutorial)
If you want to see what you can really do with TW, or want to learn how, check out Grok TiddlyWiki (https://groktiddlywiki.com/read/)
I built a personal chess knowledge base with it too. I added a content-type that let me just paste in a plain-text representation of the game and it would display the game with an interactive board.