symbolic-pymc
symbolic-pymc copied to clipboard
pymc-devs
Tools for the symbolic manipulation of PyMC models, Theano, and TensorFlow graphs.
Per discussion with @RandallBalestriero, add `logical-unification` and `cons` support for [`symjax`](https://github.com/RandallBalestriero/SymJAX) (i.e. `networkx.DiGraph`) graphs.
We can create a function that constructs a `RandomVariable` class for a given PyMC3 `Distribution` class. The basic requirements are 1. that #109 be in place and `log_lik = Distribution.logp(out_var)`,...
~~In `RandomVariable.make_node`, return `theano.gof.Apply(self, inputs, (rng.type(), out_var, log_lik))`—where `log_lik` is a graph of the log-likelihood for the given RV. This addition will allow `RandomVariable`s to represent both measure and sample-space...
We can extend the automatic closed-form multivariate normal posterior optimization to the time-series case and compute condition posteriors for terms in DLMs/state-space models. To start, this would involve all the...
Just some updates for the TensorFlow-based documentation/examples.
`NodeDef` name values can now be interpreted as "non-strict" by using a special `str` type. This type tells `TFlowMetaOp.reify` to skip the unique name check and defer to the base...
This addresses #56 in another way; namely, it uses an intermediate/temporary TF graph that mirrors a given meta graph with the meta tensor terms replaced by `Placeholder`s. The temporary TF...
`MetaSymbol.reify` is still pretty stack-driven, which is bad for scaling toward larger graphs, so we should consider implementing a trampolined approach (e.g like `etuples` and `unification`).
An issue arises when reifying meta tensors that are intended to be new to a TF graph, because a tensor with an unspecified name value is currently set—by default—to its...
In some instances, we automatically create logic variables as stand-ins for unspecified meta object components (e.g. #35, [`TFlowMetaOp.outputs`](https://github.com/pymc-devs/symbolic-pymc/blob/master/symbolic_pymc/tensorflow/meta.py#L633)); following #84, we should always produce properly "typed" generic objects and we...