However, I have some issues here. First, I don't know that I like the interface. Adding to the class instead of an instance of the class irks me. I also find the documentation hard to follow - the examples are too limited, and others are poorly formatted.
But its ruby, so I have no excuse to not try and clean it up some. I'll tinker and see what I can come up with in a PR.
Related, can anyone point me to something digestible that will bring me up to speed on the finer points of the mathematics?
Also, curious what kinda things this is used for in the wild? I don't know of anything that operates at all based on probabilities, so some examples would be helpful.
OP here, I used "adding to class" because I had assumed people would only use a single probability space at a time, and it would shorten the syntax since you didn't need to instantiate the space.
However, it's possible to make an instance of Ps and use the same interface. But I'd need to change a method or two around to support it. It wouldn't be a hard change. Do you envision using more than one separate probability spaces at once?
As for the docs, lemme know in an issue or PR what's too hard to follow. I tried to make it clear, but I welcome other eyes on it.
Naive Bayes Classifier is an example of something expressed all in probabilities. I only implemented a decision tree learner using Prolly, but am planning to implement more things using it in the near future.
I would definitely rather instantiate and build that way. I can dream up some examples where I might want to work with more than one type of probability. It would be good design to facilitate that, for sure.
I'm not up on the actual functionality - any reason you couldn't just work with an arbitrary collection of objects? Would be nice to make an AR query and wrap it in a Prolly object and work that way.
So, I'm pondering. When/where would I want to rely on probabilities instead of raw data? Everything I come up with seems like it would just work better with actual data values than deriving probabilities. But, that might just be my mathematical ignorance at play.
You could do what I’ve done with MIME::Types, which is make the class-level methods work against an instance. Most people use MIME::Types as the class-level methods, but it is possible to instantiate and use it otherwise.
By "work against an instance", do you mean that you instantiate the instance in the class-level methods? So at most, the class-level methods are just wrappers around the instance methods, emulating a singleton?
In the wild I think you'd be more likely to use something like PyMC or Stan, which work like Prolly but support arbitrarily complex models.
Still, love the idea.
To learn more about probability theory and Bayes, "Probability Demystified" is pretty good. (The Demystified series is McGraw-Hill's take on For Dummies.) To learn more about probabilistic programming, try http://camdavidsonpilon.github.io/Probabilistic-Programming-.... Or Google for MCMC.
I dunno how you'd use it in everyday programming, but it works really well for any sort of predictions. One of the examples in the "Probabilstic Programming and Bayesian Methods for Hackers" book is ranking a bunch of Reddit posts based on ups/downs but taking into account that fewer total votes equals more uncertainty.
Yeah, this is a new library. I don't expect people to use it in the wild just yet.
As for how to use it in everyday programming, I think machine learning techniques and algorithms could probably be made easier. But besides that, I was envisioning just as you can use regular expressions to do a "fuzzy match" on a string, I had wanted something that could do a "fuzzy match" on hashes, so I could branch based on a classification, rather than an exact match using "==". Something like a spam filter would be a common application. Your example about reddit would be another. Basically, making decision not just with the information on hand, but also based on prior examples.
Super cool idea! I love the fact that the interface is so simple and intuitive; I think that makes machine learning accessible to a much longer tail of problems that people would not have previously considered.
Thanks! I had tried a couple times to write this, but had some false starts. I tried to make it less verbose, and it's as good as I could get it for now.
I think this goes beyond what Prolly offers, and so might provide some inspiration for extending it in a consistent manner.