Questions about some relational operator definitions and comments about the DIVIDEBY operation

#21 · February 14, 2020, 1:31 pm

Quote from Erwin on February 14, 2020, 1:31 pm

Quote from Greg Klisch on February 13, 2020, 11:55 pm

Quote from Erwin on February 6, 2020, 8:06 am

Re. "contradiction in the definition because recording the details of a shipment ..." : the source of your perceiving a "contradiction" here probably stems from you attaching too much meaning to the word "shipment". I believe "Introduction to database systems" has an explicit remark to the effect that "SHIPMENT" represents "potential shipments" and not "shipments actually made on a specific day to a specific destinee" or some such. That's another book than the one you were reading, so it's not "your fault", and the choice of name could indeed be considered unfortunate, but then again otoh it's typically impossible to cover all of the semantics of an external predicate in one single name acting as the predicate symbol.

Does "SUPPLIERS" have a similar definition to the effect that "SUPPLIERS" supply all "potential" parts? If so, am I able to infer that all parts, current and potential, are provided by all suppliers? If so, then would not the answer to the query--quantified or not quantified--'Get suppliers who supply every ... part' simply be (by definition)?:

S {S#}

After all, there is nothing in the query about shipments! As worded, the query refers only to suppliers and parts, not shipments.

Somewhere along the way, the word "shipment" got included in the discussion. The suppliers and parts database has a relvar named SP and its [external] predicate says something like "<thisorthat supplier> supplies <thisorthat part> in <thisorthat quantity>". The relvar (and whatever relation it contains to represent the extension of that predicate) can be used to find the relation that is the extension of the predicate "<thisorthat supplier> supplies all parts" or "<thisorthat supplier> supplies all purple parts" if and only if the sense in which "supplies" is used in the latter two predicates is the very same sense as the one in which it is used in the former. No logic can ever be helpful in providing such guarantees, except perhaps in the sense that predicates "divide" "the world" in a set of objects that satisfy it and another set of objects that don't. So we could both enumerate our view of what that "division" (of the world in two sets of objects) looks like and see if it is identical or not. If so, we can conclude that we agree on the precise meaning of [all the words in] the predicate.

At some point, we always find ourselves left with only words as explained in the dictionary, and there's nothing but others words to attempt to arrive at such explanation. Given how blatantly obviously this mechanism "begs its own question", it's a miracle it works as well as it does. I sometimes use pink elephants as an example but using that example might sometimes also require that I explicitly specify that the small plastic toy my three-year old kid sometimes plays with, and which looks remarkably much like an elephant and is remarkably pink, does not qualify as a "pink elephant" nonetheless.

I suppose it was this I was referring to when I made that original remark you quoted.

(And no, according to me, the suppliers-and-parts database does not have a sense of "potential supplier" or "potential part" and I think most people who ever read "Introduction to Database Systems" would agree with that.)

Quote from Greg Klisch on February 13, 2020, 11:55 pm

Quote from Erwin on February 6, 2020, 8:06 am

Re. "contradiction in the definition because recording the details of a shipment ..." : the source of your perceiving a "contradiction" here probably stems from you attaching too much meaning to the word "shipment". I believe "Introduction to database systems" has an explicit remark to the effect that "SHIPMENT" represents "potential shipments" and not "shipments actually made on a specific day to a specific destinee" or some such. That's another book than the one you were reading, so it's not "your fault", and the choice of name could indeed be considered unfortunate, but then again otoh it's typically impossible to cover all of the semantics of an external predicate in one single name acting as the predicate symbol.

Does "SUPPLIERS" have a similar definition to the effect that "SUPPLIERS" supply all "potential" parts? If so, am I able to infer that all parts, current and potential, are provided by all suppliers? If so, then would not the answer to the query--quantified or not quantified--'Get suppliers who supply every ... part' simply be (by definition)?:

S {S#}

After all, there is nothing in the query about shipments! As worded, the query refers only to suppliers and parts, not shipments.

Somewhere along the way, the word "shipment" got included in the discussion. The suppliers and parts database has a relvar named SP and its [external] predicate says something like "<thisorthat supplier> supplies <thisorthat part> in <thisorthat quantity>". The relvar (and whatever relation it contains to represent the extension of that predicate) can be used to find the relation that is the extension of the predicate "<thisorthat supplier> supplies all parts" or "<thisorthat supplier> supplies all purple parts" if and only if the sense in which "supplies" is used in the latter two predicates is the very same sense as the one in which it is used in the former. No logic can ever be helpful in providing such guarantees, except perhaps in the sense that predicates "divide" "the world" in a set of objects that satisfy it and another set of objects that don't. So we could both enumerate our view of what that "division" (of the world in two sets of objects) looks like and see if it is identical or not. If so, we can conclude that we agree on the precise meaning of [all the words in] the predicate.

At some point, we always find ourselves left with only words as explained in the dictionary, and there's nothing but others words to attempt to arrive at such explanation. Given how blatantly obviously this mechanism "begs its own question", it's a miracle it works as well as it does. I sometimes use pink elephants as an example but using that example might sometimes also require that I explicitly specify that the small plastic toy my three-year old kid sometimes plays with, and which looks remarkably much like an elephant and is remarkably pink, does not qualify as a "pink elephant" nonetheless.

I suppose it was this I was referring to when I made that original remark you quoted.

(And no, according to me, the suppliers-and-parts database does not have a sense of "potential supplier" or "potential part" and I think most people who ever read "Introduction to Database Systems" would agree with that.)

Author of SIRA_PRISE

#22 · February 14, 2020, 10:17 pm

Yes. Here are the predicates according to my notes:

S: Supplier [S#] is named [SNAME] and has a status of [STATUS] and is located in city [CITY]

P: Part [P#] is named [PNAME] and has the colour [COLOR] and has a weight of [WEIGHT] and is made in city [CITY]

SP: Supplier [S#] has supplied part [P#] in a quantity of [QTY]

Nothing about future supplies or shipping, or any qualification about what suppliers can or might do.

Any query that strays too far from the strict wording of those predicates simply cannot be answered.

Andl - A New Database Language - andl.org

#23 · February 15, 2020, 12:38 pm

"... Does "SUPPLIERS" have a similar definition to the effect that "SUPPLIERS" supply all "potential" parts? If so, am I able to infer that all parts, current and potential, are provided by all suppliers? ..."

Sure, you can infer it. But a relational system as described in Codd 1970 is not allowed to make inferences, only implications.

For example, talk about "external predicates" is a tip-off that somebody has inferences in mind, not implications (aka "the old switcheroo").

But there is nothing to prevent a relational sub-language from treating conclusions of inferences that are explicitly supplied, as premises of an implication (which Codd explicitly allowed by accepting values of host functions).

Since (relational) formal implication cannot infer un-supplied values of inference premises, an inverse function between a relational premise and conclusion is not possible unless relational values of the inference premises accompany conclusion values (such as inferring operand values of an aggregate operator that is based on inductive inference).

#24 · February 15, 2020, 11:01 pm

That doesn't match my use of those words, or that of any dictionary I can find.

Inference: "The act or process of deriving logical conclusions from premises known or assumed to be true".

The results of a query are (or are the basis for) an inference, since the contents of the database are to be taken as true.

Andl - A New Database Language - andl.org

#25 · February 16, 2020, 8:16 am

Quote from p c on February 16, 2020, 8:16 am

Quote from dandl on February 15, 2020, 11:01 pm

That doesn't match my use of those words, or that of any dictionary I can find.

Inference: "The act or process of deriving logical conclusions from premises known or assumed to be true".

The results of a query are (or are the basis for) an inference, since the contents of the database are to be taken as true.

Whoever wrote that can't be referring to Codd's relational database model. He was clear that his operations are "noninferential". Just search the 1970 paper for that word.

For example, his natural join definition refers to truth only in the sense of a true material implication, it has no notion that assumes a "true" relation let alone "premises known or assumed to be true". (Such an assumption would mean that an empty database is not logically valid.)

Willful ignorance of the difference between inferential logic and the material implication of mathematical logic is rampant here and elsewhere. It doesn't need to be true that you must have apples and oranges before you can add them together. At the same time, nothing prevents the user or observer of relational behaviour from making inferences from relational conclusions.

Look at this paragraph from 1970:

"... The operations discussed below are specifically for relations. These operations are introduced because of their key role in deriving relations from other relations. Their principal application is in noninferential information systems-systems which do not provide logical inference services-although their applicability is not necessarily destroyed when such services are added."

"when such services are added" means that inferential services can be added by a host language, not the relational sub-language of a system, aka relational sub-system, for example non-first order functions.

"when such services are added" means that inferential services can be added by a host language, not the relational sub-language of a system, aka relational sub-system, for example non-first order functions.

Or google “difference between infer and imply” to see the poverty of everyday language word definitions.

Quote from dandl on February 15, 2020, 11:01 pm

That doesn't match my use of those words, or that of any dictionary I can find.

Inference: "The act or process of deriving logical conclusions from premises known or assumed to be true".

The results of a query are (or are the basis for) an inference, since the contents of the database are to be taken as true.

Whoever wrote that can't be referring to Codd's relational database model. He was clear that his operations are "noninferential". Just search the 1970 paper for that word.

For example, his natural join definition refers to truth only in the sense of a true material implication, it has no notion that assumes a "true" relation let alone "premises known or assumed to be true". (Such an assumption would mean that an empty database is not logically valid.)

Willful ignorance of the difference between inferential logic and the material implication of mathematical logic is rampant here and elsewhere. It doesn't need to be true that you must have apples and oranges before you can add them together. At the same time, nothing prevents the user or observer of relational behaviour from making inferences from relational conclusions.

Look at this paragraph from 1970:

"... The operations discussed below are specifically for relations. These operations are introduced because of their key role in deriving relations from other relations. Their principal application is in noninferential information systems-systems which do not provide logical inference services-although their applicability is not necessarily destroyed when such services are added."

"when such services are added" means that inferential services can be added by a host language, not the relational sub-language of a system, aka relational sub-system, for example non-first order functions.

Or google “difference between infer and imply” to see the poverty of everyday language word definitions.

#26 · February 16, 2020, 9:15 pm

Quote from dandl on February 15, 2020, 11:01 pm

That doesn't match my use of those words, or that of any dictionary I can find.

Inference: "The act or process of deriving logical conclusions from premises known or assumed to be true".

And to add insult to injury, some of those premises might be implications.

Both the insult and the injury is in the fact that this leaves the DBMS with only the possibility to make inferences, never implications.

Contrast that with "But a relational system as described in Codd 1970 is not allowed to make inferences, only implications.". Someone clearly misread something.

Author of SIRA_PRISE

#27 · February 16, 2020, 11:26 pm

The other point made in one of the references is that, if information flows from A to B, A implies and B infers. A 'makes the implication' and B 'draws the inference'. A asserts facts and stores them in a database, and by doing so may 'imply' information beyond what is stored. B queries those facts, and may 'imply' results beyond what is returned.

A asserts that supplier S has supplied certain parts, and implies that it is able to make further supplies in the future. B queries the supply of parts, and infers that further parts will be available, but that no-one can supply purple parts.

That's English usage. Of course maths and logic use these words slightly differently.

Andl - A New Database Language - andl.org

#28 · February 17, 2020, 7:41 am

Quote from dandl on February 16, 2020, 11:26 pm

The other point made in one of the references is that, if information flows from A to B, A implies and B infers. A 'makes the implication' and B 'draws the inference'. A asserts facts and stores them in a database, and by doing so may 'imply' information beyond what is stored. B queries those facts, and may 'imply' results beyond what is returned.

A asserts that supplier S has supplied certain parts, and implies that it is able to make further supplies in the future. B queries the supply of parts, and infers that further parts will be available, but that no-one can supply purple parts.

That's English usage. Of course maths and logic use these words slightly differently.

And to the extent our discussions belong to the domain of CS, and given that CS is rooted in maths and logic, what we should be sticking to here is of course the "slightly differently".

Author of SIRA_PRISE

#29 · February 17, 2020, 9:40 am

Sure thing. So would you care to comment on how that relates? I rather think it doesn't, but the floor is yours.

Andl - A New Database Language - andl.org

#30 · February 17, 2020, 5:02 pm

Quote from p c on February 17, 2020, 5:02 pm
A couple of links to what some logicians think about the difference between inference (inferential reasonng) and material implication:

https://people.ucalgary.ca/~rzach/blog/2005/04/inference-vs-implication.html

https://www.academia.edu/25014021/Inference_And_Implication

Note where the first link mentions "Deductive logic is a theory of what follows from what, not a theory of reasoning. It is a theory of deductive consequence. Deductive rules like (D) are absolutely universal rules, not default rules, they apply to any subject matter at all, and are not specifically principles about a certain process. Principles of reasoning are specifically principles about a particular process, namely reasoning. If there is a principle of reasoning that corresponds to (D), it holds only as a default principle, other things being equal."

An example of inferential reasoning aka non-deductive logic, is Hugh D's contribution to Appendix E of the DTATRM book. It claims that the predicate of a conjunction can't be negated because the sample schema has three different possible results. They happen to be disjoint implications of a conjunction, making such a negation ambiguous, ie. it can't be recorded/expressed by the chosen base relations.

For brevity, naming the base relations S and A, it is true that if the premise Not(S&A) is true, then the implication aka conclusion (( S And Not A) Or (Not S And A) Or (Not S And Not A)) is true. The implications is also a mutual implication meaning that the conclusion and premise can be reversed so in set terms an inverse function is also expressed.

However, the rationale assumes what it calls "possibilities" whose truth is not mutually implied when conclusions and premises are reversed. The reason is that it conflates the predicates of the conjuncts of S And A. It assumes that the predicate of the S conjunct is the predicate of the S variable, aka the old switcheroo. This is not always logically valid, that is, not always a universally true implication. The reason is that a premise is missing, namely that a conjunction always implies that its conjuncts are equal, they are mutually implied, aka logically equivalent in other words (S And A) implies that (S implies A) And (A implies S).

For example, (Not S And A) is said to be one of the possible conclusions. But (Not S And A) does not imply (S implies A And A implies S). Only one of the "possibilities" (Not S And Not A) implies that ((A implies S) And (S Implies A)) is universally true.

A noninferential aka deductive argument makes the premise of the mutual implication, aka equivalence or equality, a premise of the overall deduction argument, so that

(S<=>A) <=> ( Not(S&A) -> (S & Not A) ) is not a logically valid argument, not a valid implication.

A terse expression of the logically valid implication I like to use for the universally true possibility is (S=A) = -(S&A) = (-S & -A) because it can more easily be understood as an equation. Expressed by a truth table it is always true.

For a database to be logically complete the dbms has to apply deductive logic, ie. nothing can be concluded except what is logically implied by the base relations/premises, otherwise it is logically incomplete, second-order etc. Users can infer whatever they want.

A couple of links to what some logicians think about the difference between inference (inferential reasonng) and material implication:

https://people.ucalgary.ca/~rzach/blog/2005/04/inference-vs-implication.html

https://www.academia.edu/25014021/Inference_And_Implication

Note where the first link mentions "Deductive logic is a theory of what follows from what, not a theory of reasoning. It is a theory of deductive consequence. Deductive rules like (D) are absolutely universal rules, not default rules, they apply to any subject matter at all, and are not specifically principles about a certain process. Principles of reasoning are specifically principles about a particular process, namely reasoning. If there is a principle of reasoning that corresponds to (D), it holds only as a default principle, other things being equal."

An example of inferential reasoning aka non-deductive logic, is Hugh D's contribution to Appendix E of the DTATRM book. It claims that the predicate of a conjunction can't be negated because the sample schema has three different possible results. They happen to be disjoint implications of a conjunction, making such a negation ambiguous, ie. it can't be recorded/expressed by the chosen base relations.

For brevity, naming the base relations S and A, it is true that if the premise Not(S&A) is true, then the implication aka conclusion (( S And Not A) Or (Not S And A) Or (Not S And Not A)) is true. The implications is also a mutual implication meaning that the conclusion and premise can be reversed so in set terms an inverse function is also expressed.

However, the rationale assumes what it calls "possibilities" whose truth is not mutually implied when conclusions and premises are reversed. The reason is that it conflates the predicates of the conjuncts of S And A. It assumes that the predicate of the S conjunct is the predicate of the S variable, aka the old switcheroo. This is not always logically valid, that is, not always a universally true implication. The reason is that a premise is missing, namely that a conjunction always implies that its conjuncts are equal, they are mutually implied, aka logically equivalent in other words (S And A) implies that (S implies A) And (A implies S).

For example, (Not S And A) is said to be one of the possible conclusions. But (Not S And A) does not imply (S implies A And A implies S). Only one of the "possibilities" (Not S And Not A) implies that ((A implies S) And (S Implies A)) is universally true.

A noninferential aka deductive argument makes the premise of the mutual implication, aka equivalence or equality, a premise of the overall deduction argument, so that

(S<=>A) <=> ( Not(S&A) -> (S & Not A) ) is not a logically valid argument, not a valid implication.

A terse expression of the logically valid implication I like to use for the universally true possibility is (S=A) = -(S&A) = (-S & -A) because it can more easily be understood as an equation. Expressed by a truth table it is always true.

For a database to be logically complete the dbms has to apply deductive logic, ie. nothing can be concluded except what is logically implied by the base relations/premises, otherwise it is logically incomplete, second-order etc. Users can infer whatever they want.

TTM Forum

The Forum for Discussion about The Third Manifesto and Related Matters