I don't know entirely how to provide a sufficient TLDR for this, but it's something like: an embedded relational programming system can let python reason about the computation graphs for other embedded DSLs, with examples such as deriving the parametric distributions for related random variables in probabilistic programming.
This is interesting to me on a few levels:
- I've been trying to better understand relational programming for a bit, and reading an explication of a non-scheme minikanren is clarifying.
- This does suggest an approach for automating/mechanizing a bunch of the derivational stuff that happens in ML sometimes. The examples spelled out (about conjuage priors for example) are pretty simple, but in the extreme one could derive some programs mechanically from some assumptions and stipulations.
- Some things which we can already do mechanistically could potentially be reframed in a more extensible way with this kind of approach. For example, cvxpy has a set of rules that it uses to determine whether a function and constraints are convex, prior to throwing a problem at a convex solver. I think if one re-expressed the same stuff in these relational terms, you could get a version which is more readily extensible (when you have a new function whose vexity/tonicity you can describe). One step further would be "fill in a hole in this formula which makes the whole thing convex".
1 comment
[ 3.1 ms ] story [ 15.1 ms ] threadThis is interesting to me on a few levels:
- I've been trying to better understand relational programming for a bit, and reading an explication of a non-scheme minikanren is clarifying.
- This does suggest an approach for automating/mechanizing a bunch of the derivational stuff that happens in ML sometimes. The examples spelled out (about conjuage priors for example) are pretty simple, but in the extreme one could derive some programs mechanically from some assumptions and stipulations.
- Some things which we can already do mechanistically could potentially be reframed in a more extensible way with this kind of approach. For example, cvxpy has a set of rules that it uses to determine whether a function and constraints are convex, prior to throwing a problem at a convex solver. I think if one re-expressed the same stuff in these relational terms, you could get a version which is more readily extensible (when you have a new function whose vexity/tonicity you can describe). One step further would be "fill in a hole in this formula which makes the whole thing convex".