Can TCLOSE and GTC claim to be about directed paths without edges having a direction?
DTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
Quote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
Quote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong. Ordinary English usage path 'from A to B' refers to a path with direction, and says nothing about the reverse. The English usage for a two-way path is path 'between A and B'. The use of examples like parts explosion, family true, org chart reinforces that. The reverse path (if any) is named differently: part 'is a component of'', child 'is offspring of', worked 'is bossed by'.
But that was just a minor oversight on the part of the D&D authors. The important omission is re GTC, where the words 'an arc from node Pi to node Pj' mean just that, because 'Each arc is labeled with the corresponding quantity'. And you cannot do the GTC from minor to major, it has to be ordered, from major to minor. There are arrows in the diagram, but in the text and the data it was completely overlooked.
Quote from dandl on June 10, 2020, 12:38 amQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong.
David is wrong. I've already tried to say so on the topic of TCLOSE multiple ways round. There seems to be no point in continuing this 'yes it is'/'no it isn't' sort of thread.
Ordinary English usage ...
Seems to be a matter David struggles with.
I've had a gutsful of David just blanket dismissing what so many people have said, they trying to be helpful, David just not listening.
Can we set up the Wordpress software such that Bennet, D cannot reply to a post before a 12-hour stand-down period? A period during which David might try to reflect on the answers he's received from people who know what they're talking about.
Failing that, I move to ban Bennett, D.
Quote from dandl on June 10, 2020, 12:38 amQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong. Ordinary English usage path 'from A to B' refers to a path with direction, and says nothing about the reverse.
Graph theory, not Ordinary English. Unless specified otherwise, transitive closure is about reachability on undirected graphs. You can certainly define it for directed graphs, too.
See virtually any graph theory reference.
Quote from AntC on June 10, 2020, 6:09 amQuote from dandl on June 10, 2020, 12:38 amQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong.
David is wrong. I've already tried to say so on the topic of TCLOSE multiple ways round. There seems to be no point in continuing this 'yes it is'/'no it isn't' sort of thread.
Ordinary English usage ...
Seems to be a matter David struggles with.
I've had a gutsful of David just blanket dismissing what so many people have said, they trying to be helpful, David just not listening.
Can we set up the Wordpress software such that Bennet, D cannot reply to a post before a 12-hour stand-down period? A period during which David might try to reflect on the answers he's received from people who know what they're talking about.
Failing that, I move to ban Bennett, D.
I'm inclined to only ban -- whether temporary or permanent -- for persistent, irredeemable abusiveness and/or intentional nastiness. I'm not sure "not listening" counts.
Quote from Dave Voorhis on June 10, 2020, 7:41 amQuote from dandl on June 10, 2020, 12:38 amQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong. Ordinary English usage path 'from A to B' refers to a path with direction, and says nothing about the reverse.
Graph theory, not Ordinary English. Unless specified otherwise, transitive closure is about reachability on undirected graphs. You can certainly define it for directed graphs, too.
See virtually any graph theory reference.
Well, I still take the view that the description could better reflect that for the benefit of the casual reader, if it was the intention.
But that's not really the question. I'm much more interested in how to characterise the path followed by the GTC example in developing a parts explosion. That can clearly only be calculated directionally, from assembly to component, and that isn't reflected in the description AFAICT.
I'm only concerned with the first part, what they call concatenate. I think aggregate is the same as elsewhere. Any thoughts on how that should look, as an RA operator? Or is there an implementation, as for TRANCLO?
Quote from Dave Voorhis on June 10, 2020, 7:49 amQuote from AntC on June 10, 2020, 6:09 amQuote from dandl on June 10, 2020, 12:38 amQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This is wrong.
David is wrong. I've already tried to say so on the topic of TCLOSE multiple ways round. There seems to be no point in continuing this 'yes it is'/'no it isn't' sort of thread.
Ordinary English usage ...
Seems to be a matter David struggles with.
I've had a gutsful of David just blanket dismissing what so many people have said, they trying to be helpful, David just not listening.
Can we set up the Wordpress software such that Bennet, D cannot reply to a post before a 12-hour stand-down period? A period during which David might try to reflect on the answers he's received from people who know what they're talking about.
Failing that, I move to ban Bennett, D.
I'm inclined to only ban -- whether temporary or permanent -- for persistent, irredeemable abusiveness and/or intentional nastiness. I'm not sure "not listening" counts.
"Not listening" as in asking a question, getting an answer and willfully ignoring it only to come back and ask the same question again, and again, and again, is certainly persistent, is certainly disrespectful toward the ones who provided an answer, and if the "same question" is rephrased and rephrased and rephrased, even if only scarcely, merely for the purpose of being able to claim "it's not the same" is certainly abuse of the right to ask questions. At least he doesn't get into verbal aggressive mode within 5 mins, like that other friend did, so many time ago. So I was just going to try and ignore his posts, but after his latest in this thread yet I decided to let you know what passed through my mind seeing that [latest post], in regard to whether and/or how "it counts".
Quote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This must be wrong. If there are tuples t1(x1,y1) and t2(x2,y2) with y1=x2, then tr(x1,y2) is included in the result. In the "other direction", that becomes If there are tuples t2(x2,y2) and t1(x1,y1) with y2=x1, then tr(x2,y1) is included in the result. The equality being tested is different, the resulting tuple possibly included in the result is too. The fundamental relevance of "direction" cannot become clearer than that. Which is why Adrian once said you can "mimick" undirected graphs by unioning the relation representing it with its "inverse", that is, represent the connect between nodes 1 and 2 as TUP{1,2}TUP{2,1}.
Quote from Erwin on June 11, 2020, 3:07 pmQuote from Dave Voorhis on June 9, 2020, 7:57 amQuote from dandl on June 9, 2020, 1:26 amDTATRM p183:
(In other words, the “<x,y>“ tuple appears in r+ only if there is a path in the graph from node x to node y, loosely speaking.)
This statement implies a direction, but TCLOSE is not directional. The TCLOSE presented in the accompanying code is correct: it will create a path from X to Y and equivalently a path from Y to X. It's a non-cyclic graph, but it's not a DAG. For that, you would need to know the direction of each edge. DTATRM fails to mention that.
The GTC on p 236 makes it absolutely clear that the paths have direction, from MAJOR to MINOR. But on p239 the it lists 4 arguments to a proposed GTC operator, but gives no means by which to determine the direction of the edges. There is no way given by which to know that P1 contains 5 x P2, and not P2 contains 5 x P1.
In practice, it means that for TCLOSE to produce an ordered list of paths, or for GTC to produce the results shown, there needs to be some means to determine the direction of each edge in the path.
A path from x to y means that there are a series of zero (i.e., x is connected to y) or more connected nodes between x and y. It doesn't imply a direction, and a path from x to y implies a path from y to x.
It's about connection, not direction.
This must be wrong. If there are tuples t1(x1,y1) and t2(x2,y2) with y1=x2, then tr(x1,y2) is included in the result. In the "other direction", that becomes If there are tuples t2(x2,y2) and t1(x1,y1) with y2=x1, then tr(x2,y1) is included in the result. The equality being tested is different, the resulting tuple possibly included in the result is too. The fundamental relevance of "direction" cannot become clearer than that. Which is why Adrian once said you can "mimick" undirected graphs by unioning the relation representing it with its "inverse", that is, represent the connect between nodes 1 and 2 as TUP{1,2}TUP{2,1}.
I'm not sure it's wrong, but it may be more usual to use different terminology. Per https://algowiki-project.org/en/Transitive_closure_of_a_directed_graph (and my distant recollection from taking a graph theory course a few thousand years ago) "... for an undirected graph, the search for transitive closure is equivalent to finding connected components."