That is pretty rad, thanks for sharing! On Wednesday, June 1, 2016 at 7:26:37 AM UTC-4, Conor White-Sullivan wrote: > > This is amazing to come across. > > I discovered Leo today after scouring the web trying to find some UI where > people were merging trees to create this a multi-dimensional dag, as you > describe. Totally in love with what you're doing. > > I also had the realization recently that layering trees to form a graph > could be incredibly powerful > > Here's the UI I built this weekend to get started > > > > <https://lh3.googleusercontent.com/-T_L5LZZPBhM/V06JBKAtnQI/AAAAAAAAAb0/OdRt_KcVOTonmv6KDlL2eki87A6KKwp-QCLcB/s1600/treedom2.gif> > > > Now just have to figure out a Clojure workflow and I'll be using your DAG > editor to build my graph editor ;) > > > > On Friday, February 12, 2016 at 4:42:20 AM UTC+5:30, Edward K. Ream wrote: >> >> John Lunzer's recent remarks has triggered one of the biggest Aha's in >> Leo's history, one that was totally unexpected until this afternoon. >> >> Leo's fundamental data structure is a tree of nodes. More accurately, it >> is a Directed Acyclic Graph or dag. Links in such a graph can point "down" >> the tree, but never up, so there are no cycles. Leo's clones are well >> defined just exactly because there are no cycles. Given a node, we know >> precisely *and* intuitively which nodes are descendants. Because of >> clones, a node may have more than one parent. >> >> Here's the Aha. Imagine this data structure as being linked with *black* >> thread. Now imagine another *completely independent* set of *red* >> threads. The only requirement is that the links defined by the red threads >> must *also* be a tree/dag. That is, there is *absolutely no* necessary >> relationship between the red and black threads. >> >> Now imagine that every Leo attribute creates its *own* sets of >> links/threads. *We have a new view for every attribute.* Let's call >> such a data structure a *multi-threaded tree/dag*. Trees might actually >> be enough, but I'm not sure so I'll refer to tree/dag (tree or dag). >> *Important*: some nodes may not have any thread running them for some >> colored threads (attributes). That's just fine. >> >> Alas, the term "multi-threaded data structure" is commonly used for data >> structures that can be accessed by independently running threads. That's >> not at all what I am talking about. >> >> I am not aware of anything like this in graph theory. Could this be a >> truly new idea? I really have no idea. >> >> Of course, you could call the resulting structure a general graph, and >> technically it is, but how the data structure will be used inside Leo is >> *very >> *different. Instead of a single, unintuitive mess, we have a collection >> of easily traversed trees/dags. *We instantly have an arbitrary >> dimensioned graph*! Each color creates a new dimension. Of course, we >> only *see* one dimension at a time, but attributes may be the >> *composition* of other attributes (unions, intersections or other >> relations), so this is no real restriction. >> >> And listen to this. *It is astoundingly easy to create this multi-dag >> in Leo*. At present, each vnode has a parents list and a children >> list. All we have to do is replace these two lists by dictionaries whose >> keys are attributes and whose values are the parents or children lists for >> those attributes. Finally, we add Python properties shield the dictionary >> lookup from the rest of Leo. We are talking about maybe 50 lines of code! >> As far as the rest of Leo is concerned, vnodes *still* have parents and >> children lists. The switcheroo happens totally invisibly, when the user >> wants to see another view. The attribute changes and that changes what the >> vnode dictionary/properties "deliver" to the rest of Leo. >> >> To recap: What we see depends only on the attribute that defines the >> view. This attribute determines what parents and children lists become >> active. So easy. So very powerful. >> >> Each *current view* will show only the nodes with the given attribute. >> To repeat, attributes can be composed of other attributes, so in effect >> each view can be associated with an *arbitrary set* of attributes. This >> is an *astoundingly* general data structure. >> >> The real challenge lies in assigning different colored links to nodes. >> I'm still trying to wrap my thoughts around all of this. >> >> As always with truly huge Ahas, it's already impossible to know exactly >> what thoughts lead to it. As soon as the Aha happened, the world changed >> so much that the past becomes hard to reconstruct. But for sure the >> following factors were "in the air": >> >> 1. Most importantly, the consensus has been building among the usual >> suspects that attributes are a more intuitive, and perhaps more powerful, >> alternative to clones. >> >> 2. For the last year I have been trying to ignore the fact that sometimes >> clones get in the way. This was the meaning of today's remark that "I love >> clones, I hate clones". >> >> 3. John's remark about attributes and hoists certainly triggered the >> avalanche. >> >> *Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes >> complexity. In particular, both hoists and chapters are a (mildly >> successful) attempt to make clones do the work of attribute-based views. In >> the new scheme, we simply re-thread nodes that we want to be part of the >> new view. >> >> *And notice*: when we require that views be made of clones we can *not* >> change any parent/child relationships. But that constraint completely >> disappears when we use attributes to define views. >> >> *Summary* >> >> This is one of the most momentous Aha's in Leo's history. It was >> completely unexpected this morning. It is almost too easy to make it >> happen. I may do it this evening. >> >> There remain important user interface questions concerning how nodes get >> assigned various colored threads, but I have faith that the result will be >> truly amazing. >> >> This Aha will have a huge number of happy consequences. Just for >> starters: >> >> 1. Searches can be limited to a single view (thread color). If we don't >> use clones in a view, each search will find a node at most once. This will >> erase my biggest pet peeve about Leo! >> >> 2. Every view (attribute) can define/create its own set of parent/child >> relationships, independently of all other views. Afaik, no other data >> structure is this flexible while still remaining intuitive. >> >> 3. It will be *very easy* for attribute editors to show nodes having >> those attributes in the most natural way *for that attribute* without >> being constrained in any way by other organizations of the data. Yes, this >> is really just a restatement of 2, but it's different in practice. >> >> No way would this Aha have happened without the interesting conversations >> that have taken place in the last few months. Well done, all of us! >> >> Edward >> >>
-- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
