[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall <rjm@zenucom.com> writes:
>
> Hunsberger, Peter wrote:
>
> >Elliotte Harold <elharo@metalab.unc.edu> writes:
> >
> >
> >>Hunsberger, Peter wrote:
> >>
> >>
> >>
> >>
> >>>Which still leaves the original question; once you've got a way of
> >>>managing and manipulate graphs, why would you need a way to
> >>>distinguish trees? What does recognizing the special case get you?
> >>>
> >>>
> >>Because some things are true of trees which are not true of
> >>all graphs,
> >>the algorithms to process them can be made simpler and/or
> faster. For
> >>instance, you can do a depth first search or breadth first search
> >>without worrying about cycle detection.
> >>
> >>
> >>
> >
> >That's exactly my point, if we ever got to the point where we could
> >manage graphs (in general) I don't think you'd need to care
> about trees
> >anymore. Internally, software might optimize the management of all
> >kinds of special cases (not just trees), but if we've got Michaels
> >non-instance specific network exchange capability then at an
> interface
> >level you shouldn't care anymore?
> >
> >
> >
> the big difference between a graph and a tree is the "root"
> node. ie a
> tree has a starting point. second big difference, as noted
> earlier, is
> that trees don't have cycles. this means that trees match easily with
> the way our brains seem to organise information ("The Maths Gene: Why
> Everyone Has It, But Most People Don't Use It Keith Devlin
> <http://www.amazon.co.uk/exec/obidos/search-handle-url/index=b
ooks-uk&field-author=Devlin%2C%20Keith/202-9947616-2794245>")
>
> try thinking of an alternate way to express a graph using tags, that
is
> also easy to read. and looks like a graph. this is a constraint of one
> dimensional respresentation.
Your earlier reply to me is much more important than this discussion,
but it's going to take some more time to organize my thoughts on that
one....
Two quick things here:
I'm well aware of the differences between graphs and trees. The history
of this discussion was basically: How do we manage networks of
documents? I then turned that into a question of how to manage graphs.
Gavin responded with a question of how to determine whether something is
a graph or a tree, which I still don't get in this context. The way I
see it, if you've figured out how to do graphs (equivalent to how we do
XML today) then I don't care if it's a graph or a tree.
Second thing is that I don't think there is a nice one dimensional
representation for a graph. Nodes and edges are as good as it gets. So,
if we had generalized tools they'd be manipulating graphics the same way
we manipulate text today and some people would be complaining how
cumbersome it was to _say_ "draw [a] node [with] label X" and "connect X
[to] Y label A" ([] = optional keywords) instead of how cumbersome it
was to type in all those pointy brackets. Likely, the tool implementers
would be arguing over how the spec. on edge normalization was ambiguous
for some corner case or other, and the ancients on the list would be
saying things like "this perma-thread was started on xml-dev 10 years
ago"...
|
