Tuple visibility through a view
Quote from Dave Voorhis on October 25, 2019, 3:32 pmQuote from p c on October 25, 2019, 3:19 pmQuote from Dave Voorhis on October 25, 2019, 2:49 pmQuote from p c on October 25, 2019, 2:41 pmQuote from Dave Voorhis on October 25, 2019, 2:23 pmQuote from p c on October 25, 2019, 2:12 pmQuote from Dave Voorhis on October 25, 2019, 2:03 pmQuote from p c on October 25, 2019, 1:56 pmQuote from Dave Voorhis on October 25, 2019, 1:26 pmQuote from p c on October 25, 2019, 1:19 pmQuote from Dave Voorhis on October 25, 2019, 12:44 pmQuote from p c on October 25, 2019, 12:14 pm“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y. in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.
“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?
“In other words, how does it impact the schema I gave in post #20?
“How, and where, do I turn it into Tutorial D?...”
These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?
There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither..
Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.
Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.
Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.
A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.
Quote from p c on October 25, 2019, 12:38 pmForgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.
Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves. I mean think about the argument, not assume translation for implementation!
Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.
Does anyone here understand @p-c's replies?
I'm left wondering if you're the database equivalent to Irwin Corey.
Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.
How can I attempt to show it wrong when "the meat" is incomprehensible?
I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?
If it can't be implemented -- or the implementation can't be explained -- it's not a better way.
Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.
I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.
It's clear that you are letting your experience distract you into not focussing your thinking on the minimum needed to focus on for these specific problems.
I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.
A resume is not an answer to your original questions.
Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.
Picked at random, this:
For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a:
(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y) & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).
Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.
I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen
In short, I think you're faking it.
I didn't expect you'd pick the hardest one! So start with the first wff of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?
No, why would it?
All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".
Do you mean constant? Or constraint?
Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?
Sometimes I miss typos because I don't always recognize some print, whether small or large.
I meant constraint.
Do you remember this paragraph from my latest long post?:
"A simulation or argument using this particular generator assumes that x>y is a logical implication akin to x->y or x implies y and in set terms it means that x represents a subset of y in the sense that if t is a member of x, then t is a member of y. Depending on other wffs in an argument it may also mean that x is an empty subset of y."
Given that quote and the five simplifications I also gave, can you now answer with certainty, not 'maybe', whether the wff expresses the meaning of your constraint? Stick to the question.
I can answer with absolute certainty that I have no idea what it has to do with my constraint -- and by "my constraint", I can only presume you mean the "foreign key" constraint CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber} in the post #20 scenario -- because you've made no attempt to explain it.
I think @johnwcowan's assessment is right.
Just to confirm, are you saying that you have no idea how set membership in set theory corresponds to logical implication in propositional theory?
I meant to say:
Just to confirm, are you saying that you have no idea how set membership in set theory corresponds to logical implication in propositional theory?
Quote from p c on October 25, 2019, 4:13 pmQuote from Dave Voorhis on October 25, 2019, 3:32 pmQuote from p c on October 25, 2019, 3:19 pmQuote from Dave Voorhis on October 25, 2019, 2:49 pmQuote from p c on October 25, 2019, 2:41 pmQuote from Dave Voorhis on October 25, 2019, 2:23 pmQuote from p c on October 25, 2019, 2:12 pmQuote from Dave Voorhis on October 25, 2019, 2:03 pmQuote from p c on October 25, 2019, 1:56 pmQuote from Dave Voorhis on October 25, 2019, 1:26 pmQuote from p c on October 25, 2019, 1:19 pmQuote from Dave Voorhis on October 25, 2019, 12:44 pmQuote from p c on October 25, 2019, 12:14 pm“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y. in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.
“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?
“In other words, how does it impact the schema I gave in post #20?
“How, and where, do I turn it into Tutorial D?...”
These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?
There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither..
Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.
Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.
Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.
A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.
Quote from p c on October 25, 2019, 12:38 pmForgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.
Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves. I mean think about the argument, not assume translation for implementation!
Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.
Does anyone here understand @p-c's replies?
I'm left wondering if you're the database equivalent to Irwin Corey.
Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.
How can I attempt to show it wrong when "the meat" is incomprehensible?
I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?
If it can't be implemented -- or the implementation can't be explained -- it's not a better way.
Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.
I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.
It's clear that you are letting your experience distract you into not focussing your thinking on the minimum needed to focus on for these specific problems.
I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.
A resume is not an answer to your original questions.
Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.
Picked at random, this:
For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a:
(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y) & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).
Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.
I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen
In short, I think you're faking it.
I didn't expect you'd pick the hardest one! So start with the first wff of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?
No, why would it?
All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".
Do you mean constant? Or constraint?
Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?
Sometimes I miss typos because I don't always recognize some print, whether small or large.
I meant constraint.
Do you remember this paragraph from my latest long post?:
"A simulation or argument using this particular generator assumes that x>y is a logical implication akin to x->y or x implies y and in set terms it means that x represents a subset of y in the sense that if t is a member of x, then t is a member of y. Depending on other wffs in an argument it may also mean that x is an empty subset of y."
Given that quote and the five simplifications I also gave, can you now answer with certainty, not 'maybe', whether the wff expresses the meaning of your constraint? Stick to the question.
I can answer with absolute certainty that I have no idea what it has to do with my constraint -- and by "my constraint", I can only presume you mean the "foreign key" constraint CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber} in the post #20 scenario -- because you've made no attempt to explain it.
I think @johnwcowan's assessment is right.
Just to confirm, are you saying that you have no idea how set membership in set theory corresponds to logical implication in propositional theory?
Sorry, what does that have to do with what I wrote?
Please, please, please read what I've written again and again: I have no idea what your "one-liner arguments" have to do with anything. You may feel your formulae clarify or make a point, but they don't because they're not connected to anything. The closest they came was one paragraph that indicated a meant InvoiceHeading {InvoiceNumber}, b meant InvoiceDetail {InvoiceNumber}, and c meant InvoiceHeading {InvoiceNumber} JOIN InvoiceDetail {InvoiceNumber}, but the explanations for d and x and y were baffling.
In general, your explanations are either baffling or absent, relying on the reader to -- presumably -- intuit your intent rather than clearly explaining it. Really, it shouldn't be this difficult, particularly if the solution is meant to be implemented by systems programmers and software engineers.
Perhaps explain what you have in mind in plain English?
[quote]
Sorry, what does that have to do with what I wrote?
Please, please, please read what I've written again and again: I have no idea what your "one-liner arguments" have to do with anything. You may feel your formulae clarify or make a point, but they don't because they're not connected to anything. The closest they came was one paragraph that indicated a meant InvoiceHeading {InvoiceNumber}, b meant InvoiceDetail {InvoiceNumber}, and c meant InvoiceHeading {InvoiceNumber} JOIN InvoiceDetail {InvoiceNumber}, but the explanations for d and x and y were baffling.
In general, your explanations are either baffling or absent, relying on the reader to -- presumably -- intuit your intent rather than clearly explaining it. Really, it shouldn't be this difficult, particularly if the solution is meant to be implemented by systems programmers and software engineers.
Perhaps explain what you have in mind in plain English? [end quote]
When you say you have no idea what they have to do with anything I must take that as meaning you think they have nothing to do with anything. Maybe that means you don't understand what a logical argument is. If you don't understand the use of d,x and y then you don't understand a syntactic expression. Understanding a logical argument and not understanding syntax is a contradiction. Whatever plain English is, it's not contradictions.
When you also say you see no "connections" that tells me either the simplifications are unclear or they're in error. This would mean that as given you would not be able to apply a single one of them in a completely different problem about something else. Which ones?
If you mean the paragraph you allude to in the above quote doesn't come close enough to explaining how the symbols a and b can simultaneously stand for relations, sets, wffs, propositions, argument premises and conclusions and even relvars and can be mechanically manipulated according only to syntax to evaluate logical validity and the conclusions can be understood as representing combinations of the same procedural steps that a TD already uses to delete base relvar values then I must conclude again you aren't following the argument logically, without baggage that's irrelevant to a logical argument. If you can apply the premises, the argument conclusions control what a dbms that obeys them is allowed to do. If you understand the argument and its a good applicable one for the problem, then the conclusion should tell you all you need to know.
For example, one of the conclusions is a&x. Maybe you are wondering what does x mean for an implementation. Well, it means nothing except that since a&x is true, a must be true. All the argument tells you besides that conclusion is that x is defined in terms of other booleans. When a&x is true and the database contains no relation corresponding to x, that must tell you that the relation corresponding to 'a' has the same value it started with, namely true for all its original tuples. In fact, the conclusions emphasize that with a double negative at the end.
If the argument you quote is obeyed, then when the delete definition it signifies is invoked, no tuple in (base) relvar a is deleted by a command such as Delete C{B attributes} WHERE (some condition referring to B attributes) and C stands for the join of your base relvars and B stands for a sufficient enough projection of your InvoiceDetails relvar to identify an InvoiceDetails tuple or tuples it means your implementation obeys the conclusion.
I have already said that d,x and y are synthetic wffs used only for purposes of logical argument evaluation. They are used only for the evaluation of the argument premises and conclusion. They have nothing to do with language implementation. They exist only for logical purposes, not dbms purposes. They are not defined, that is assumed, externally like the other booleans/sets, only within the argument. If you want, you could think of them as shorthands that allow the argument to get out of hand because it would be half a page long without them.
The fact that you are obsessed with a syntactic device suggests you have not actually been able to work through the premises and conclusions or I have made a technical mistke.
Regarding implementing by system engineers, to emphasize what I've already said and which you haven't disputed: I see no need for implementing logical arguments, say by a TD compiler, only application of their conclusions. In the simplest case, this is matter of making sure an existing TD implementation follows a suitable delete definition.
Quote from p c on October 25, 2019, 6:58 pm[quote]
Sorry, what does that have to do with what I wrote?
Please, please, please read what I've written again and again: I have no idea what your "one-liner arguments" have to do with anything. You may feel your formulae clarify or make a point, but they don't because they're not connected to anything. The closest they came was one paragraph that indicated a meant InvoiceHeading {InvoiceNumber}, b meant InvoiceDetail {InvoiceNumber}, and c meant InvoiceHeading {InvoiceNumber} JOIN InvoiceDetail {InvoiceNumber}, but the explanations for d and x and y were baffling.
In general, your explanations are either baffling or absent, relying on the reader to -- presumably -- intuit your intent rather than clearly explaining it. Really, it shouldn't be this difficult, particularly if the solution is meant to be implemented by systems programmers and software engineers.
Perhaps explain what you have in mind in plain English? [end quote]
When you say you have no idea what they have to do with anything I must take that as meaning you think they have nothing to do with anything. Maybe that means you don't understand what a logical argument is. If you don't understand the use of d,x and y then you don't understand a syntactic expression. Understanding a logical argument and not understand syntax is a contradiction. Whatever plain English is, it's not contradictions.
When you also say you see no "connections" that tells me either the simplifications are unclear or they're in error. This would mean that as given you would not be able to apply a single one of them in a completely different about something else. Which ones?
If you mean the paragraph you allude to in the above quote doesn't come close enough to explaining how the symbols a and b can simultaneously stand for relations, sets, wffs, propositions, argument premises and conclusions and even relvars and can be mechanically manipulated according only to syntax to evaluate logical validity and the conclusions can be understood as representing combinations of the same procedural steps that a TD already uses to delete base relvar values then I must conclude again you aren't following the argument logically ...
What argument?
You provided what appear to be formulae. In one paragraph, you indicated that some letters in the formulae (a, b, and c) relate to some expressions in what appears to be Tutorial D syntax, with what I assume to be relvar and attribute names drawn from post #20. Outside of that, whatever connection exists between the formulae and anything else is not described, explained, or even mentioned sufficiently to apply them to anything. I am familiar with logical arguments and the use of symbolic logic. Other than sharing a very superficial resemblance to logical arguments and symbolic logic, your posts don't appear to involve either one.
Quote from Dave Voorhis on October 25, 2019, 7:09 pmQuote from p c on October 25, 2019, 6:58 pm[quote]
Sorry, what does that have to do with what I wrote?
Please, please, please read what I've written again and again: I have no idea what your "one-liner arguments" have to do with anything. You may feel your formulae clarify or make a point, but they don't because they're not connected to anything. The closest they came was one paragraph that indicated a meant InvoiceHeading {InvoiceNumber}, b meant InvoiceDetail {InvoiceNumber}, and c meant InvoiceHeading {InvoiceNumber} JOIN InvoiceDetail {InvoiceNumber}, but the explanations for d and x and y were baffling.
In general, your explanations are either baffling or absent, relying on the reader to -- presumably -- intuit your intent rather than clearly explaining it. Really, it shouldn't be this difficult, particularly if the solution is meant to be implemented by systems programmers and software engineers.
Perhaps explain what you have in mind in plain English? [end quote]
When you say you have no idea what they have to do with anything I must take that as meaning you think they have nothing to do with anything. Maybe that means you don't understand what a logical argument is. If you don't understand the use of d,x and y then you don't understand a syntactic expression. Understanding a logical argument and not understand syntax is a contradiction. Whatever plain English is, it's not contradictions.
When you also say you see no "connections" that tells me either the simplifications are unclear or they're in error. This would mean that as given you would not be able to apply a single one of them in a completely different about something else. Which ones?
If you mean the paragraph you allude to in the above quote doesn't come close enough to explaining how the symbols a and b can simultaneously stand for relations, sets, wffs, propositions, argument premises and conclusions and even relvars and can be mechanically manipulated according only to syntax to evaluate logical validity and the conclusions can be understood as representing combinations of the same procedural steps that a TD already uses to delete base relvar values then I must conclude again you aren't following the argument logically ...
What argument?
You provided what appear to be formulae. In one paragraph, you indicated that some letters in the formulae (a, b, and c) relate to some expressions in what appears to be Tutorial D syntax, with what I assume to be relvar and attribute names drawn from post #20. Outside of that, whatever connection exists between the formulae and anything else is not described, explained, or even mentioned sufficiently to apply them to anything. I am familiar with logical arguments and the use of symbolic logic. Other than sharing a very superficial resemblance to logical arguments and symbolic logic, your posts don't appear to involve either one.
The argument you quoted. The one that introduced d,x and y.
Did you actually read the original explanation where I explained the syntax by quoting the instructions for the generator I'm using?
Do you not appreciate that '/' separates premises from conclusions in the argument? Is that what you mean by no connections?
Quote from p c on October 25, 2019, 7:29 pmQuote from Dave Voorhis on October 25, 2019, 7:09 pmQuote from p c on October 25, 2019, 6:58 pm[quote]
Sorry, what does that have to do with what I wrote?
Please, please, please read what I've written again and again: I have no idea what your "one-liner arguments" have to do with anything. You may feel your formulae clarify or make a point, but they don't because they're not connected to anything. The closest they came was one paragraph that indicated a meant InvoiceHeading {InvoiceNumber}, b meant InvoiceDetail {InvoiceNumber}, and c meant InvoiceHeading {InvoiceNumber} JOIN InvoiceDetail {InvoiceNumber}, but the explanations for d and x and y were baffling.
In general, your explanations are either baffling or absent, relying on the reader to -- presumably -- intuit your intent rather than clearly explaining it. Really, it shouldn't be this difficult, particularly if the solution is meant to be implemented by systems programmers and software engineers.
Perhaps explain what you have in mind in plain English? [end quote]
When you say you have no idea what they have to do with anything I must take that as meaning you think they have nothing to do with anything. Maybe that means you don't understand what a logical argument is. If you don't understand the use of d,x and y then you don't understand a syntactic expression. Understanding a logical argument and not understand syntax is a contradiction. Whatever plain English is, it's not contradictions.
When you also say you see no "connections" that tells me either the simplifications are unclear or they're in error. This would mean that as given you would not be able to apply a single one of them in a completely different about something else. Which ones?
If you mean the paragraph you allude to in the above quote doesn't come close enough to explaining how the symbols a and b can simultaneously stand for relations, sets, wffs, propositions, argument premises and conclusions and even relvars and can be mechanically manipulated according only to syntax to evaluate logical validity and the conclusions can be understood as representing combinations of the same procedural steps that a TD already uses to delete base relvar values then I must conclude again you aren't following the argument logically ...
What argument?
You provided what appear to be formulae. In one paragraph, you indicated that some letters in the formulae (a, b, and c) relate to some expressions in what appears to be Tutorial D syntax, with what I assume to be relvar and attribute names drawn from post #20. Outside of that, whatever connection exists between the formulae and anything else is not described, explained, or even mentioned sufficiently to apply them to anything. I am familiar with logical arguments and the use of symbolic logic. Other than sharing a very superficial resemblance to logical arguments and symbolic logic, your posts don't appear to involve either one.
The argument you quoted. The one that introduced d,x and y.
Did you actually read the original explanation where I explained the syntax by quoting the instructions for the generator I'm using?
Do you not appreciate that '/' separates premises from conclusions in the argument? Is that what you mean by no connections?
No, not at all. You posted what appears to be a random formula, not an argument. By no connections, I mean what does it have to do with anything?
Please, Dave, stop. This is blowing up my mailbox (I am subscribed to all threads) and it's utterly futile.
Quote from johnwcowan on October 25, 2019, 7:57 pmPlease, Dave, stop. This is blowing up my mailbox (I am subscribed to all threads) and it's utterly futile.
Yes, you're right, and apologies for the mail bombing. I'm out of this one and any future p-c postings unless sense is made.
Do you not appreciate that '/' separates premises from conclusions in the argument? Is that what you mean by no connections?
No, not at all. You posted what appears to be a random formula, not an argument. By no connections, I mean what does it have to do with anything?
Bingo!
So you think the premises
(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y) & -(d&x = d&y )
and the conclusion
-(c & b&y) > a&x & -b & -c &-(-a)
do not form a logical argument?
Say yes and I will completely understand your difficulty.
(Maybe you want to call the wffs formulas. That lingo doesn't matter in a formal argument.)
If you think the wffs/formulas are 'random', it can only mean you haven't worked through them one by one. Note that the conclusion is itself an implication according to customary precedence rules.