"Edward is a Python library for probabilistic modeling, inference, and criticism. It is a testbed for fast experimentation and research with probabilistic models, ranging from classical hierarchical models on small data sets to complex deep probabilistic models on large data sets. Edward fuses three fields: Bayesian statistics and machine learning, deep learning, and probabilistic programming."
The announcement is on edwardlib.org (the URL shared on HN). Wouldn't that be an obvious connection? A project making an announcement about itself on its own website, seems natural to me.
The announcement should at least include a link to an explanation on the main project page. Due to only being posted on discourse, there is no direct link to go to the main project page, only by manually editing the URL or googling for Edward. Even the logo in the top-left corner only leads to the discourse overview page.
Edit: Just editing the URL leads to an HTTPS error because the certificate is only valid for *.github.io; you need to use HTTP.
What I meant is that if you have a major announcement about your project that you can reasonably expect to be shared, it's nice to give some context within the announcement.
I think this also applies to people on your mailing list. So often I get announcements sent out to a mailing list I signed up for where I forgot what the project is. Just having a sentence or two with a reminder goes a long way toward keeping me interested.
I totally agree. But in absence of that, I think tweaking headlines or adding parenthesized descriptions is good form, despite being against current HN policy.
“Everything being subsumed by TensorFlow” doesn’t seem to me like a particularly worrisome outcome. The status quo is “everything being a Python library,” and people generally seem to view that as positive. The PyData movement brought another level of interoperability to the ecosystem, so you can combine elements from Pandas, SciPy, sklearn, etc with good runtime performance and low cognitive load. Bringing everything into TensorFlow abstractions makes more optimizations possible (especially on heterogeneous architectures), and perhaps even more importantly, makes it easy to run end-to-end gradient descent on compositions of parts from across the ecosystem.
I don't have anything against Tensorflow, but I've learned over the years that it's good to have competition in numerical libraries and software so there's replication of results. Try your analysis using one library, and corroborate it using another one. When a field is dependent on one major piece of software, it's more susceptible to bugs--a programming bug becomes a misguided line of research for a whole field.
Edward has been a promising addition to the PPL landscape. I actually preferred using it with Theano when I used it but that was a year ago, and it seems to have been developing rapidly. I have mixed feelings about this announcement, although to be honest I don't totally even really understand all the implications of it. In some ways I'm not sure how much Edward incrementally adds above and beyond TF; it has occupied a niche between something like TF and Stan or PyMC which is fine enough but I've sometimes wondered if it was sustainable in the long run. I have appreciated it being around, though, and have hoped it would continue to develop.
(Yes, none of these are exactly 1:1 equivalent with numpy, but there absolutely are options. And from my point of view, having some options which aren’t tied to Python is healthy).
> it's good to have competition in numerical libraries and software so there's replication of results. Try your analysis using one library, and corroborate it using another one.
and then discover that they are all using netlib/lapack under the hood :b
I've had the pleasure of working with Edward for the last couple of months, and it's been the first PPL I've felt comfortable building a stable production codebase on top of.
It strikes a great balance between feeling like you're programming with probability distributions, and providing ways of diving under the hood to improve performance when you need to (like tweaking the underlying tf optimizer, or being able to implement your own distribution to use like a native one).
If such a library didn't exist, I would have needed to build my own. Congrats on the move to tf.contrib.
Time Series forecasting as a service. It's an area where careful treatment of error distributions matters a lot. There's a link in my HN profile, though the page won't be up for another week.
I had the same question when I was first choosing libraries for my current project!
So I put together this comparison of PyMC3, Edward, and Stan. It's jut doing bayesian inference on the location and scale of data sampled from a normal distribution. Super simple, but highlights the differences between the libraries.
Having worked with Edward, the LOC difference is deceptive. Edward has really solid abstract base classes, so developing on it is much more expressive for larger projects. I unequivocally recommend using Edward.
As a frequent user of Edward (big fan), I'm not sure I should be crazy about this - while it probably means that it'll get more frequent updates and love, I liked the researchy vibe that it had and its strong ties to sampling-based methods, etc. which might be lost in a move into contrib.
That being said, Dustin is probably working closely with Google people to do this properly, so it'll probably turn out ok in the end.
44 comments
[ 2.8 ms ] story [ 93.3 ms ] threadhttp://edwardlib.org/
Edit: Just editing the URL leads to an HTTPS error because the certificate is only valid for *.github.io; you need to use HTTP.
I think this also applies to people on your mailing list. So often I get announcements sent out to a mailing list I signed up for where I forgot what the project is. Just having a sentence or two with a reminder goes a long way toward keeping me interested.
Hopefully not a trend of everything being subsumed by Tensorflow.
Why?
Are you really saying those are all monopolies in their categories?
Edward has been a promising addition to the PPL landscape. I actually preferred using it with Theano when I used it but that was a year ago, and it seems to have been developing rapidly. I have mixed feelings about this announcement, although to be honest I don't totally even really understand all the implications of it. In some ways I'm not sure how much Edward incrementally adds above and beyond TF; it has occupied a niche between something like TF and Stan or PyMC which is fine enough but I've sometimes wondered if it was sustainable in the long run. I have appreciated it being around, though, and have hoped it would continue to develop.
R? Eigen? Neanderthal? HMatrix?
(Yes, none of these are exactly 1:1 equivalent with numpy, but there absolutely are options. And from my point of view, having some options which aren’t tied to Python is healthy).
It aims to have more features, and more speed than numpy, with Clojure, on the JVM + Nvidia + AMD + Intel.
Also relevant here is Bayadera, Clojure/GPU Bayesian modeling lib for the JVM: http://github.com/uncomplicate/bayadera
and
https://www.youtube.com/watch?v=bEOOYbscyTs
https://www.youtube.com/watch?v=TGxYfi3Vi3s
On the JVM, we're trying to do something like pytorch/numpy on the JVM. We also have python bindings:
https://github.com/deeplearning4j/nd4j
https://github.com/deeplearning4j/jumpy
We've been building this since 2014. Of note is we'll also be able to import TF, pytorch,.. in the next few months.
We're also an eclipse foundation project as of recently.
I think point still applies for new developing software: multiple implementations can corroborate each other or help identify bugs.
and then discover that they are all using netlib/lapack under the hood :b
https://research.fb.com/facebook-and-microsoft-introduce-new...
It strikes a great balance between feeling like you're programming with probability distributions, and providing ways of diving under the hood to improve performance when you need to (like tweaking the underlying tf optimizer, or being able to implement your own distribution to use like a native one).
If such a library didn't exist, I would have needed to build my own. Congrats on the move to tf.contrib.
I'm a probabilistic programming enthusiast, and I had the impression it's still an open research field.
Could you (or anyone else) comment on why would you choose Edward over something PyMC3? How does it compare?
So I put together this comparison of PyMC3, Edward, and Stan. It's jut doing bayesian inference on the location and scale of data sampled from a normal distribution. Super simple, but highlights the differences between the libraries.
https://github.com/cshenton/normal-comparison
Having worked with Edward, the LOC difference is deceptive. Edward has really solid abstract base classes, so developing on it is much more expressive for larger projects. I unequivocally recommend using Edward.
That being said, Dustin is probably working closely with Google people to do this properly, so it'll probably turn out ok in the end.
Anyone got experience of using Edward for serious inference using MCMC?
[1] http://andrewgelman.com/2017/05/31/compare-stan-pymc3-edward...
That book’s balance between theory and practice is remarkable, but im no fan of R :/