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.
