Unfortunately most of the contexts were fairly specific and a few
years ago, so I don't remember all of the details, and mostly in the
context of private research that I'm not at liberty to share. Some of
the results have been published (though not my specific work) by a
then-colleague of mine; you can find his papers by googling "amine
ghrab graph olap".
On 4 January 2018 at 18:19, Ben Kovitz <bkov...@gmail.com> wrote:
> On Thursday, January 4, 2018 at 4:01:41 AM UTC-5, Gary Verhaegen wrote:
>
>> Have you considered encoding your port graph into a normal graph?
>
>
> That was the first idea I had, and I quickly rejected it as adding
> complication. The consideration that led me to port graphs in the first
> place was that when, say, I have a node for "plus", and it has neighbor
> nodes for "operand" and "sum", which other nodes connect to, an easy bug is
> that when the "plus" is deleted, its "operand" and "sum" nodes might not get
> deleted—leaving the graph in an invalid state. I figured it would be best to
> just absorb those connection nodes into the "plus" node in the form of a
> list of "ports", and include the port labels in the edges. Then deleting the
> "plus" automatically deletes the ports, you can easily query for "what nodes
> are connected to the plus" (where you want to skip connection nodes), and
> generally there are fewer ways to make mistakes in the code.
>
> However, following Christopher Small's suggestion to check out the Datomic
> APIs, I'm now thinking that a layer to map the port graphs to simplicial
> ("normal", undirected) graphs might actually be the simplest thing. Nodes,
> ports, and edges are easily represented by nodes in a simplicial graph. This
> escapes the "type headache" that led me to start this thread, since all
> edges in the port graph are just plain nodes in the simplicial graph,
> whether they're port-to-port edges, port-to-edge edges, or edge-to-edge
> edges. The layer of indirection might cost some performance—and performance
> does matter here, since this program is extremely CPU-bound—but it's more
> important to preëmpt bugs by keeping code simple.
>
> And now you make this interesting point, which I hadn't previously
> considered:
>
>> That would require you to define a mapping, but would then allow you to
>> fairly easily reuse theorems, algorithms and libraries by having them
>> operate on the encoded graph, with a hopefully thin layer of translation.
>
>
> I could even use ubergraph to represent the simplicial graph, and thereby
> get access to all code that follows the loom protocols.
>
>> I have seen this approach of encoding graphs into other graphs work out
>> pretty well in other contexts.
>
>
> Do you remember any of those other contexts? Maybe I could check one out and
> learn something from it.
>
>> If you’re shopping around for ideas as to how to define data manipulation
>> API, it may be worth taking some time looking at Specter too.
>
>
> Thanks for this suggestion, too. I'm now checking it out.
>
> --
> Ben Kovitz
> http://pages.iu.edu/~bkovitz/
>
> --
> 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/d/optout.
--
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/d/optout.
