Update on "C# is a D" project
Quote from AntC on May 17, 2020, 6:25 amQuote from dandl on May 17, 2020, 1:48 am
- Generate a 12 times multiplication table (or a multiplication table for N)
- Given a family tree, check whether there are any loops
- The Alice even query
I have found the ability to generate sequences surprisingly useful. Since while is enough and easy to implement, I looked no further.
In my rag-bag of ad-hoc data manipulation tools (chiefly used in ERP migrations), I have a pre-built table with an INT column containing every INT from zero up to a
2 ^ 16or so. I also have a table with every date from the invention of computers at least up to the probable death of anybody likely to need recording in the database -- that is if the ERP doesn't already have such a thing (most do).
SELECT INT1.INT AS X, INT2.INT AS Y, X * Y AS PRODUCT FROM INT AS INT1, INT AS INT2 WHERE INT1.INT <= 12 AND INT2.INT <= 12 ORDER BY X, Y;Nearly every requirement can be turned into a query over
INTand/or overDATE.
Of course, that's what we all do if the query language isn't powerful enough. I bet you have a little Cobol program to generate it, no?
What I'm about is more powerful query languages, so this is just a simple one liner (including generating the sequence).
Two steps is one too much (for getting addressed in a ***single*** operator that is offered by the system as a basic building brick).
Define an operator to do one thing, and do it right.
I have no idea what this means. GTC as described has three steps: path generation (TC), computation along path, aggregation across paths. Shorthands combine multiple steps into one for convenience (eg UPDATE). The while operator does one thing, and acts as a basic building block for this and other generative computations. RM VSS 5 requires a shorthand. What's your point?
You also don't claim that JOIN ought to include PROJECT functionality because the user's question necessitates projection and if JOIN doesn't do it then I must add the projection to the query myself, do you ?
The joins in TD include COMPOSE which is a shorthand for a join combined with a project.Why not have other similar shorthands?
User-defined generic operators per RM VSS 6 are shorthands. What's your point?
Nestability of the operators of the algebra is not the bug, it's the feature. Define an operator to do one thing, and do it right. Anything else leads to a new operator for each new query/user problem. (In fact, each newly written query ***IS***, in a sense, a newly written operator, and no developer in his right mind is ever going to expect from the DBMS provider that the latter has already included all the queries for the former, not ?)
Of course, and then combine them into user-defined operators and shorthands. What's your point?
EXTEND ( UNPACK (RELATION ( BODY ( TUPLE (INTRANGE(INTINTERVAL(FROM(0)TO(65535)))))), ,(INTRANGE)) , (MULTIPLE12(MULT(INTRANGE,12))))RELATION selects a singleton, UNPACK turns that into a 65535-tuple one (in which the interval type is traded for the underlying point type), EXTEND computes the multiples. Nobody has ever said "range generation" can only be solved using GTC or whatever other recursion-based means. That database programmers ***think so*** because it's the only way they can do it ***in SQL*** and that they have gotten it rusted into their brains so deeply that they cannot even imagine anymore that there might be other solutions too, is their problem not mine.
I don't understand UNPACK, but it sounds messy. Why generate 2^16 tuples when you only need 11? Why not use while?
RESTRICT ( TCLOSE ( PAR_CHI , (PARENT,CHILD) ) , EQ ( PARENT , CHILD ) )G not even needed. Where's the problem ?
Are you sure that works? It doesn't look right. Try this data:
name,boss Alice,Gail Bob,Alice Cindy,Alice Dave,Bob Emma,Bob Fred,Cindy Gail,Cindy
I don't know the details of Alice's "even" problem and I'm currently not going to go looking. Engine is having open-heart surgery and I want it running as soon as possible so that next time I might be able to show results along the code.
Essentially it's a relational expression to determine whether a relation is of even cardinality (rather than a scalar computation on COUNT).
Quote from dandl on May 17, 2020, 11:02 pmQuote from AntC on May 17, 2020, 6:25 amQuote from dandl on May 17, 2020, 1:48 am
- Generate a 12 times multiplication table (or a multiplication table for N)
- Given a family tree, check whether there are any loops
- The Alice even query
I have found the ability to generate sequences surprisingly useful. Since while is enough and easy to implement, I looked no further.
In my rag-bag of ad-hoc data manipulation tools (chiefly used in ERP migrations), I have a pre-built table with an INT column containing every INT from zero up to a
2 ^ 16or so. I also have a table with every date from the invention of computers at least up to the probable death of anybody likely to need recording in the database -- that is if the ERP doesn't already have such a thing (most do).
SELECT INT1.INT AS X, INT2.INT AS Y, X * Y AS PRODUCT FROM INT AS INT1, INT AS INT2 WHERE INT1.INT <= 12 AND INT2.INT <= 12 ORDER BY X, Y;Nearly every requirement can be turned into a query over
INTand/or overDATE.Of course, that's what we all do if the query language isn't powerful enough. I bet you have a little Cobol program to generate it, no?
What I'm about is more powerful query languages, so this is just a simple one liner (including generating the sequence).
A 100K SQL statement can be a one-liner too.
Quote from dandl on May 17, 2020, 11:50 pmTwo steps is one too much (for getting addressed in a ***single*** operator that is offered by the system as a basic building brick).
Define an operator to do one thing, and do it right.
I have no idea what this means. GTC as described has three steps: path generation (TC), computation along path, aggregation across paths. Shorthands combine multiple steps into one for convenience (eg UPDATE). The while operator does one thing, and acts as a basic building block for this and other generative computations. RM VSS 5 requires a shorthand. What's your point?
You also don't claim that JOIN ought to include PROJECT functionality because the user's question necessitates projection and if JOIN doesn't do it then I must add the projection to the query myself, do you ?
The joins in TD include COMPOSE which is a shorthand for a join combined with a project.Why not have other similar shorthands?
User-defined generic operators per RM VSS 6 are shorthands. What's your point?
Nestability of the operators of the algebra is not the bug, it's the feature. Define an operator to do one thing, and do it right. Anything else leads to a new operator for each new query/user problem. (In fact, each newly written query ***IS***, in a sense, a newly written operator, and no developer in his right mind is ever going to expect from the DBMS provider that the latter has already included all the queries for the former, not ?)
Of course, and then combine them into user-defined operators and shorthands. What's your point?
EXTEND ( UNPACK (RELATION ( BODY ( TUPLE (INTRANGE(INTINTERVAL(FROM(0)TO(65535)))))), ,(INTRANGE)) , (MULTIPLE12(MULT(INTRANGE,12))))RELATION selects a singleton, UNPACK turns that into a 65535-tuple one (in which the interval type is traded for the underlying point type), EXTEND computes the multiples. Nobody has ever said "range generation" can only be solved using GTC or whatever other recursion-based means. That database programmers ***think so*** because it's the only way they can do it ***in SQL*** and that they have gotten it rusted into their brains so deeply that they cannot even imagine anymore that there might be other solutions too, is their problem not mine.
I don't understand UNPACK, but it sounds messy. Why generate 2^16 tuples when you only need 11? Why not use while?
RESTRICT ( TCLOSE ( PAR_CHI , (PARENT,CHILD) ) , EQ ( PARENT , CHILD ) )G not even needed. Where's the problem ?
Are you sure that works? It doesn't look right. Try this data:
name,boss Alice,Gail Bob,Alice Cindy,Alice Dave,Bob Emma,Bob Fred,Cindy Gail,CindyI don't know the details of Alice's "even" problem and I'm currently not going to go looking. Engine is having open-heart surgery and I want it running as soon as possible so that next time I might be able to show results along the code.
Essentially it's a relational expression to determine whether a relation is of even cardinality (rather than a scalar computation on COUNT).
I've taken the liberty to leave some names out, saved some typing. Screenprints of the TC and of its restriction are attached. Screenprint of the UNPACK too.
Uploaded files:
Quote from Erwin on May 18, 2020, 11:29 amQuote from dandl on May 17, 2020, 11:50 pmTwo steps is one too much (for getting addressed in a ***single*** operator that is offered by the system as a basic building brick).
Define an operator to do one thing, and do it right.
I have no idea what this means. GTC as described has three steps: path generation (TC), computation along path, aggregation across paths. Shorthands combine multiple steps into one for convenience (eg UPDATE). The while operator does one thing, and acts as a basic building block for this and other generative computations. RM VSS 5 requires a shorthand. What's your point?
You also don't claim that JOIN ought to include PROJECT functionality because the user's question necessitates projection and if JOIN doesn't do it then I must add the projection to the query myself, do you ?
The joins in TD include COMPOSE which is a shorthand for a join combined with a project.Why not have other similar shorthands?
User-defined generic operators per RM VSS 6 are shorthands. What's your point?
Nestability of the operators of the algebra is not the bug, it's the feature. Define an operator to do one thing, and do it right. Anything else leads to a new operator for each new query/user problem. (In fact, each newly written query ***IS***, in a sense, a newly written operator, and no developer in his right mind is ever going to expect from the DBMS provider that the latter has already included all the queries for the former, not ?)
Of course, and then combine them into user-defined operators and shorthands. What's your point?
EXTEND ( UNPACK (RELATION ( BODY ( TUPLE (INTRANGE(INTINTERVAL(FROM(0)TO(65535)))))), ,(INTRANGE)) , (MULTIPLE12(MULT(INTRANGE,12))))RELATION selects a singleton, UNPACK turns that into a 65535-tuple one (in which the interval type is traded for the underlying point type), EXTEND computes the multiples. Nobody has ever said "range generation" can only be solved using GTC or whatever other recursion-based means. That database programmers ***think so*** because it's the only way they can do it ***in SQL*** and that they have gotten it rusted into their brains so deeply that they cannot even imagine anymore that there might be other solutions too, is their problem not mine.
I don't understand UNPACK, but it sounds messy. Why generate 2^16 tuples when you only need 11? Why not use while?
RESTRICT ( TCLOSE ( PAR_CHI , (PARENT,CHILD) ) , EQ ( PARENT , CHILD ) )G not even needed. Where's the problem ?
Are you sure that works? It doesn't look right. Try this data:
name,boss Alice,Gail Bob,Alice Cindy,Alice Dave,Bob Emma,Bob Fred,Cindy Gail,CindyI don't know the details of Alice's "even" problem and I'm currently not going to go looking. Engine is having open-heart surgery and I want it running as soon as possible so that next time I might be able to show results along the code.
Essentially it's a relational expression to determine whether a relation is of even cardinality (rather than a scalar computation on COUNT).
I've taken the liberty to leave some names out, saved some typing. Screenprints of the TC and of its restriction are attached. Screenprint of the UNPACK too.
Fair enough. It's not easy code to read (reminds me of Lisp, I wonder why?), but I think you're saying your TCLOSE will always represent a loop in a graph by a set of results where a node points to itself. Is that a required feature of TCLOSE? I can imagine implementations that did any of: loop forever, throw an exception, add a self loop, not add a self loop. Interesting.
My point though really was that while lets you write queries for this and countless other problems. My example turned out to be too easy.
In the other case, you have a custom function to generate an integer sequence, and that is doing the heavy lifting [Andl has that too]. Again, I should probably have picked a harder example. What about a Sudoku solver?
Quote from dandl on May 19, 2020, 1:26 am
Fair enough. It's not easy code to read (reminds me of Lisp, I wonder why?), but I think you're saying your TCLOSE will always represent a loop in a graph by a set of results where a node points to itself. Is that a required feature of TCLOSE? I can imagine implementations that did any of: loop forever, throw an exception, add a self loop, not add a self loop. Interesting.
My point though really was that while lets you write queries for this and countless other problems. My example turned out to be too easy.
In the other case, you have a custom function to generate an integer sequence, and that is doing the heavy lifting [Andl has that too]. Again, I should probably have picked a harder example. What about a Sudoku solver?
No. The definition of TCLOSE in TDATRM clearly and unmistakeably says the three tuples of someone having him/herself as a boss at some level, must be there. No options.
There is no risk of "loop forever" because once added to the result, there cannot be attempts to "add it again". Thus there is no ***need*** to throw an exception. And the definition leaves no room but to "add the self loop". Read it and apply it. For each of the three (say, X), there is a set of two other persons (Y and Z) such that (X,Y) and (Y,Z) and (Z,X). Thus (X,X) must be included. Matters become different for the generalized form because then the "self loops" can cause infinite addition of "the same loop" but, say, with ever increasing other computed values. So someone has to do something.
UNPACK is not a "custom function". It's a fundamental core operator from the "Temporal Data" books.
And Sudoku solvers, I do that in java. I fail to see the point of trying to do that in pure RA.
Quote from dandl on May 19, 2020, 1:26 amQuote from Erwin on May 18, 2020, 11:29 amQuote from dandl on May 17, 2020, 11:50 pmTwo steps is one too much (for getting addressed in a ***single*** operator that is offered by the system as a basic building brick).
Define an operator to do one thing, and do it right.
I have no idea what this means. GTC as described has three steps: path generation (TC), computation along path, aggregation across paths. Shorthands combine multiple steps into one for convenience (eg UPDATE). The while operator does one thing, and acts as a basic building block for this and other generative computations. RM VSS 5 requires a shorthand. What's your point?
You also don't claim that JOIN ought to include PROJECT functionality because the user's question necessitates projection and if JOIN doesn't do it then I must add the projection to the query myself, do you ?
The joins in TD include COMPOSE which is a shorthand for a join combined with a project.Why not have other similar shorthands?
User-defined generic operators per RM VSS 6 are shorthands. What's your point?
Nestability of the operators of the algebra is not the bug, it's the feature. Define an operator to do one thing, and do it right. Anything else leads to a new operator for each new query/user problem. (In fact, each newly written query ***IS***, in a sense, a newly written operator, and no developer in his right mind is ever going to expect from the DBMS provider that the latter has already included all the queries for the former, not ?)
Of course, and then combine them into user-defined operators and shorthands. What's your point?
EXTEND ( UNPACK (RELATION ( BODY ( TUPLE (INTRANGE(INTINTERVAL(FROM(0)TO(65535)))))), ,(INTRANGE)) , (MULTIPLE12(MULT(INTRANGE,12))))RELATION selects a singleton, UNPACK turns that into a 65535-tuple one (in which the interval type is traded for the underlying point type), EXTEND computes the multiples. Nobody has ever said "range generation" can only be solved using GTC or whatever other recursion-based means. That database programmers ***think so*** because it's the only way they can do it ***in SQL*** and that they have gotten it rusted into their brains so deeply that they cannot even imagine anymore that there might be other solutions too, is their problem not mine.
I don't understand UNPACK, but it sounds messy. Why generate 2^16 tuples when you only need 11? Why not use while?
RESTRICT ( TCLOSE ( PAR_CHI , (PARENT,CHILD) ) , EQ ( PARENT , CHILD ) )G not even needed. Where's the problem ?
Are you sure that works? It doesn't look right. Try this data:
name,boss Alice,Gail Bob,Alice Cindy,Alice Dave,Bob Emma,Bob Fred,Cindy Gail,CindyI don't know the details of Alice's "even" problem and I'm currently not going to go looking. Engine is having open-heart surgery and I want it running as soon as possible so that next time I might be able to show results along the code.
Essentially it's a relational expression to determine whether a relation is of even cardinality (rather than a scalar computation on COUNT).
I've taken the liberty to leave some names out, saved some typing. Screenprints of the TC and of its restriction are attached. Screenprint of the UNPACK too.
Fair enough. It's not easy code to read (reminds me of Lisp, I wonder why?), but I think you're saying your TCLOSE will always represent a loop in a graph by a set of results where a node points to itself. Is that a required feature of TCLOSE? I can imagine implementations that did any of: loop forever, throw an exception, add a self loop, not add a self loop. Interesting.
My point though really was that while lets you write queries for this and countless other problems. My example turned out to be too easy.
In the other case, you have a custom function to generate an integer sequence, and that is doing the heavy lifting [Andl has that too]. Again, I should probably have picked a harder example. What about a Sudoku solver?
The world has all the declarative Sudoku solvers and -- because it almost always gets mentioned in the next breath -- Mandlebrot set generators it already needs. (In the former case, zero would be more than enough.)
Far more interesting is application to real problems. I note that Hugh has been very forthcoming with his real applications of Rel / Tutorial D. I suppose I could do the same, though it would require a small festival of anonymisation.
I'm curious what real-world problems others are solving with their implementations.