Can TCLOSE and GTC claim to be about directed paths without edges having a direction?
Quote from Erwin on June 11, 2020, 11:52 am"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 AntC on June 10, 2020, 6:09 amI've had a gutsful of [him] just blanket dismissing what so many people have said, they trying to be helpful, [and him] just not listening.
...
Failing that, I move to ban [him.]
I do note said participant's rare talent for winning friends and influencing people.
I hope he also takes this opportunity to reflect on it.
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 agree. The graph is constructed with an explicit link from x1 to y1. If there were a link from y1 to x1 there would be a second tuple in the relation to say as much. The diagram at Fig 6.2 on p183 shows these links drawn as arrows, in the direction from MAJOR to MINOR. The text "from node x to node y" is consistent.
However, there is nothing in the data to prefer one direction over the other. Nothing in the data says the direction is 'from x to y' rather than 'from y to x'. The TCLOSE is the path from P1 to P5 and P6, but it is also equivalently the path from P5 or P6 to P1. Nothing in the data says which direction to prefer. It is true that all the edges must be in the same direction, but the data does not tell us which direction that is. Is P1 the assembly containing parts P5 and P6, or do P5 and P6 contain part P1? You could draw the diagram reversing all the arrows, and get the very same TCLOSE.
The algorithm presented in DTATRM takes advantage of this by propagating in both directions and meeting up in the middle. Edges are added from the bottom up. [Incidentally, you can easily see the directionality here. Just change the order of the two RENAME operations as I did by accident, and TRANCLO will happily add 11 links in the reverse direction!]
This is useless for the GTC case presented later, where the edges must be added strictly 'top-down' to be able to do the calculation. That's the part I'm interested in, and DTATRM is no help.
Quote from dandl on June 12, 2020, 1:37 amQuote 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 agree. The graph is constructed with an explicit link from x1 to y1. If there were a link from y1 to x1 there would be a second tuple in the relation to say as much. The diagram at Fig 6.2 on p183 shows these links drawn as arrows, in the direction from MAJOR to MINOR. The text "from node x to node y" is consistent.
However, there is nothing in the data to prefer one direction over the other. Nothing in the data says the direction is 'from x to y' rather than 'from y to x'. The TCLOSE is the path from P1 to P5 and P6, but it is also equivalently the path from P5 or P6 to P1. Nothing in the data says which direction to prefer. It is true that all the edges must be in the same direction, but the data does not tell us which direction that is. Is P1 the assembly containing parts P5 and P6, or do P5 and P6 contain part P1? You could draw the diagram reversing all the arrows, and get the very same TCLOSE.
The algorithm presented in DTATRM takes advantage of this by propagating in both directions and meeting up in the middle. Edges are added from the bottom up. [Incidentally, you can easily see the directionality here. Just change the order of the two RENAME operations as I did by accident, and TRANCLO will happily add 11 links in the reverse direction!]
This is useless for the GTC case presented later, where the edges must be added strictly 'top-down' to be able to do the calculation. That's the part I'm interested in, and DTATRM is no help.
Well you've been asking about this in almost a dozen different posts and I still don't understand what your problem is or what you're asking, but FWIW look at the SIRA_PRISE syntax.
It ***forces*** the user to specify "how the mapping goes" as an explicit "(from,to)" attribute pair, ***even*** if it's just TCLOSE without G and ***even*** if the relation is binary so that there cannot be any doubt. The reason was that there is never a watertight guarantee that the relation subjected to TCLOSE is binary. Just like (in fact because) there is never a watertight guarantee that identifiers of the objects identified in the database are non-composite. Meaning there might be relations in the database holding two identifiers, each composite, that record, eurhm, well, relations [between real-world objects] of which we might want to be able to find the TCLOSE.
Quote from Erwin on June 12, 2020, 8:13 amQuote from dandl on June 12, 2020, 1:37 amQuote 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 agree. The graph is constructed with an explicit link from x1 to y1. If there were a link from y1 to x1 there would be a second tuple in the relation to say as much. The diagram at Fig 6.2 on p183 shows these links drawn as arrows, in the direction from MAJOR to MINOR. The text "from node x to node y" is consistent.
However, there is nothing in the data to prefer one direction over the other. Nothing in the data says the direction is 'from x to y' rather than 'from y to x'. The TCLOSE is the path from P1 to P5 and P6, but it is also equivalently the path from P5 or P6 to P1. Nothing in the data says which direction to prefer. It is true that all the edges must be in the same direction, but the data does not tell us which direction that is. Is P1 the assembly containing parts P5 and P6, or do P5 and P6 contain part P1? You could draw the diagram reversing all the arrows, and get the very same TCLOSE.
The algorithm presented in DTATRM takes advantage of this by propagating in both directions and meeting up in the middle. Edges are added from the bottom up. [Incidentally, you can easily see the directionality here. Just change the order of the two RENAME operations as I did by accident, and TRANCLO will happily add 11 links in the reverse direction!]
This is useless for the GTC case presented later, where the edges must be added strictly 'top-down' to be able to do the calculation. That's the part I'm interested in, and DTATRM is no help.
Well you've been asking about this in almost a dozen different posts and I still don't understand what your problem is or what you're asking, but FWIW look at the SIRA_PRISE syntax.
It ***forces*** the user to specify "how the mapping goes" as an explicit "(from,to)" attribute pair, ***even*** if it's just TCLOSE without G and ***even*** if the relation is binary so that there cannot be any doubt. The reason was that there is never a watertight guarantee that the relation subjected to TCLOSE is binary. Just like (in fact because) there is never a watertight guarantee that identifiers of the objects identified in the database are non-composite. Meaning there might be relations in the database holding two identifiers, each composite, that record, eurhm, well, relations [between real-world objects] of which we might want to be able to find the TCLOSE.
From what you say you already understand the problem and have a solution (unlike DTATRM or other contributors). I thought you might.
Would you care to post the syntax here, or a link, for the benefit of myself and others?
Quote from dandl on June 12, 2020, 9:33 amQuote from Erwin on June 12, 2020, 8:13 amQuote from dandl on June 12, 2020, 1:37 amQuote 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 agree. The graph is constructed with an explicit link from x1 to y1. If there were a link from y1 to x1 there would be a second tuple in the relation to say as much. The diagram at Fig 6.2 on p183 shows these links drawn as arrows, in the direction from MAJOR to MINOR. The text "from node x to node y" is consistent.
However, there is nothing in the data to prefer one direction over the other. Nothing in the data says the direction is 'from x to y' rather than 'from y to x'. The TCLOSE is the path from P1 to P5 and P6, but it is also equivalently the path from P5 or P6 to P1. Nothing in the data says which direction to prefer. It is true that all the edges must be in the same direction, but the data does not tell us which direction that is. Is P1 the assembly containing parts P5 and P6, or do P5 and P6 contain part P1? You could draw the diagram reversing all the arrows, and get the very same TCLOSE.
The algorithm presented in DTATRM takes advantage of this by propagating in both directions and meeting up in the middle. Edges are added from the bottom up. [Incidentally, you can easily see the directionality here. Just change the order of the two RENAME operations as I did by accident, and TRANCLO will happily add 11 links in the reverse direction!]
This is useless for the GTC case presented later, where the edges must be added strictly 'top-down' to be able to do the calculation. That's the part I'm interested in, and DTATRM is no help.
Well you've been asking about this in almost a dozen different posts and I still don't understand what your problem is or what you're asking, but FWIW look at the SIRA_PRISE syntax.
It ***forces*** the user to specify "how the mapping goes" as an explicit "(from,to)" attribute pair, ***even*** if it's just TCLOSE without G and ***even*** if the relation is binary so that there cannot be any doubt. The reason was that there is never a watertight guarantee that the relation subjected to TCLOSE is binary. Just like (in fact because) there is never a watertight guarantee that identifiers of the objects identified in the database are non-composite. Meaning there might be relations in the database holding two identifiers, each composite, that record, eurhm, well, relations [between real-world objects] of which we might want to be able to find the TCLOSE.
From what you say you already understand the problem and have a solution (unlike DTATRM or other contributors). I thought you might.
Would you care to post the syntax here, or a link, for the benefit of myself and others?
The formal grammar is at http://shark.armchair.mb.ca/~erwin/languageandgrammar_0105.html . The concerned entries are <ROtclose> and ROgtclose> .
Explanations can be found starting at http://shark.armchair.mb.ca/~erwin/languagetutorial_0105.html#ROtclose .
And the "examples" page (getting a bit of age though) has this : http://shark.armchair.mb.ca/~erwin/languageexamples_0105.html#TCLOSE .
And it's really really really extremely difficult to not find these pages using just a google search ...
Quote from Erwin on June 12, 2020, 12:53 pmQuote from dandl on June 12, 2020, 9:33 amQuote from Erwin on June 12, 2020, 8:13 amQuote from dandl on June 12, 2020, 1:37 amQuote 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 agree. The graph is constructed with an explicit link from x1 to y1. If there were a link from y1 to x1 there would be a second tuple in the relation to say as much. The diagram at Fig 6.2 on p183 shows these links drawn as arrows, in the direction from MAJOR to MINOR. The text "from node x to node y" is consistent.
However, there is nothing in the data to prefer one direction over the other. Nothing in the data says the direction is 'from x to y' rather than 'from y to x'. The TCLOSE is the path from P1 to P5 and P6, but it is also equivalently the path from P5 or P6 to P1. Nothing in the data says which direction to prefer. It is true that all the edges must be in the same direction, but the data does not tell us which direction that is. Is P1 the assembly containing parts P5 and P6, or do P5 and P6 contain part P1? You could draw the diagram reversing all the arrows, and get the very same TCLOSE.
The algorithm presented in DTATRM takes advantage of this by propagating in both directions and meeting up in the middle. Edges are added from the bottom up. [Incidentally, you can easily see the directionality here. Just change the order of the two RENAME operations as I did by accident, and TRANCLO will happily add 11 links in the reverse direction!]
This is useless for the GTC case presented later, where the edges must be added strictly 'top-down' to be able to do the calculation. That's the part I'm interested in, and DTATRM is no help.
Well you've been asking about this in almost a dozen different posts and I still don't understand what your problem is or what you're asking, but FWIW look at the SIRA_PRISE syntax.
It ***forces*** the user to specify "how the mapping goes" as an explicit "(from,to)" attribute pair, ***even*** if it's just TCLOSE without G and ***even*** if the relation is binary so that there cannot be any doubt. The reason was that there is never a watertight guarantee that the relation subjected to TCLOSE is binary. Just like (in fact because) there is never a watertight guarantee that identifiers of the objects identified in the database are non-composite. Meaning there might be relations in the database holding two identifiers, each composite, that record, eurhm, well, relations [between real-world objects] of which we might want to be able to find the TCLOSE.
From what you say you already understand the problem and have a solution (unlike DTATRM or other contributors). I thought you might.
Would you care to post the syntax here, or a link, for the benefit of myself and others?
The formal grammar is at http://shark.armchair.mb.ca/~erwin/languageandgrammar_0105.html . The concerned entries are <ROtclose> and ROgtclose> .
Explanations can be found starting at http://shark.armchair.mb.ca/~erwin/languagetutorial_0105.html#ROtclose .
And the "examples" page (getting a bit of age though) has this : http://shark.armchair.mb.ca/~erwin/languageexamples_0105.html#TCLOSE .
And it's really really really extremely difficult to not find these pages using just a google search ...
That addresses precisely the issues I raised. [Although I can't say I found the example particularly easy to work through.]
So DTATRM really choose a rather narrow subset of possible use cases for TCLOSE in their builtin operator, and their TRANCLO expansion. I assume it would be not too hard to code your extended TCLOSE and GTCLOSE as TD operators, except there is no way to pass in an 'attribute list'. The only way I can think of is to RENAME to known names, but it's starting to get clunky.
The attribute list of course gives that edge direction otherwise missing. Thanks! [Sorry about the Google, but I guess you knew what to Google for!]
Edit: I should have mentioned, when I did this in Andl I skipped TCLOSE and based it all on while, so the problem never arose. Done this way you have to code the pairings in the iterated relational function, so I completely missed this interesting little diversion.
Quote from dandl on June 12, 2020, 9:33 am... (unlike DTATRM or other contributors). ...
Quote from dandl on June 12, 2020, 2:12 pm... [Although I can't say I found the example particularly easy to work through.]
Your gloomy editorial quips and negative attitude add nothing, and lead to suggestions like that in post #15.
Stop it.
This is meant to be a forum for casual collaborative discussion about computer science, not an extension of your workplace. We are not employees to be castigated if our contributions don't meet your expectations.