Earlier quoted context omitted.
It's a fair question, but from my heydays doing ML research even good libraries can be pretty revolutionary. The engineering-side of ML is still in relative infancy. For a great example look at all the papers Andrew McCallum's group has been able to publish by building on top of FACTORIE: they get to focus their time on the problem at hand rather than all the math required to solve it. Basically they can write code t…
> ML is getting closer and closer to being an everyday tool for engineers rather than something that requires you to be a full-time math person I so wish! As a Sr Data Scientist, I interview potential candidates quite often, many of these are 10x engineers. Me: (2,3,4) is a vector. Eng: Ok. Me: Gimme a unit vector in the same direction. Eng 1: ??? Eng 2: "It can be done. I don't know how, but with Spark it can be don…
Probabilistic programming does in 50 lines of code what used to take thousands
51–60 of 81 posts
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#52Earlier quoted context omitted.
I've played with it a bit and, in my opinion, the principles behind it at least, the streamlined and optimized simulation of bayesian generative models is the best chance we have to solve artificial general intelligence. Reading probmods.org and dippl.org made me go from being very pessimistic I would see it in my lifetime to a solid maybe.
It's a very powerful statistical technique, yes, but I doubt it will be enough for AI. The problem is that you need to sample efficiently from the posterior distribution, and for anything AI related, MCMC isn't going to cut it. Let's take a step back and consider a logical problem. Can you put N socks in N-1 boxes such that no box contains more than one socks? Obviously not, it's the pigeonhole principle. Convert tha…
For example, I have been toying with using MCMH similarly to how it is used in dippl.org to write a kind of probabilistic program that generates other programs by sampling from a probabilistic programming language grammar. A bit like with the arithmetic generator here: https://probmods.org/learning-as-conditional-inference.html#... but for whole programs.
After the MCMH has converged to a program that generates approximately correct output, you can tune grammar hyperparameters on the higher likelihood output program samples so that next time it will converge faster.
I don't know if this counts as approximating "the generative distribution and the inference distribution at the same time" under your definition but my hope is that the learned grammar rules are good abstractions for hierarchical generators of learned concepts.
Of course the worry is that my approach will not converge very fast but there are reasons to think that having a suitably arranged hyperparametrized probabilistic grammar might use the Occams' razor inherent in bayesian methods to produce exponentially fewer, simpler grammar rules that generate approximations when it doesn't have enough data to converge to more complex and precise programs and that these simple rules which rely on fewer parameters might provide the necessary intermediate steps to then pivot to more complex rules. These smaller steps help MCMH to find a convergence path. Not sure how well it will work for complex problems however. My idea is still half baked. I have ton's of loose ends and details I have not figured out, some of which I might not even have a solution, as well as little time to work on this (this is just a hobby for me).
Anyways, all that to say that probabilistic programming can go beyond just hardcoding a generative model and running it.
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#53> “It goes beyond image classification — the most popular task in computer vision — and tries to answer one of the most fundamental questions in computer vision: What is the right representation of visual scenes? Can someone knowledgeable in graphics research explain the context that this question comes from? If I am reading the question correctly, I infer that the question suggests that there exists a right way to r…
Think about Dreaming. "seeing" during a dream state works by experiencing pure data representation of the real world. People fluent in lucid dreaming can tell you something funny happens when you try to thorough examine objects while sleeping. Constructed worlds tend to be skin deep, and fall apart when poked. Everything is build with ideas drawn from your experience. Its Plato's Allegory of the Cave all the way down…
"The world is such and such or so and so, only because we talk to ourselves about its being such and such and so and so..." Carlos Castaneda
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#54Earlier quoted context omitted.
It's a fair question, but from my heydays doing ML research even good libraries can be pretty revolutionary. The engineering-side of ML is still in relative infancy. For a great example look at all the papers Andrew McCallum's group has been able to publish by building on top of FACTORIE: they get to focus their time on the problem at hand rather than all the math required to solve it. Basically they can write code t…
> ML is getting closer and closer to being an everyday tool for engineers rather than something that requires you to be a full-time math person I so wish! As a Sr Data Scientist, I interview potential candidates quite often, many of these are 10x engineers. Me: (2,3,4) is a vector. Eng: Ok. Me: Gimme a unit vector in the same direction. Eng 1: ??? Eng 2: "It can be done. I don't know how, but with Spark it can be don…
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#55Earlier quoted context omitted.
> ML is getting closer and closer to being an everyday tool for engineers rather than something that requires you to be a full-time math person I so wish! As a Sr Data Scientist, I interview potential candidates quite often, many of these are 10x engineers. Me: (2,3,4) is a vector. Eng: Ok. Me: Gimme a unit vector in the same direction. Eng 1: ??? Eng 2: "It can be done. I don't know how, but with Spark it can be don…
Wouldn't you just take the length of the vector with sqrt(4+9+16) and divide each component by it? Or is this a different kind of 'vector' than graphics people are familiar with?
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#56Earlier quoted context omitted.
> ML is getting closer and closer to being an everyday tool for engineers rather than something that requires you to be a full-time math person I so wish! As a Sr Data Scientist, I interview potential candidates quite often, many of these are 10x engineers. Me: (2,3,4) is a vector. Eng: Ok. Me: Gimme a unit vector in the same direction. Eng 1: ??? Eng 2: "It can be done. I don't know how, but with Spark it can be don…
"to save their lives" is a little dramatic, considering they were in a closed tech interview. I'm sure if you gave them 20 seconds on the internet (you know, the resource they would have in a real life problem solving situation) they could find one.
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#57relevant paper: http://mrkulk.github.io/www_cvpr15/1999.pdf
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#58If anyone wants to jump into this, Josh Tenenbaum and Noah Goodman put together this amazing interactive book for learning probabilistic programming with Church: https://probmods.org/
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#59If anyone wants to jump into this, Josh Tenenbaum and Noah Goodman put together this amazing interactive book for learning probabilistic programming with Church: https://probmods.org/
Great project but very weird choice of language. How probable is it (pun intended) that the person coming to learn about probabilistic programming would already know functional programming?
Re: Probabilistic programming does in 50 lines of code what used to take thousands
#60Probabilistic prediction: this is primarily going to be used for robots that monitor, kill or assist with killing people.