On Friday, February 8, 2013 1:56:27 AM UTC-8, Edmund wrote: > > Hey Jason, > > Going slightly OT here to describe my motivations, but you did ask > for more details ! :) > > I wrote a little blog post + lib last month using Stuart Sierra's Flow > (much like > Graph) to implement the steps in doing a very simple discrete inference > task. Its > demonstrating the same thing you talk about in your post about > declarative computation - here the point is that you can efficiently > update your > inference based new data on account of having the > graph structure to work over. Here's the post > http://boss-level.com/?p=160 and a > literate version of the code http://ejackson.github.com/inflow/ > This is my original motivation. >
I think I understand what you're trying to do from the example, thanks! > What I'm doing there is 'building-up' the computation over time, > so I start with a graph with just the input data, and end up with a > graph with the input and output. But the 'building up' is not the > principal hangup I > have: I'm happy to have an in- and out- map. The problem is, when > dealing with a very nested graph, getting a fine grained syntax for > describing where to put the outputs. Ie how do I tell Graph to put just > the output x into > {:a {:b 1 :c x}} of the graph, without replacing the entire map of the :a > key ? > Like I said earlier, it's a requirement of Graph that node names must be unique, and distinct from top-level input keys. Thus, there cannot be a way to 'put x into the map under :a at key :c' , because there is no way to in-place modify the inputs or other node values of the graph. The output is just a map of all the node results, nothing more and nothing less. That said, you can use a hierarchical graph to specify different node functions for the different sub-keys: ;; As a hierarchical graph user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b) :c (fnk [[:a1 b]] (inc b))}}) {:a1 {:b 1}}) {:a2 {:b 1, :c 2}} So for an example like the one you gave in the above link, you can represent your nested stats directly as a nested graph without resorting to key flattening. And if you want to compute just a subset of the graph for updated downstream values and then merge this into your previous map, you can do this in two steps: 1. Pick out the subset of leaf functions that may have changed, using the same strategy you currently use with Flow, and construct a Graph with only those sub-keys. For example: user> ((eager-compile {:a2 {:b (fnk [[:a1 b]] b)}}) {:a1 {:b 2}}) {:a2 {:b 2}} , then 2. deep-merge these results with the original result map. i..e, (deep-merge-with (fn [x y] y) original-results updated-results) where deep-merge-with is http://clojuredocs.org/clojure_contrib/clojure.contrib.map-utils/deep-merge-with This logic could be wrapped up into a single higher-order function that takes a graph and knows how to incrementally update the results given incremental changes in input. Does that make sense / seem like it will satisfy your need? Cheers, Jason > That's obviously no good if I need to have lots of things changing > beneath :a in a single graph flow due to uniqueness.[ > > With Flow what I did is flatten the nested graph such that the keys are > vectors of the path to each node, run the flow on that graph, and then > re-nest the the graph afterwards (the flow-> and ->flow functions). > So the map {:a {:b 1 :c x}} becomes {[:a :b] 1, [:a :c] x}, and I can > refer to > nested nodes this way. > > In Graph such a scheme would be possible too, but that Graph enforces > keywords as the keys for the graph. Having vectors for the keys still > allows you to > have uniqueness, topological ordering etc. So the example I gave in my > last email: > > {:a {:b 1}} -> {:a {:b 1, :c 2}} > > could, hypothetically, be written for just the outputs as > > ((graph/eager-compile {[:a :c] (fnk [[:a b]] (inc b))}) > {:a {:b 1}}) > > >> {:a {:c 2}} > > So my question is: how do I refer to nested nodes in the output > selector using Graph? Conditionally, on that being impossible, would > there be any merit in the vector scheme that I have suggested ? > > Sorry for the long post, I hope I haven't obscured my question. I also > get the feeling that I must be missing something very obvious in your > code for how to do this ! > > Edmund > > > On Thursday, 7 February 2013 19:27:13 UTC, Jason Wolfe wrote: >> >> On Thu, Feb 7, 2013 at 10:54 AM, AtKaaZ <atk...@gmail.com> wrote: >> > Hello. >> > >> https://github.com/Prismatic/plumbing/blob/master/test/plumbing/graph_examples_test.clj#L148 >> >> > Why do they return in a map instead of maybe a set ? do we ever get >> {:key >> > false} ? >> > Thanks. >> >> The leaf value for output schemata is always 'true'. It's a bit odd, >> but to support specifications of functions/graphs that return nested >> maps, the outer layers need to be maps. It's true that the innermost >> layers could be represented as sets, but we chose to keep things >> uniform instead. >> >> > >> > >> > On Thu, Feb 7, 2013 at 7:22 PM, Jason Wolfe <ja...@w01fe.com> wrote: >> >> >> >> We've just posted a blog post with more high-level context on what >> we're >> >> trying to accomplish with Graph (plus more examples!) >> >> >> >> >> >> >> http://blog.getprismatic.com/blog/2013/2/1/graph-abstractions-for-structured-computation >> >> >> >> >> We're also answering questions and reading comments in the Hacker News >> >> thread, if that's your thing: >> >> >> >> http://news.ycombinator.com/item?id=5183236 >> >> >> >> Cheers, Jason >> >> >> >> >> >> On Tuesday, January 29, 2013 10:46:54 AM UTC-8, Aria Haghighi wrote: >> >>> >> >>> Hey all, >> >>> >> >>> Prismatic has open-sourced our Plumbing and Graph library on github. >> >>> Jason Wolfe gave a talk about how we use graph for systems >> composition at >> >>> Strange loop last year. Please give the library >> >>> a whirl and let us know if you're using it and if you find any issues >> or >> >>> feature requests. We use this library very heavily throughout our >> code and >> >>> hope others find it useful as well. >> >>> >> >>> Best, Aria >> >> >> >> -- >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups "Clojure" group. >> >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient >> with >> >> your first post. >> >> To unsubscribe from this group, send email to >> >> clojure+u...@googlegroups.com >> >> For more options, visit this group at >> >> http://groups.google.com/group/clojure?hl=en >> >> --- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Clojure" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an >> >> email to clojure+u...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> > >> > >> > >> > >> > -- >> > Please correct me if I'm wrong or incomplete, >> > even if you think I'll subconsciously hate it. >> > >> > -- >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clo...@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> your >> > first post. >> > To unsubscribe from this group, send email to >> > clojure+u...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> > --- >> > You received this message because you are subscribed to the Google >> Groups >> > "Clojure" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to clojure+u...@googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.