 | |
#41
 
| |||
| |||
|
Re: compound propositions -
03-19-2010
, 04:01 PM
|
D&D aren't exactly the focal point of database theory either. Speaking of terminology, can you remind me again what or whom exactly |
assign a spatial/relative location to a scientist into a scientific
universe of discourse ?
A question always comes back to my mind: Why do we always have to
resort to mystical terminology when dealing with science ? Is this a
curse ? Is database theory doomed to remain in utter infancy. Can't
we just turn alchemy into chemistry once and for all.
#42
| |||
| |||
|
|
Snipped D&D aren't exactly the focal point of database theory either. Speaking of terminology, can you remind me again what or whom exactly is the/a *focal point* of database theory? And by whose logic does one assign a spatial/relative location to a scientist into a scientific universe of discourse ? |
scientists, and mathematics is not a science. Your terminology may vary.
I was just trying to make the point that how we define things
doesn't necessarily coincide with how we name them. Of course
it's very helpful to have consistent terminology.
Quote:
|
A question always comes back to my mind: Why do we always have to resort to mystical terminology when dealing with science ? Is this a curse ? Is database theory doomed to remain in utter infancy. Can't we just turn alchemy into chemistry once and for all. |
explanations of the relationship between database theory and practice
and why theory matters. But theory they are not, and I'm sure Date
would agree.
--
Reinier
#43
| |||
| |||
|
|
Some months ago Bob B took me to task for language that might have been too loose or even glib, referring to predicates and expressions. That was fair enough. Though I could've made it clearer that by expressions I meant relational algebra expressions, I still don't have clear answers to all of his complaint. One reason is that I still don't know how Codd's Information Principle applies to compound propositions, eg., " 'C1' is a customer OR 'C1' is a client". I can see that humans might imagine themselves capable of interpreting a relation (or to put it redundantly a relation value) as implitly mentioning that 'OR' connective (and dba's might so instruct their users). But where is it recorded? (or 'manifested'?) Eg., is it 'recorded' only in the ephemeral form of an expectation that a program's execution can't manifest given a single relation to operate on? |
record a disjunction, information is inherently missing: it is known that at
least one disjunct is supposed to be true, but not which.
I think that if you recast what you intend in terms of nulls, and then seek
to eliminate those nulls, you'll find that the resulting scheme doesn't
involve the recording of disjunctive information.
On the other hand, you could find what it is that is in common between the
disjuncts. Both customers and clients are payors, for example.
Quote:
|
As far as I can tell, there is no way to record a logical connective in a tuple, therefore not for a tuple and therefore not in a relational value (other than in a disconnected text mode thath isn't amenable to the algebra) which has always made me suspect that Codd's R-tables don't store compound propositions. If so, that would be one difference between internal and external predicates, which would make me suspect that we can't always expect the same results when the same algebra is applied to both. (I realize that Codd and others - maybe Ullman, I forget - showed that FOL and his relational algebra were equivalent, but I presume the conditions of that were with reference to his R-tables and not that FOL always gives the same results under all conditions.) |
#44
| |||
| |||
|
|
"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:XEvnn.71100$PH1.31420 (AT) edtnps82 (DOT) .. .... One reason is that I still don't know how Codd's Information Principle applies to compound propositions, eg., " 'C1' is a customer OR 'C1' is a client". I can see that humans might imagine themselves capable of interpreting a relation (or to put it redundantly a relation value) as implitly mentioning that 'OR' connective (and dba's might so instruct their users). But where is it recorded? (or 'manifested'?) Eg., is it 'recorded' only in the ephemeral form of an expectation that a program's execution can't manifest given a single relation to operate on? I'm confused. Are you trying to find a way to avoid using nulls? ... |
coherently I do have a comment about 'avoiding nulls' and no offense
intended - the phrase seems so unfortunate to me, as if it means some
kind of detour or deviation from orthodoxy. Not unlike how so many
expressions in other fields sooner or later acquire the opposite meaning
from the original. I suppose 'avoiding nonsense' covers the same
intended ground but bothering to keep either figment constantly in mind
seems a waste of time to me. I suppose there are purists in all fields
who feel a need to rebut every cockamamie nuance spouted by half-assed
practitioners.
#45
| |||
| |||
|
|
Mr. Scott wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:XEvnn.71100$PH1.31420 (AT) edtnps82 (DOT) .. ... One reason is that I still don't know how Codd's Information Principle applies to compound propositions, eg., " 'C1' is a customer OR 'C1' is a client". I can see that humans might imagine themselves capable of interpreting a relation (or to put it redundantly a relation value) as implitly mentioning that 'OR' connective (and dba's might so instruct their users). But where is it recorded? (or 'manifested'?) Eg., is it 'recorded' only in the ephemeral form of an expectation that a program's execution can't manifest given a single relation to operate on? I'm confused. Are you trying to find a way to avoid using nulls? ... No, I didn't have that in mind. Until I can put the question more coherently I do have a comment about 'avoiding nulls' and no offense intended - the phrase seems so unfortunate to me, as if it means some kind of detour or deviation from orthodoxy. Not unlike how so many expressions in other fields sooner or later acquire the opposite meaning from the original. I suppose 'avoiding nonsense' covers the same intended ground but bothering to keep either figment constantly in mind seems a waste of time to me. I suppose there are purists in all fields who feel a need to rebut every cockamamie nuance spouted by half-assed practitioners. |
of disjunctive information in neat tabular format.
#46
| |||
| |||
|
|
"paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:2oprn.364$Z6.28 (AT) edtnps82 (DOT) .. Mr. Scott wrote: "paul c" <toledobythesea (AT) oohay (DOT) ac> wrote in message news:XEvnn.71100$PH1.31420 (AT) edtnps82 (DOT) .. ... One reason is that I still don't know how Codd's Information Principle applies to compound propositions, eg., " 'C1' is a customer OR 'C1' is a client". I can see that humans might imagine themselves capable of interpreting a relation (or to put it redundantly a relation value) as implitly mentioning that 'OR' connective (and dba's might so instruct their users). But where is it recorded? (or 'manifested'?) Eg., is it 'recorded' only in the ephemeral form of an expectation that a program's execution can't manifest given a single relation to operate on? I'm confused. Are you trying to find a way to avoid using nulls? ... No, I didn't have that in mind. Until I can put the question more coherently I do have a comment about 'avoiding nulls' and no offense intended - the phrase seems so unfortunate to me, as if it means some kind of detour or deviation from orthodoxy. Not unlike how so many expressions in other fields sooner or later acquire the opposite meaning from the original. I suppose 'avoiding nonsense' covers the same intended ground but bothering to keep either figment constantly in mind seems a waste of time to me. I suppose there are purists in all fields who feel a need to rebut every cockamamie nuance spouted by half-assed practitioners. Nulls are not nonsense. They're merely a device that permits the recording of disjunctive information in neat tabular format. |
SUM(A) + SUM(B) = SUM(A+B)
create table tablewithnulls(A integer, B integer)
insert into tablewithnulls values(1,NULL)
insert into tablewithnulls values(NULL,2)
insert into tablewithnulls values(3,4)
select SUM(A) from tablewithnulls -- 4
select SUM(B) from tablewithnulls -- 6
select SUM(A+B) from tablewithnulls -- 7 != 4+6
#47
| |||
| |||
|
|
On Mar 30, 10:59 am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote: Mr. Scott wrote: Nulls are not nonsense. They're merely a device that permits the recording of disjunctive information in neat tabular format. Explain how that requires breaking useful identies like SUM(A) + SUM(B) = SUM(A+B) create table tablewithnulls(A integer, B integer) insert into tablewithnulls values(1,NULL) insert into tablewithnulls values(NULL,2) insert into tablewithnulls values(3,4) select SUM(A) from tablewithnulls -- 4 select SUM(B) from tablewithnulls -- 6 select SUM(A+B) from tablewithnulls -- 7 != 4+6 I think under Zaniolo's no-information interpretation of NULL, tablewithnulls can be regarded as simultaneously encoding the following relations without NULLs: A --- 1 3 B --- 2 4 A' B' ------ 3 4 Note the following: SUM(A) = 4 SUM(B) = 6 SUM(A') = 3 SUM(B') = 4 SUM(A'+B') = 7 SUM(A') + SUM(B') = SUM(A'+B') |
(ie. no null and no duplicates) while preserving the identity. Good to know.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.