Is a function a relation?
David BL
question of whether a function is a relation (I have a small point to
add).
I'm interpreting "is a" in the same way as D&D. i.e. the question is
equivalent to asking whether every function value is a relation value.
D&D use the CIRCLE and ELLIPSE example to illustrate the idea of type
inheritance as specialisation by constraint. CIRCLE is a subtype of
ELLIPSE because every value of type CIRCLE is also a value of type
ELLIPSE.
Let E be a variable of type ELLIPSE that happens to hold a value of
type CIRCLE. D&D mention that THE_R(E) is not permitted, and it is
necessary to instead use THE_R(TREAT_DOWN_AS_CIRCLE(E)). Implicit in
this idea is that when an ellipse value happens to also be a circle
value, the interpretation of the ellipse as a circle is unambiguous.
Consider the binary relation with the following graph
{ (x,y) | y = x+1 }
and the following two functions
f(x) = x+1
g(y) = y-1
It seems to me that assuming D&D's interpretation of "is a", it cannot
be said that a function is a relation because TREAT_DOWN_AS_FUNCTION
is ambiguous when provided with a relation variable that holds the
value f.
David BL
> Consider the binary relation with the following graph
>
> { (x,y) | y = x+1 }
>
I neglected an important assumption: As is customary in the database
community, it is assumed that the attributes of a relation are
identified by name, not by ordinal position (i.e. despite my use of
ordered pairs above - which was for only for convenience).
I should have instead defined the body of the relation as:
{ t | t('y') = t('x') + 1 }
where each t is a tuple, formalised as a mapping from attribute name
to attribute value.
Keith H Duggar
You considered the wrong relation values having the wrong
attribute names. Here are the correct values
f(x) = x+1 -> { (domain,range) | range = domain + 1 }
g(y) = y+1 -> { (domain,range) | range = domain - 1 }
corresponding to the f(x) and g(y) you gave.
KHD
David BL
>
> You considered the wrong relation values having the wrong
> attribute names. Here are the correct values
>
> f(x) = x+1 -> { (domain,range) | range = domain + 1 }
> g(y) = y+1 -> { (domain,range) | range = domain - 1 }
>
> corresponding to the f(x) and g(y) you gave.
So you're suggesting that a function is a relation where a special
convention has been followed in the choice of attribute names? Yes
that's one way of looking at it. That would in fact suggest the
interesting idea that one can use the RA to define functions. E.g.
start with some n-ary relation and use projection to get a binary
relation, and rename as required according to this special naming
convention.
David BL
> Yes that's one way of looking at it.
I'll expand on what I mean by that. It seems to me that one could use
special conventions to "show" that just about any type can be regarded
as a specialisation of a relation. E.g. one could say that a whole
number in [0,255] is a relation by introducing symbols to represent
1,2,4,8,...,128 and the relation records a set of symbols that are
then interpreted in the manner of an 8 bit unsigned representation.
Cimode
are to consider that a type is a set of values. Nevertherless, a
logical computing model (to define among other things the physical
reprentation of domain values) must be defined first (that is what I
spent the last 10 years working onto)...Hope this helps...
David BL
It could be thought that the logical can only exist as an abstraction
over the physical. However I don't believe that's a useful way to
think. In fact I suggest it misses the idea behind physical
independence. What I mean is that the logical doesn't need to be
"realised" or "reified" by the physical at all!
This could be seen as just a metaphysical comment (more specifically
in favour of mathematical realism), but what I really mean is that
pure mathematical systems can for example define things like the
integers in a way that's unique up to isomorphism through the
axiomatic approach, and that perspective is all one needs at the
logical level. I don't see how the physical comes into it at all.
Putting it another way (using the language of a mathematical realist
in denial), database values don't exist in time and space!
It's not clear that type systems particularly help in this purist
mathematical endeavour. I note that the usual axioms of set theory
completely ignore any concept of type. I'd be interested to know
whether modern mathematicians that have researched type theory believe
it's important to mathematical foundations. My understanding is that
Russell only investigated type theory with the aim to avoid paradoxes
by preventing loops, but his work was made redundant by axiomatic
systems like ZFC which is believed to be free of paradoxes.
Cimode
The problem of achieving physical/logical independence under the
assumption of RMis far more complex than a simple taxonomy exercice.
The need for a specialized computing model is a prerequisite for
implementing relational logical operations.
The computing model must both take into considerations physical
limitations of current systems while allowing sound representation of
logical relational operations.
> I note that the usual axioms of set theory
> completely ignore any concept of type. I'd be interested to know
> whether modern mathematicians that have researched type theory believe
> it's important to mathematical foundations. My understanding is that
> Russell only investigated type theory with the aim to avoid paradoxes
> by preventing loops, but his work was made redundant by axiomatic
> systems like ZFC which is believed to be free of paradoxes.
RM is a part of set theory. Domains are in fact types that are
defined in a naive way.
Brian Selzer
"David BL" <dav...@iinet.net.au> wrote in message
news:09f7bd9a-76f9-47c3...@m19g2000yqk.googlegroups.com...
I think that it is not names but roles. Instead of domain and range, think
determinant and dependent. A function is a relation that has defined in its
schema at least one dependent attribute that does not belong to all
determinants. Put it another way: a function is a relation that satisfies
at least one nontrivial functional dependency.
Brian Selzer
"Brian Selzer" <br...@selzer-software.com> wrote in message
news:PX30m.509$kA....@nlpi068.nbdc.sbc.com...
After thinking about this for a moment, I realized that I neglected to
consider pathological cases, such as relations that are not at least in 3NF.
So, with that qualification: a function is a 3NF relation that has defined
in its schema at least one dependent attribute that does not belong to all
determinants; a function is a 3NF relation that satisfies at least one
nontrivial functional dependency.
Brian Selzer
Scratch that. Due to the augmentation inference rule for functional
dependencies, even pathological relations are functions whenever they each
satisfy at least one nontrivial functional dependency. I'm really finding
it difficult to state that without using the term 'functional' and without
rehashing the definition of a functional dependency, but I should hope that
by now you get the gist of what I'm saying.
Marshall
Note that downcasting is a partial function that may succeed or fail
at runtime.
If we treat the attributes of a function uniformly, we lose the
distinction
between input and output attributes. If we lose that distinction, then
try to get it back, it may be the case that we cannot do so uniquely.
A particularly familiar and yet complex case is the "+" relation:
+: a, b -> c
Every nonempty partition of the attributes specifies a function
a, b -> c
b, c -> a
a, c -> b
We can go further and consider the whole thing a predicate:
a, b, c ->? ()
Note how much this looks like functional dependencies.
It is my considered opinion that we ought to have these
distinctions present in the type system, because they are
ideal candidates for static analysis.
Marshall
Marshall
That's a fine way to go. SML goes that way. But there
are other ways to go, and as well as that way works for
SML, I think a relational language is going to best be
served by a different approach.
Marshall
Marshall
That's possible, but I think the better approach is to keep
function attributes at the same level of nesting as is done
with relation attributes: at the top wherever possible.
Consider the case of composition. It gets quite complicated!
But the complication is all on the shoulders of the type system
implementer. The programmer will be much happier that
way than if we introduce nesting and special conventions, etc.
Marshall
Marshall
Heh. Yes, there is a bijection between the natural numbers and
bit strings. But the tricky thing is, bit strings are strings, which
is
to say they are lists, which is to say they are indexed by natural
numbers.
Axiomatic set theory just uses sets. And I mean it *really*
just uses sets; there are no other kinds of objects in that
universe. Natural numbers are encoded as sets. Everything
is encoded as sets. If you have a set, every member of the
set is itself a set.
Not my favorite way of thinking about the world, but it's
mathematically sound.
Marshall
Marshall
>
> It's not clear that type systems particularly help in this purist
> mathematical endeavour.
My sense is that it doesn't.
> I note that the usual axioms of set theory
> completely ignore any concept of type. I'd be interested to know
> whether modern mathematicians that have researched type theory believe
> it's important to mathematical foundations. My understanding is that
> Russell only investigated type theory with the aim to avoid paradoxes
> by preventing loops, but his work was made redundant by axiomatic
> systems like ZFC which is believed to be free of paradoxes.
Certainly Russel's paradox is easily avoided by using a restricted
form of comprehension. However every time I see it suggested
that that was a particular motivation for Russel's work, it gets
laughed at by those more in the know about math history.
An interesting paper on the question, which I bet you will
like:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.7134
Anything by Leslie Lamport is worth reading. Even if he
often flies way over my head.
Marshall
Marshall
Oh, and don't forget that we probably need different treatment
for total vs. partial functions, and we'd probably also like to
get in catamorphisms/generators/multifunctions (or whatever
you want to call them) and also anamorphisms/folds/stream
functions. And consider that a predicate is a restricted form
of multifunction that we probably also want special treatment
for.
Be sure your types system handles all of these, and all
possible compositions of these, soundly.
Don't forget that if your stream function is a fold of a
binary function that is both commutative and associative,
("in AC") you can compose it with an extensional relation
nicely, but if the function is not in AC, then composing
it with a relation introduces nondeterminism!
Whee!
Marshall
Brian Selzer
While I would agree that the physical representation of the symbols and
combinations of symbols that compose formal language terms is irrelevant, if
what is in the Universe of Discourse can exist in time and space, then
database values can exist in time and space. A value is the result of
applying for a given term the valuation function which maps terms expressed
in a formal language to things in the Universe of Discourse under an
interpretation. So from one point of view, a value /is/ the thing in the
Universe referred to by a given term, but just at the instant of
interpretation. More importantly, if the micro-world that the database is
supposed to model includes things than can occupy a locus in time and/or
space, then the language, the logic and the intended interpretation must
reflect that; however, correct me if I'm wrong, but isn't a pure
mathematical system composed entirely of abstract objects, and aren't
abstract objects by definition not located in time or space and thus not
subject to change? How, then, can a pure mathematical system be a
sufficient logical model for things that can change?
David BL
>
> An interesting paper on the question, which I bet you will
> like:
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.7134
>
> Anything by Leslie Lamport is worth reading. Even if he
> often flies way over my head.
Thanks for the link. Ah yes I've come across this guy before. I
liked his paper on logical clocks and ordered events in a distributed
system.
David BL
>
> While I would agree that the physical representation of the symbols and
> combinations of symbols that compose formal language terms is irrelevant, if
> what is in the Universe of Discourse can exist in time and space, then
> database values can exist in time and space. A value is the result of
> applying for a given term the valuation function which maps terms expressed
> in a formal language to things in the Universe of Discourse under an
> interpretation.
I prefer to consider the RM as a pure mathematical formalism divorced
from "interpretations" (i.e. external predicates and so forth).
> How, then, can a pure mathematical system be a
> sufficient logical model for things that can change?
It is true that a single database value cannot model things that can
change (into the future). However database systems are variables not
values.
David BL
Tegiri Nenashi
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.7134
On page 7:
"...even defining division by zero to yield zero..."
This prompted the following definition:
"Computer science is a branch of applied mathematics that defines
division by zero to yield zero"
Cimode
It looks like a typo.
Brian Selzer
> On Jun 24, 12:44 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
>>
>> While I would agree that the physical representation of the symbols and
>> combinations of symbols that compose formal language terms is irrelevant,
>> if
>> what is in the Universe of Discourse can exist in time and space, then
>> database values can exist in time and space. A value is the result of
>> applying for a given term the valuation function which maps terms
>> expressed
>> in a formal language to things in the Universe of Discourse under an
>> interpretation.
>
> I prefer to consider the RM as a pure mathematical formalism divorced
> from "interpretations" (i.e. external predicates and so forth).
I can't see how that is even possible, since the extension of a predicate,
regardless of whether it is internal or external, is a collection of atomic
formulae, each of which must be judged to be true or false under an
interpretation. Under the Closed World Interpretation, only those atomic
formulae that are judged to be true are represented, but the judgement must
still be made, and that requires the assignment of meaning to each term in
each atomic formula. I am not saying that the assignment of meaning and the
judgement of truth which are the constituents of interpretation should not
be isolated, but I think it is a gross oversimplification to deny that they
play a part altogether in relational database theory.
Marshall
The author of the paper was talking about someone else's system,
and I don't think this was an endorsement of it.
I don't see how forcing every function to be total is a workable plan,
although it does appeal to some people.
Marshall
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
>
> > I prefer to consider the RM as a pure mathematical formalism divorced
> > from "interpretations" (i.e. external predicates and so forth).
>
> I can't see how that is even possible, since the extension of a predicate,
> regardless of whether it is internal or external, is a collection of atomic
> formulae, each of which must be judged to be true or false under an
> interpretation. Under the Closed World Interpretation, only those atomic
> formulae that are judged to be true are represented, but the judgement must
> still be made, and that requires the assignment of meaning to each term in
> each atomic formula. I am not saying that the assignment of meaning and the
> judgement of truth which are the constituents of interpretation should not
> be isolated, but I think it is a gross oversimplification to deny that they
> play a part altogether in relational database theory.
What I mean is that one shouldn't confuse pure mathematical systems
such as set theory with how they are applied in the real world.
A mathematical relation as just a set of tuples.
I agree that the topic of interpretation is relevant to database
theory.
Brian Selzer
But a database relation is not the same thing as a mathematical relation.
The difference may not be immediately obvious--and I'm not referring to the
fact that components of tuples in a database relation are named whereas
components of tuples in a mathematical relation are indexed. The difference
is in how the relations are arrived at, and the extent to which they endure.
In the case of a database relation, the predicate is extended and each
atomic formula is judged to be either true or false at the instant of
interpretation, but in the case of a mathematical relation, the predicate is
extended and there is no need to judge whether each atomic formula is true
or false because owing to the fact that whenever there is a particular
abstract object, it is necessary that there is that particular abstract
object, each atomic formula in the extension of a mathematical relation is
true necessarily. So for mathematical relations, one can safely dispense
with judging the truths of the atomic formulae represented by tuples. Also,
the assignment of meaning to terms in the atomic formulae in the extension
of mathematical relations can be deferred because abstract objects neither
come into existence, change in appearance nor cease to exist. It is
tempting, therefore, to treat database relations as mathematical relations,
and one safely can for activities or specifications that involve just one
instance at a time, such as queries or the specification of referential
constraints, but the danger in expanding the scope of activities or
specifications so that they involve more than one instance at a time, as is
the case for updates, is that there would be more than one assignment of
meaning and more than one judgement of truth for the same activity.
Cimode
theorist has allowed to establish a fundamental link between set
theory and algebra. Unfortunately, the established formalization
remains limitative to the expressive power of mathematical relations:
they did not even bother establish valid quantifiers. In that
perspective, relational formalization is to revised while keeping its
axiomatic definitions and get back to its mathetical fundamentals.
David BL
I don't know what that means, so I'll ask some questions to try to
establish a common point of reference!
* Do you draw a distinction between a relation variable and a
relation value?
* Do you think it's possible to talk about the relation value
recorded in a relation variable in a particular database at a
particular time?
* Is a relation value necessarily associated with some external
predicate?
* What is the definition of equivalent relation values?
* Do you think it's possible to say that distinct relation variables
(possibly in distinct databases) happen to have recorded the same
relation value at particular times - even though the relation
variables have distinct external predicates?
Brian Selzer
Of course, but I think in terms of relation schemata instead of relation
variables. Date and Darwen's databases_as_collections_of_relvars paradigm
presupposes assignment as the only mechanism for implementing database
updates. Relation schemata serve the same purpose as relation variables but
without the baggage of assuming an implementation methodology.
> * Do you think it's possible to talk about the relation value
> recorded in a relation variable in a particular database at a
> particular time?
I'm not sure what you're asking here. A database is a set of relations that
conforms to the database schema. The state constraints specified on the
schema determine the set of all possible databases. Only one possible
database can actually be /the database/ at any given point in time. It
should be possible to talk about any relation in any database at any time.
That's why I don't understand your question.
> * Is a relation value necessarily associated with some external
> predicate?
If I understand correctly what you mean by 'external predicate,' then the
answer is a qualified 'yes.' Each and every value is the result of applying
the valuation function to a term under an interpretation at the instant of
interpretation. For things that cannot change, such as mathematical
objects, that function application yields the same result at every instant
of interpretation, and as a consequence of that being taken for granted,
values are often incorrectly treated as being equivalent to the symbols or
compositions of symbols that are terms in a formal language. The problem is
that for things that can change, a particular composition of symbols can
mean different things at different times. For example, the phrase, "the guy
in the red t-shirt and blue baseball cap" may describe different guys at
different times, even though in each given context it is sufficient to
identify a particular guy. So since relations are values, they are each
extensionally the result of applying the valuation function to a distinct
composition of symbols under an interpretation at the instant of
interpretation, and therefore are associated with both the interpetation and
the instant of interpretation.
> * What is the definition of equivalent relation values?
In what context?
> * Do you think it's possible to say that distinct relation variables
> (possibly in distinct databases) happen to have recorded the same
> relation value at particular times - even though the relation
> variables have distinct external predicates?
A relation is a named set of sets of named values. The name of a relation
is significant and should, I think, preclude it from being recorded in
distinct relation variables. Also, one cannot assume that the name given to
a domain defined in one database schema would be identical to the name given
to the same domain in another database schema, so there is no common frame
of reference in order to compare relations in databases that conform to
different database schemata. In the case of ETL applications, the frame of
reference is supplied in the form of a schema mapping between systems.
David BL
>
> I agree that the topic of interpretation is relevant to database
> theory.
I'll take that back. I would rather narrow the term "database theory"
to a pure mathematical discipline, and therefore instead say that
interpretation is only relevant to the practical application of
database theory.
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
>
> > relation value?
>
> Of course, but I think in terms of relation schemata instead of relation
> variables. Date and Darwen's databases_as_collections_of_relvars paradigm
> presupposes assignment as the only mechanism for implementing database
> updates. Relation schemata serve the same purpose as relation variables but
> without the baggage of assuming an implementation methodology.
If a database system records relations, then there are relation
variables. I fail to see how you can deny that. It follows from the
definition of 'variable'. Also when a variable changes then by
definition it has been reassigned. I don't see how that assumes any
implementation methodology. Definitions in themselves don't imply
anything at all.
> > * Do you think it's possible to talk about the relation value
> > recorded in a relation variable in a particular database at a
> > particular time?
>
> I'm not sure what you're asking here. A database is a set of relations that
> conforms to the database schema. The state constraints specified on the
> schema determine the set of all possible databases. Only one possible
> database can actually be /the database/ at any given point in time. It
> should be possible to talk about any relation in any database at any time.
> That's why I don't understand your question.
I find many things you say very confusing. A database... all posible
databases...one possible database...the database...any database. What
do you mean by the word 'database'?
I distinguish between a database type (aka database schema), database
variable (aka physical database system with named relvars) and
database value (aka tuple with RVAs).
I was talking about the idea of there being a value of a given
relation variable in a given database system at a given time.
> > * Is a relation value necessarily associated with some external
> > predicate?
>
> If I understand correctly what you mean by 'external predicate,' then the
> answer is a qualified 'yes.'
Well I think the answer is 'no'.
> Each and every value is the result of applying
> the valuation function to a term under an interpretation at the instant of
> interpretation. For things that cannot change, such as mathematical
> objects, that function application yields the same result at every instant
> of interpretation, and as a consequence of that being taken for granted,
> values are often incorrectly treated as being equivalent to the symbols or
> compositions of symbols that are terms in a formal language. The problem is
> that for things that can change, a particular composition of symbols can
> mean different things at different times. For example, the phrase, "the guy
> in the red t-shirt and blue baseball cap" may describe different guys at
> different times, even though in each given context it is sufficient to
> identify a particular guy. So since relations are values, they are each
> extensionally the result of applying the valuation function to a distinct
> composition of symbols under an interpretation at the instant of
> interpretation, and therefore are associated with both the interpetation and
> the instant of interpretation.
We have different definitions of the term 'value'. I use it (only) to
mean an abstract, well defined mathematical object like a particular
integer, completely divorced from any appearance of that value (such
as being used to record someone's age).
When you say a value means different things at different times it
seems like you're thinking a value is what C.Date calls an appearance
of a value, which actually has more to do with a variable that exists
in time and space.
> > * What is the definition of equivalent relation values?
>
> In what context?
>
> > * Do you think it's possible to say that distinct relation variables
> > (possibly in distinct databases) happen to have recorded the same
> > relation value at particular times - even though the relation
> > variables have distinct external predicates?
>
> A relation is a named set of sets of named values. The name of a relation
> is significant and should, I think, preclude it from being recorded in
> distinct relation variables.
I don't consider relation values to have names.
> Also, one cannot assume that the name given to
> a domain defined in one database schema would be identical to the name given
> to the same domain in another database schema, so there is no common frame
> of reference in order to compare relations in databases that conform to
> different database schemata. In the case of ETL applications, the frame of
> reference is supplied in the form of a schema mapping between systems.
When the integer value 5 is encoded in various databases around the
world, do you consider that it is the same integer being recorded?
Joe Thurbon
There may be some talking at cross purposes here.
I had assumed that when database theoreticians talked about
interpretations they were talking about something similar to what
logicians call an interpretation (or interpretation function, depending on
what you're reading). In logic, an interpretation is very much a
mathematical construct (c.f. model theory).
(I've just received my mail-order of Date's Logic and Databases, so
hopefully soon I'll be able to confirm or deny the above assumption.)
What are you talking about when you say interpretation?
Cheers,
Joe
David BL
I completely agree that an interpretation in model theory is a
mathematical construct. I don't believe Brian was using the word
interpretation in that sense, because he spoke about a UoD that can
exist in time and space. His words:
"... if what is in the Universe of Discourse can
exist in time and space, then database values can
exist in time and space. A value is the result of
applying for a given term the valuation function
which maps terms expressed in a formal language to
things in the Universe of Discourse under an
interpretation."
I assumed he was talking about the idea to interpret mathematical
relations as predicates that apply to the real world. i.e. external
predicates.
As C.Date says:
"... while internal predicates are a formal
construct, external predicates are an informal
construct merely. Internal predicates are (loosely)
what the data means to the DBMS; external
predicates, by contrast, are what the data means
to the user."
An external predicate, being informal, is typically stated in natural
language.
Brian Selzer
> On Jun 27, 2:22 am, "Brian Selzer" <br...@selzer-software.com> wrote:
>> "David BL" <davi...@iinet.net.au> wrote in message
>>
>> > * Do you draw a distinction between a relation variable and a
>> > relation value?
>>
>> Of course, but I think in terms of relation schemata instead of relation
>> variables. Date and Darwen's databases_as_collections_of_relvars
>> paradigm
>> presupposes assignment as the only mechanism for implementing database
>> updates. Relation schemata serve the same purpose as relation variables
>> but
>> without the baggage of assuming an implementation methodology.
>
> If a database system records relations, then there are relation
> variables. I fail to see how you can deny that. It follows from the
> definition of 'variable'. Also when a variable changes then by
> definition it has been reassigned. I don't see how that assumes any
> implementation methodology. Definitions in themselves don't imply
> anything at all.
I think you are afflicted with tunnel vision. A database system does not
just record relations in isolation. If anything it records entire
databases, one at a time, each of which just happens to be a set of
relations. But a database system need not even record databases at all: it
could instead record just the differences between successive databases,
which when accumulated can be presented as a set of relations. None of
these implementation methodologies involve the use of relation variables.
The latter does not even hint at assignment, since it involves appending to
and accumulating a stream of assertions to arrive at the current set of
relations, though it is conceivable that intermediate results could be
cached under the covers in order to improve query performance.
>
>> > * Do you think it's possible to talk about the relation value
>> > recorded in a relation variable in a particular database at a
>> > particular time?
>>
>> I'm not sure what you're asking here. A database is a set of relations
>> that
>> conforms to the database schema. The state constraints specified on the
>> schema determine the set of all possible databases. Only one possible
>> database can actually be /the database/ at any given point in time. It
>> should be possible to talk about any relation in any database at any
>> time.
>> That's why I don't understand your question.
>
> I find many things you say very confusing. A database... all posible
> databases...one possible database...the database...any database. What
> do you mean by the word 'database'?
A database is a set of relations that conforms to a given database schema.
Don't you agree that the database schema defines the set of all valid
databases? Don't you also agree that of all valid databases, only one
database at a time can be the current database? Is it my use of the terms
'possible' and 'actual' that has you confused?
Abstract, well defined mathematical objects cannot change, so a formalism
that admits only abstract, well defined mathematical objects cannot be used
to model things that can change.
> When you say a value means different things at different times it
> seems like you're thinking a value is what C.Date calls an appearance
> of a value, which actually has more to do with a variable that exists
> in time and space.
Please don't misrepresent me: I didn't say that a value means different
things at different times; I said that a term in a formal language can mean
different things at different times.
Also, a variable is a container for a value. How can it exist in time and
space?
>
>> > * What is the definition of equivalent relation values?
>>
>> In what context?
>>
>> > * Do you think it's possible to say that distinct relation variables
>> > (possibly in distinct databases) happen to have recorded the same
>> > relation value at particular times - even though the relation
>> > variables have distinct external predicates?
>>
>> A relation is a named set of sets of named values. The name of a
>> relation
>> is significant and should, I think, preclude it from being recorded in
>> distinct relation variables.
>
> I don't consider relation values to have names.
That doesn't surprise me. I suppose that you would attribute the same
meaning to a relation that is constructed by explicitly stating the heading
and tuples, as a relation consisting of the exact same set of tuples that is
the result of a union of two relations in the database?
>> Also, one cannot assume that the name given to
>> a domain defined in one database schema would be identical to the name
>> given
>> to the same domain in another database schema, so there is no common
>> frame
>> of reference in order to compare relations in databases that conform to
>> different database schemata. In the case of ETL applications, the frame
>> of
>> reference is supplied in the form of a schema mapping between systems.
>
> When the integer value 5 is encoded in various databases around the
> world, do you consider that it is the same integer being recorded?
Yes, provided it is understood that the integer domain is common to all of
those databases.
Brian Selzer
I think your assumption is faulty. I merely claim that there can be things
that can change--that is, that there can be objects that can exemplify
different properties at different times. Obviously, if one seeks to discuss
such objects, they must be included in the Universe of Discourse.
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
>
>
> > variables. I fail to see how you can deny that. It follows from the
> > definition of 'variable'. Also when a variable changes then by
> > definition it has been reassigned. I don't see how that assumes any
> > implementation methodology. Definitions in themselves don't imply
> > anything at all.
>
> I think you are afflicted with tunnel vision. A database system does not
> just record relations in isolation. If anything it records entire
> databases, one at a time, each of which just happens to be a set of
> relations. But a database system need not even record databases at all: it
> could instead record just the differences between successive databases,
> which when accumulated can be presented as a set of relations. None of
> these implementation methodologies involve the use of relation variables.
> The latter does not even hint at assignment, since it involves appending to
> and accumulating a stream of assertions to arrive at the current set of
> relations, though it is conceivable that intermediate results could be
> cached under the covers in order to improve query performance.
You're ignoring the idea of physical independence.
The definition of 'variable' (relevant to this discussion) doesn't
constrain physical implementation choices in any way. The sense in
which a variable is deemed to hold a value can be arbitrarily
indirect, and for example may involve physical storage of deltas.
Here are some other aspects of physical independence:
* Both base relvars and derived relvars are variables. This
distinction (which is a curious one because it doesn't generally
represent determinant versus dependent) is only made in the model, and
doesn't constrain the implementation.
* A possrep is part of the model and doesn't dictate options for the
implementation. In other words the DBMS is free to select an
implementation that doesn't resemble any of the possreps and yet it
could be said that it faithfully implements all of them.
By its very nature this usage of 'variable' is always an abstraction
over the physical (whereas values are instead pure mathematical
abstractions divorced from the physical). For example in order to say
that an area of computer memory encodes a value it is necessary to
make assumptions about many things including address lines, data buses
and the interpretation of voltage levels. This should be a reminder
that one cannot readily draw an absolute distinction between "direct"
and "indirect" encodings of values.
> > I find many things you say very confusing. A database... all possible
> > databases...one possible database...the database...any database. What
> > do you mean by the word 'database'?
>
> A database is a set of relations that conforms to a given database schema.
Do you mean set as in formal set theory? If a database is a set, then
it's a pure mathematical object that doesn't exist in time and space.
That seems to contradict your prior post "... database values can
exist in time and space ..."
> Don't you agree that the database schema defines the set of all valid
> databases? Don't you also agree that of all valid databases, only one
> database at a time can be the current database? Is it my use of the terms
> 'possible' and 'actual' that has you confused?
Actually I'm finding many things you're saying confusing.
> > We have different definitions of the term 'value'. I use it (only) to
> > mean an abstract, well defined mathematical object like a particular
> > integer, completely divorced from any appearance of that value (such
> > as being used to record someone's age).
>
> Abstract, well defined mathematical objects cannot change, so a formalism
> that admits only abstract, well defined mathematical objects cannot be used
> to model things that can change.
I already pointed out the flaw in that statement. Physical database
systems are variables not values.
> > When you say a value means different things at different times it
> > seems like you're thinking a value is what C.Date calls an appearance
> > of a value, which actually has more to do with a variable that exists
> > in time and space.
>
> Please don't misrepresent me: I didn't say that a value means different
> things at different times; I said that a term in a formal language can mean
> different things at different times.
>
> Also, a variable is a container for a value. How can it exist in time and
> space?
You're going to have to expand on that.
> > I don't consider relation values to have names.
>
> That doesn't surprise me. I suppose that you would attribute the same
> meaning to a relation that is constructed by explicitly stating the heading
> and tuples, as a relation consisting of the exact same set of tuples that is
> the result of a union of two relations in the database?
Relation values aren't constructed (rather they are selected). You
make it sound like they can suddenly spring into existence.
Since relation values don't exist in space or time it doesn't make
sense to think that they in themselves record facts about the real
world. They only do that when they appear as encoded values in a
physical database (as the current value of a relation variable).
Brian Selzer
> On Jun 27, 2:23 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
>> "David BL" <davi...@iinet.net.au> wrote in message
>>
>>
>> > If a database system records relations, then there are relation
>> > variables. I fail to see how you can deny that. It follows from the
>> > definition of 'variable'. Also when a variable changes then by
>> > definition it has been reassigned. I don't see how that assumes any
>> > implementation methodology. Definitions in themselves don't imply
>> > anything at all.
>>
>> I think you are afflicted with tunnel vision. A database system does not
>> just record relations in isolation. If anything it records entire
>> databases, one at a time, each of which just happens to be a set of
>> relations. But a database system need not even record databases at all:
>> it
>> could instead record just the differences between successive databases,
>> which when accumulated can be presented as a set of relations. None of
>> these implementation methodologies involve the use of relation variables.
>> The latter does not even hint at assignment, since it involves appending
>> to
>> and accumulating a stream of assertions to arrive at the current set of
>> relations, though it is conceivable that intermediate results could be
>> cached under the covers in order to improve query performance.
>
> You're ignoring the idea of physical independence.
I don't think I am.
> The definition of 'variable' (relevant to this discussion) doesn't
> constrain physical implementation choices in any way. The sense in
> which a variable is deemed to hold a value can be arbitrarily
> indirect, and for example may involve physical storage of deltas.
The use of relvars does constrain physical implementation--at least
indirectly. The decision to use relvars relegates delete, insert, and
update to being shortcuts for assignment. As a consequence, when it comes
time to enforce constraints, only the before and after images of each relvar
are supplied, and it can no longer be determined whether an update was
issued, or a just a delete and an insert, or if the entire relation had been
replaced.
<snip>
>> > I find many things you say very confusing. A database... all possible
>> > databases...one possible database...the database...any database. What
>> > do you mean by the word 'database'?
>>
>> A database is a set of relations that conforms to a given database
>> schema.
>
> Do you mean set as in formal set theory? If a database is a set, then
> it's a pure mathematical object that doesn't exist in time and space.
> That seems to contradict your prior post "... database values can
> exist in time and space ..."
Perhaps I should have used the term 'collection' instead, to avoid
confusion.
>> Don't you agree that the database schema defines the set of all valid
>> databases? Don't you also agree that of all valid databases, only one
>> database at a time can be the current database? Is it my use of the
>> terms
>> 'possible' and 'actual' that has you confused?
>
> Actually I'm finding many things you're saying confusing.
Sorry about that.
>> > We have different definitions of the term 'value'. I use it (only) to
>> > mean an abstract, well defined mathematical object like a particular
>> > integer, completely divorced from any appearance of that value (such
>> > as being used to record someone's age).
>>
>> Abstract, well defined mathematical objects cannot change, so a formalism
>> that admits only abstract, well defined mathematical objects cannot be
>> used
>> to model things that can change.
>
> I already pointed out the flaw in that statement. Physical database
> systems are variables not values.
I don't think it is flawed since those variables can only contain abstract,
well defined mathematical objects that cannot change.
>> > When you say a value means different things at different times it
>> > seems like you're thinking a value is what C.Date calls an appearance
>> > of a value, which actually has more to do with a variable that exists
>> > in time and space.
>>
>> Please don't misrepresent me: I didn't say that a value means different
>> things at different times; I said that a term in a formal language can
>> mean
>> different things at different times.
>>
>> Also, a variable is a container for a value. How can it exist in time
>> and
>> space?
>
> You're going to have to expand on that.
What do you want to know?
>
>> > I don't consider relation values to have names.
>>
>> That doesn't surprise me. I suppose that you would attribute the same
>> meaning to a relation that is constructed by explicitly stating the
>> heading
>> and tuples, as a relation consisting of the exact same set of tuples that
>> is
>> the result of a union of two relations in the database?
>
> Relation values aren't constructed (rather they are selected). You
> make it sound like they can suddenly spring into existence.
They can in D. See <relation selector inv> on page 110 of TTM 3rd Edition.
> Since relation values don't exist in space or time it doesn't make
> sense to think that they in themselves record facts about the real
> world. They only do that when they appear as encoded values in a
> physical database (as the current value of a relation variable).
Not sure what you mean by this.
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
>
>
> > constrain physical implementation choices in any way. The sense in
> > which a variable is deemed to hold a value can be arbitrarily
> > indirect, and for example may involve physical storage of deltas.
>
> The use of relvars does constrain physical implementation--at least
> indirectly. The decision to use relvars relegates delete, insert, and
> update to being shortcuts for assignment.
I disagree. Variables can have many distinct ways of being
reassigned. This can be modelled by representing changes to variables
as values of various types!
My area of research (Operational Transform) concerns the recording of
locally generated deltas on a replicated, distributed database as
values (called "operations") that can be propagated efficiently in
order to achieve synchronisation without any need for distributed
transactions. I certainly don't think of operations as just shortcuts
for assignments. This is not just a physical distinction, it is a
logical one. In fact a logical representation of an operation allows
for the concept of intention preservation when operations are
transformed against each other in such a way that they can be applied
in different orders at different sites, yet still allow all sites in
the distributed system to converge to the same final state.
Let the execution of operation O on state S result in state S' denoted
by S' = S+O. In the OT literature two concurrent operations O1,O2
that are applied on the same initial state S are said to be equivalent
if S+O1 = S+O2. This is not a sufficient condition for O1=O2.
This formalises the sense in which it is possible to say that delete,
insert and update can be equivalent to assignment, but not the same as
assignment.
This is regardless of whether one treats the database state as the
abstract value of a database variable.
> >> Abstract, well defined mathematical objects cannot change, so a formalism
> >> that admits only abstract, well defined mathematical objects cannot be
> >> used
> >> to model things that can change.
>
> > I already pointed out the flaw in that statement. Physical database
> > systems are variables not values.
>
> I don't think it is flawed since those variables can only contain abstract,
> well defined mathematical objects that cannot change.
I don't see what the problem is.
> >> > When you say a value means different things at different times it
> >> > seems like you're thinking a value is what C.Date calls an appearance
> >> > of a value, which actually has more to do with a variable that exists
> >> > in time and space.
>
> >> Please don't misrepresent me: I didn't say that a value means different
> >> things at different times; I said that a term in a formal language can
> >> mean
> >> different things at different times.
>
> >> Also, a variable is a container for a value. How can it exist in time
> >> and
> >> space?
>
> > You're going to have to expand on that.
>
> What do you want to know?
When someone uses a debugger to view values of integer variables on
the stack frame, are you saying they aren't variables, or that they
don't exist in time and space?
> >> > I don't consider relation values to have names.
>
> >> That doesn't surprise me. I suppose that you would attribute the same
> >> meaning to a relation that is constructed by explicitly stating the
> >> heading
> >> and tuples, as a relation consisting of the exact same set of tuples that
> >> is
> >> the result of a union of two relations in the database?
>
> > Relation values aren't constructed (rather they are selected). You
> > make it sound like they can suddenly spring into existence.
>
> They can in D. See <relation selector inv> on page 110 of TTM 3rd Edition.
That is a *selection* of a relation value. It doesn't cause a
relation value to come into existence. D&D are careful about this -
that's why they use the term selection not construction.
> > Since relation values don't exist in space or time it doesn't make
> > sense to think that they in themselves record facts about the real
> > world. They only do that when they appear as encoded values in a
> > physical database (as the current value of a relation variable).
>
> Not sure what you mean by this.
Given a relation type (i.e. schema), there are a number (possibly
infinite) of relation values that conform to that type. The type and
the values of that type are all abstract and carry almost no
information.
Consider the analogy of a textual string. If you could look at a vast
number of random strings, you might occasionally find some interesting
ones like Shakespeare's Macbeth. Information comes from the
*selection* of useful values from amongst the multitude. An analogy
is how a sculptor uncovers a work of art in a block of stone even
though it was there all along.
The amount of information in a value can be quantified by the size of
the smallest program that can generate that value. A program to
generate the set of all strings is trivial (at least on an abstract
machine that's equivalent to a Turing machine with its infinite
tape!), whereas a program to output only one selected string is
arbitrarily large.
Cimode
<<
Given a relation type (i.e. schema), there are a number (possibly
infinite) of relation values that conform to that type. The type and
the values of that type are all abstract and carry almost no
information. >>
cardinality of the relation supertype. That is a constraint imposed
by how a relation is defined.
none Reinier Post
[...]
>interesting idea that one can use the RA to define functions. E.g.
>start with some n-ary relation and use projection to get a binary
>relation, and rename as required according to this special naming
>convention.
Functions were introduced to me, in high school,
as binary relations that are subject to a functional dependency.
Treating functions as constrained relations won't help you much, though.
E.g. in order to arrive at all computable functions you'll need to
come op with some computing machinery of whatever form. Starting out
with relations doesn't change that.
--
Reinier
David BL
Sure. Why did you say that?
Joe Thurbon
> On Jun 27, 10:10 am, "Joe Thurbon" <use...@thurbon.com> wrote:
[...]
>>
>> What are you talking about when you say interpretation?
>
> I completely agree that an interpretation in model theory is a
> mathematical construct. I don't believe Brian was using the word
> interpretation in that sense, because he spoke about a UoD that can
> exist in time and space. His words:
>
> "... if what is in the Universe of Discourse can
> exist in time and space, then database values can
> exist in time and space. A value is the result of
> applying for a given term the valuation function
> which maps terms expressed in a formal language to
> things in the Universe of Discourse under an
> interpretation."
>
> I assumed he was talking about the idea to interpret mathematical
> relations as predicates that apply to the real world. i.e. external
> predicates.
>
Sorry about the delay in replying, this conversation seems to have moved
on. But thanks for clarifying.
> As C.Date says:
>
> "... while internal predicates are a formal
> construct, external predicates are an informal
> construct merely. Internal predicates are (loosely)
> what the data means to the DBMS; external
> predicates, by contrast, are what the data means
> to the user."
>
> An external predicate, being informal, is typically stated in natural
> language.
>
Out of interest, Date also states his formal predicates in natural
language, at least in Logic and Databases.
Cheers,
Joe
Brian Selzer
> On Jun 29, 5:11 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
>> "David BL" <davi...@iinet.net.au> wrote in message
>>
>>
>> > The definition of 'variable' (relevant to this discussion) doesn't
>> > constrain physical implementation choices in any way. The sense in
>> > which a variable is deemed to hold a value can be arbitrarily
>> > indirect, and for example may involve physical storage of deltas.
>>
>> The use of relvars does constrain physical implementation--at least
>> indirectly. The decision to use relvars relegates delete, insert, and
>> update to being shortcuts for assignment.
>
> I disagree. Variables can have many distinct ways of being
> reassigned. This can be modelled by representing changes to variables
> as values of various types!
Can you please elaborate?
> My area of research (Operational Transform) concerns the recording of
> locally generated deltas on a replicated, distributed database as
> values (called "operations") that can be propagated efficiently in
> order to achieve synchronisation without any need for distributed
> transactions.
It sounds like a very interesting area of research. I can only imagine what
it entails.
> I certainly don't think of operations as just shortcuts
> for assignments. This is not just a physical distinction, it is a
> logical one. In fact a logical representation of an operation allows
> for the concept of intention preservation when operations are
> transformed against each other in such a way that they can be applied
> in different orders at different sites, yet still allow all sites in
> the distributed system to converge to the same final state.
>
> Let the execution of operation O on state S result in state S' denoted
> by S' = S+O. In the OT literature two concurrent operations O1,O2
> that are applied on the same initial state S are said to be equivalent
> if S+O1 = S+O2. This is not a sufficient condition for O1=O2.
I'm cringing a bit here. This reminds me of the problems associated with
Sql Server replicating updates as delete/insert pairs.
> This formalises the sense in which it is possible to say that delete,
> insert and update can be equivalent to assignment, but not the same as
> assignment.
I'm cringing again, because this implies that descriptions must be rigid
under the intended interpretation. I think that in order to be equivalent,
the result has to be not just the same syntactically, but also semantically.
When I issue an update, I am asserting that something appears different, but
when I issue a delete and an insert, I am asserting that something ceased to
exist while at the same time something else came into existence; therefore,
even though the results of two operations may be identical syntactically,
they are not necessarily semantically equivalent.
Now you're talking about a physical manifestation of the abstract.
>> >> > I don't consider relation values to have names.
>>
>> >> That doesn't surprise me. I suppose that you would attribute the same
>> >> meaning to a relation that is constructed by explicitly stating the
>> >> heading
>> >> and tuples, as a relation consisting of the exact same set of tuples
>> >> that
>> >> is
>> >> the result of a union of two relations in the database?
>>
>> > Relation values aren't constructed (rather they are selected). You
>> > make it sound like they can suddenly spring into existence.
>>
>> They can in D. See <relation selector inv> on page 110 of TTM 3rd
>> Edition.
>
> That is a *selection* of a relation value. It doesn't cause a
> relation value to come into existence. D&D are careful about this -
> that's why they use the term selection not construction.
I don't know about you, but the right hand side of the assignment,
PQ := RELATION { TUPLE { P# P#('P1'), QTY QTY( 600) } ,
TUPLE { P# P#('P5'), QTY QTY( 500) } ,
TUPLE { QTY QTY(1000), P# P#('P2') } ,
TUPLE { P# P#('P4'), QTY QTY( 500) } ,
TUPLE { QTY QTY(400), P# P#('P3') } ,
TUPLE { P# P#('P6'), QTY QTY( 100) } } ;
From page 153, TTM 3rd Edition, looks to me like a relation that just sprang
into existence!
David BL
> "David BL" <davi...@iinet.net.au> wrote in message
> > I disagree. Variables can have many distinct ways of being
> > reassigned. This can be modelled by representing changes to variables
> > as values of various types!
>
> Can you please elaborate?
What I mean is that the various changes which can be made to a given
variable of a given type can be regarded as mathematical objects (i.e.
values of various types) which I later referred to as operations.
> > Let the execution of operation O on state S result in state S' denoted
> > by S' = S+O. In the OT literature two concurrent operations O1,O2
> > that are applied on the same initial state S are said to be equivalent
> > if S+O1 = S+O2. This is not a sufficient condition for O1=O2.
>
> I'm cringing a bit here. This reminds me of the problems associated with
> Sql Server replicating updates as delete/insert pairs.
I think you have misunderstood. I'll repeat my last sentence above:
This is not a sufficient condition for O1=O2. An update operation is
not equal to delete+insert.
> > This formalises the sense in which it is possible to say that delete,
> > insert and update can be equivalent to assignment, but not the same as
> > assignment.
>
> I'm cringing again, because this implies that descriptions must be rigid
> under the intended interpretation. I think that in order to be equivalent,
> the result has to be not just the same syntactically, but also semantically.
I have no idea what you mean. When I say "equivalent" I simply mean a
particular equivalence relation can be defined. That in turn just
means a relation that is reflexive, symmetric and transitive. It
turns out that an equivalence relation can be defined on operations
O1,O2, according to the requirement that they act on the same initial
state and produce the same final state, but in the OT literature this
is not regarded as a definition of when two operations are equal, but
instead only of when they are "equivalent".
> > When someone uses a debugger to view values of integer variables on
> > the stack frame, are you saying they aren't variables, or that they
> > don't exist in time and space?
>
> Now you're talking about a physical manifestation of the abstract.
I have no idea what you mean by that and why. There are two different
kinds of abstractions:
1) Formal mathematical objects that don't exist in time and space.
E.g. the integers.
2) Informal abstractions over the physical which are objects that are
deemed to exist in time and space. E.g. a human, or a relation
variable on a real computer.
You appear to be saying that variables cannot be of type (2) because
they hold values of type (1). Why exactly do you think that is a
problem?
> I don't know about you, but the right hand side of the assignment,
>
> PQ := RELATION { TUPLE { P# P#('P1'), QTY QTY( 600) } ,
> TUPLE { P# P#('P5'), QTY QTY( 500) } ,
> TUPLE { QTY QTY(1000), P# P#('P2') } ,
> TUPLE { P# P#('P4'), QTY QTY( 500) } ,
> TUPLE { QTY QTY(400), P# P#('P3') } ,
> TUPLE { P# P#('P6'), QTY QTY( 100) } } ;
>
> From page 153, TTM 3rd Edition, looks to me like a relation that just sprang
> into existence!
No. The rhs of that assignment statement is only selecting a relation
value, not causing the value to exist (and implying that it didn't
exist previously). Your position is metaphysical because it doesn't
make any measureable predictions that can be falsified.
Would you say
x := 5;
causes the integer 5 to spring into existence? I would say that the
rhs simply refers to one of the integers, and not even talk about when
or where that integer exists (which is just a waste of time).
Cimode
David BL
ISTM that in practise all types of interest to computer software must
either be finite or countably infinite. For example a domain type
that consists of all the finite strings is countably infinite but
nevertheless a reasonable idealisation for real computers (i.e.
despite the potential for running out of memory).
By contrast, uncountably infinite sets are generally useless in
computer science because the elements can't be encoded in a
satisfactory manner. Consider for example sets of infinite strings, or
the power set over the integers.
Brian Selzer
I think that there is a misunderstanding here about formality and about the
difference between ordinary and abstract objects. I hope that the following
will clear a few things up.
I accept as an axiom that there are objects that can have a location in time
or space. To formalize this, let C! be a 1-place relation that ranges over
the objects in the Universe and expresses the property of having a location
in time and space--that is, being concrete. Given C!, the properties of
being ordinary, O!, and being abstract, A!, can be defined. Only those
objects that can have a location in time or space are ordinary, and those
are exactly the objects that possibly exemplify C!; every other object is
abstract and as such cannot have a location in time or space, and the
abstract objects are exactly the objects that don't possibly exemplify C!.
The integer 5 is an abstract object. Abstract objects do not actually
exist: they just are. Under the Domain Closure Assumption, the only objects
that actually exist are those that exemplify C! and are represented in the
database, but that doesn't mean that abstract objects can't be discussed: it
just means that the quantifier forall ranges over every object that can
possibly be, which includes all objects that cannot have a location in time
and space, all objects that can, but don't, and all objects that actually
do. It is a consequence of assuming a fixed domain of quantification for
actual existence to be expressed as a predicate--call it E!. Obviously, E!
implies C!.
In contrast to the assignment of the integer 5, which as an abstract object
does not exemplify C!, for the assignment to PQ to succeed, due to the
Domain Closure Assumption the objects that each tuple in the relation maps
to must exist--that is, they must exemplify E! which implies that they must
exemplify C!. In that sense, the assignment of the relation asserts the
existence of the objects that its tuples map to, so it's not that much of a
stretch to say that the relation just sprang into existence. Of course,
all of this assumes that the user making the assertion is not lying or
mistaken.
none Reinier Post
>I accept as an axiom that there are objects that can have a location in time
>or space. To formalize this, let C! be a 1-place relation that ranges over
>the objects in the Universe and expresses the property of having a location
>in time and space--that is, being concrete.
Wait. Assuming that objects exist doesn't imply that we can uniquely
identify them. You and I, or even I and I, may very well disagree on
how to partition the universe into objects, depending on the purpose of
our description. How many objects is a chair? How many objects is
the character A? Can it be green? Is the chemical element C an object?
Is course 430, Database Design and Administration at Moron University,
an object? The reconciliation of different, overlapping database
schemas, even within the same organization, is an important practical
problem. So your relation is rather big. It certainly isn't a normal
database relation.
In order to apply the relational model, we don't have to assume the
existence of objects at all. It's an extra step you choose to make.
Aren't you just complicating matters for ytourself, and for the
rest of us?
>Given C!, the properties of
>being ordinary, O!, and being abstract, A!, can be defined. Only those
>objects that can have a location in time or space are ordinary, and those
>are exactly the objects that possibly exemplify C!; every other object is
>abstract and as such cannot have a location in time or space, and the
>abstract objects are exactly the objects that don't possibly exemplify C!.
>
>The integer 5 is an abstract object. Abstract objects do not actually
>exist: they just are.
But can we identify them uniquely? Are the character 'A', the
ASCII character 'A', the English character 'A', and the Arial character
'A' the same object, or are they not; if not, how many different objects
are they? Why call these things objects at all? Isn't it better to
call them something else? 'Values' comes to mind.
>Under the Domain Closure Assumption, the only objects
>that actually exist are those that exemplify C! and are represented in the
>database, but that doesn't mean that abstract objects can't be discussed: it
>just means that the quantifier forall ranges over every object that can
>possibly be, which includes all objects that cannot have a location in time
>and space, all objects that can, but don't, and all objects that actually
>do.
I think that's a bit much to ask. You can't quantify over them
unless you know how to find them and to tell them apart.
>It is a consequence of assuming a fixed domain of quantification for
>actual existence to be expressed as a predicate--call it E!. Obviously, E!
>implies C!.
Existence is a property of predicates or properties, not of
objects or values. It is nonsensical to state that 3 exists.
But I'm not sure that you need O! or E! anyway.
>In contrast to the assignment of the integer 5, which as an abstract object
>does not exemplify C!, for the assignment to PQ to succeed, due to the
>Domain Closure Assumption the objects that each tuple in the relation maps
>to must exist--that is, they must exemplify E! which implies that they must
>exemplify C!. In that sense, the assignment of the relation asserts the
>existence of the objects that its tuples map to, so it's not that much of a
>stretch to say that the relation just sprang into existence. Of course,
>all of this assumes that the user making the assertion is not lying or
>mistaken.
And this is your weak point. You want to express identity beyond
identifiability by attributes, but natural attributes are all that
we can see, so we have no way of verifying this identity.
The usual position is simply not to assume this identity at all:
assuming it can only serve to confuse things, by suggesting
identifiability that doesn't really exist.
One day, Mary came home from school and her goldfish was floating
sideways in its bowl. She ran to her mother and cried: mommy, mommy,
Britney is ill! Put your coat on, her mother said, we're taking her
to see the doctor. They took the whole bowl into the car, carefully
wrapped in a towel to keep Britney from catching a cold, and parked
around the corner, right in front of an animal store. Look at these
happy little goldfish in the window, said Mary to her goldfish,
we're going to make you better and you'll be just as happy as they are.
http://www.nytimes.com/2004/05/02/magazine/fixing-nemo.html
It took a long wait before the doctor could finally see Mary
and her poor little fish. But it was worth it! Don't worry,
said the doctor, we have just the treatment for her. By tomorrow,
she'll be as good as, erhm, as gold. Mary went home in delight.
The doctor called up the data entry screen and entered:
patient's name: Brittany
owner's name: Mary
type: goldfish
healthy: -
The next day, when Mary returned with her mother,
the screen had changed. Now it said:
patient's name: Brittany
owner's name: Mary
type: goldfish
healthy: +
Treatment was unusually difficult, said the doctor, that'll be $100.
Now it was Mary's mother's turn to start sobbing. But Mary went home
with a healthy little goldfish, and they lived happily ever after.
Later that day, the doctor got a phone call.
It was Mary's mother. I refuse to pay that bill, she said,
you know why. Prove it, said the doctor. Mary's mother
went over to his office and opened the transaction log.
You're essentially saying that, if the doctor's database was designed
according to your principles, her malpractice suit will hinge
on whether she sees an update or an delete/insert. Is that
a reasonable position?
I don't think so. Why are you holding it, then? You may be
confusing database tuples with objects in the OO world.
The difference is in the nature of the relationship between
attribute updates and the object being modelled.
In an OO fishtank, setting the 'healthy' property of a fish
to '+' will actually heal the fish! In a database, unless
we have some really unusual user-defined types inside, it will
do no such thing, but will only change our *statement* on
the health of that fish. This is why it's useless to regard
our database tuples as 'really' standing for identifiable objects:
we can only do that to the extent that we can actually identify
these objects by the tuple's attribute values.
--
Reinier
Walter Mitty
"none (Reinier Post)" <rp@raampje.> wrote in message
news:4a4d30b3$0$8961$703f...@news.kpn.nl...
> Brian Selzer wrote:
>
>>I accept as an axiom that there are objects that can have a location in
>>time
>>or space. To formalize this, let C! be a 1-place relation that ranges
>>over
>>the objects in the Universe and expresses the property of having a
>>location
>>in time and space--that is, being concrete.
>
> Wait. Assuming that objects exist doesn't imply that we can uniquely
> identify them. You and I, or even I and I, may very well disagree on
> how to partition the universe into objects, depending on the purpose of
> our description. How many objects is a chair? How many objects is
> the character A? Can it be green? Is the chemical element C an object?
> Is course 430, Database Design and Administration at Moron University,
> an object? The reconciliation of different, overlapping database
> schemas, even within the same organization, is an important practical
> problem. So your relation is rather big. It certainly isn't a normal
> database relation.
[snip]
> I don't think so. Why are you holding it, then? You may be
> confusing database tuples with objects in the OO world.
> The difference is in the nature of the relationship between
> attribute updates and the object being modelled.
>
> In an OO fishtank, setting the 'healthy' property of a fish
> to '+' will actually heal the fish! In a database, unless
> we have some really unusual user-defined types inside, it will
> do no such thing, but will only change our *statement* on
> the health of that fish. This is why it's useless to regard
> our database tuples as 'really' standing for identifiable objects:
> we can only do that to the extent that we can actually identify
> these objects by the tuple's attribute values.
>
> --
> Reinier
Among Hindu mystics, the division of the universe into objects is itself an
illusion. It might be considered "the first great blunder" of someone who
would understand ultimate reality.
http://en.wikipedia.org/wiki/Maya_(illusion)
Those of us who use databases for practical purposes, or who build databases
for others to use, do not think like Hindu mystics. We accept subject
matter entities as having real existence, and real identity. We routinely
refer to the assertions made inside a database as "facts" rather than
"opinions". It helps us get our job done, or at least gives us the
comforting illusion that we are getting our job done. We even think of some
keys as being "natural" and being subject to discovery rather than
invention.
The fact that all of this is subjective rather than objective usually
surfaces, in one way or another, during the requirements analysis phase of a
database project. In interviews with subject matter experts and users of
the data, you often hear people exclaim something like this: "Don't listen
to all those other people. They're all idiots. I'm going to tell you how
it really works." And that's only when you're building a database for
actual users.
More than half the time nowadays, requirements analysis is done with
marketing taking the part of some imagined future users of the product.
These future users are supposed to materialize once the product is built,
in a scenario that might be called the "field of dreams sales plan." You
know, "build it, and they will buy."
its common to accept subject matter entities as really existing, and really
havinmg identity.
Walter Mitty
"Walter Mitty" <wam...@verizon.net> wrote in message
news:OTh3m.554$P5....@nwrddc02.gnilink.net...
In a wonderful illustration of reality and illusion, my newsreader took the
close parenthesis in the above URL to be not part of the URL. So when you
follow the link, you get taken to the Wikipedia page for "no such article".
To get to the actual article, you may have to manually correct the URL
before you follow the link. I couldn't have engineered a better
illustration of the subjectivity of data.
Brian Selzer
"none (Reinier Post)" <rp@raampje.> wrote in message
news:4a4d30b3$0$8961$703f...@news.kpn.nl...
>
>>I accept as an axiom that there are objects that can have a location in
>>time
>>or space. To formalize this, let C! be a 1-place relation that ranges
>>over
>>the objects in the Universe and expresses the property of having a
>>location
>>in time and space--that is, being concrete.
>
> Wait. Assuming that objects exist doesn't imply that we can uniquely
> identify them.
I'll buy that, but not for the reason you're suggesting. It is the
assumption that there is a Universe that implies that the objects contained
therein can be distinguished from one another.
> You and I, or even I and I, may very well disagree on
> how to partition the universe into objects, depending on the purpose of
> our description.
But you cannot deny that there can be objects that can be located in time or
space, because there is overwhelming empiracle evidence to support it. Just
look out the window.
>How many objects is a chair? How many objects is
> the character A? Can it be green? Is the chemical element C an object?
> Is course 430, Database Design and Administration at Moron University,
> an object?
Unlike you, I am not referring to an arbitrary partitioning. Interpretation
is an instantaneous process--it occurs at a location in time. For abstract
objects that cannot have a location in time, the instant of interpretation
has no bearing on the outcome because abstract objects neither come into
existence nor cease to exist, but for ordinary objects that can, the instant
of interpretation may occur earlier than, at, or later than that location,
and the outcome is different at each of those instants, for one occurs
before the object came into existence, one occurs during its existence, and
one occurs after it ceases to exist.
> The reconciliation of different, overlapping database
> schemas, even within the same organization, is an important practical
> problem.
So what? How does that bear on whether there can be things that can have a
location in time or space?
> So your relation is rather big. It certainly isn't a normal
> database relation.
C! is a 1-place relation term in a formal language. It is not a database
relation, and I never said that it was. It could certainly belong to the
predicates of database relations, though.
> In order to apply the relational model, we don't have to assume the
> existence of objects at all. It's an extra step you choose to make.
> Aren't you just complicating matters for ytourself, and for the
> rest of us?
You are so totally wrong: if we don't assume the existence of objects, then
there is no need for the basic assumptions of the relational model: the
unique name assumption, the closed world assumption, and the domain closure
assumption.
>>Given C!, the properties of
>>being ordinary, O!, and being abstract, A!, can be defined. Only those
>>objects that can have a location in time or space are ordinary, and those
>>are exactly the objects that possibly exemplify C!; every other object is
>>abstract and as such cannot have a location in time or space, and the
>>abstract objects are exactly the objects that don't possibly exemplify C!.
>>
>>The integer 5 is an abstract object. Abstract objects do not actually
>>exist: they just are.
>
> But can we identify them uniquely? Are the character 'A', the
> ASCII character 'A', the English character 'A', and the Arial character
> 'A' the same object, or are they not; if not, how many different objects
> are they? Why call these things objects at all? Isn't it better to
> call them something else? 'Values' comes to mind.
For me, 'symbols' comes to mind because 'values' are objects fixed at the
instant of interpretation. Some values are fixed to symbols; some values
are fixed to complex language terms, such as descriptions or function
applications.
>Under the Domain Closure Assumption, the only objects
>>that actually exist are those that exemplify C! and are represented in the
>>database, but that doesn't mean that abstract objects can't be discussed:
>>it
>>just means that the quantifier forall ranges over every object that can
>>possibly be, which includes all objects that cannot have a location in
>>time
>>and space, all objects that can, but don't, and all objects that actually
>>do.
>
> I think that's a bit much to ask. You can't quantify over them
> unless you know how to find them and to tell them apart.
Actually, you've got it backwards: you can't find them or tell them apart
unless you can quantify over them. Properties are expressed in logic as
1-place relations that range over the objects in the Universe. Objects that
have a property exemplify its 1-place relation; objects that don't don't.
You can distinguish between objects only if one exemplifies the 1-place
relation for a property that the other doesn't, and you can only find
objects if you can distinguish between them.
>>It is a consequence of assuming a fixed domain of quantification for
>>actual existence to be expressed as a predicate--call it E!. Obviously,
>>E!
>>implies C!.
>
> Existence is a property of predicates or properties, not of
> objects or values.
Neither properties nor predicates can have a location in time or space;
therefore, you're wrong: existence is not a property of predicates or
properties. It is nonsensical to state that red exists, but one can
sensibly state that something that does exist is red. "The balloon is red."
> It is nonsensical to state that 3 exists.
I think I pointed that out. Abstract objects do not actually exist: they
just are.
> But I'm not sure that you need O! or E! anyway.
>
>>In contrast to the assignment of the integer 5, which as an abstract
>>object
>>does not exemplify C!, for the assignment to PQ to succeed, due to the
>>Domain Closure Assumption the objects that each tuple in the relation maps
>>to must exist--that is, they must exemplify E! which implies that they
>>must
>>exemplify C!. In that sense, the assignment of the relation asserts the
>>existence of the objects that its tuples map to, so it's not that much of
>>a
>>stretch to say that the relation just sprang into existence. Of course,
>>all of this assumes that the user making the assertion is not lying or
>>mistaken.
>
> And this is your weak point. You want to express identity beyond
> identifiability by attributes,
This is not true. I didn't say this, nor did I imply it. I wouldn't even
think of it because identity is a relation, and has a strict formal
definition both for ordinary objects and for abstract objects. You are
conflating the concept of identity with the concept of identification. They
are completely unrelated. This is the crux of the issue: you are operating
under the false notion that what identifies something at one time identifies
the same thing at all times. While that is true of abstract objects since
abstract objects cannot have a location in time, it is clearly not true for
ordinary objects, as I have pointed out on numerous occasions.
I guess this is partly my fault: I should have stuck with the word 'thing'
rather than 'object' due to all of the OO baggage that 'object' carries with
it, but for the record: you brought up OO. I didn't!
<snipped fallacious argument based upon the misrepresentation of my
position>
none Reinier Post
>> You and I, or even I and I, may very well disagree on
>> how to partition the universe into objects, depending on the purpose of
>> our description.
>
>But you cannot deny that there can be objects that can be located in time or
>space, because there is overwhelming empiracle evidence to support it. Just
>look out the window.
I don't deny that there are objects. But look at
http://en.wikipedia.org/wiki/Window
How many windows are there in each of the pictures?
>>How many objects is a chair? How many objects is
>> the character A? Can it be green? Is the chemical element C an object?
>> Is course 430, Database Design and Administration at Moron University,
>> an object?
>
>Unlike you, I am not referring to an arbitrary partitioning.
It's only arbitrary in the Saussurean sense, i.e.
established by convention among those who use the terms.
[...]
>> The reconciliation of different, overlapping database
>> schemas, even within the same organization, is an important practical
>> problem.
>
>So what? How does that bear on whether there can be things that can have a
>location in time or space?
What those things are is part of our conceptualization. Different
choices of concepts => different things. But I agree that for
most cases this isn't much of an issue.
>> In order to apply the relational model, we don't have to assume the
>> existence of objects at all. It's an extra step you choose to make.
>> Aren't you just complicating matters for ytourself, and for the
>> rest of us?
>
>You are so totally wrong: if we don't assume the existence of objects, then
>there is no need for the basic assumptions of the relational model: the
>unique name assumption, the closed world assumption, and the domain closure
>assumption.
These assumptions are useful and common, but optional.
[...]
>> I think that's a bit much to ask. You can't quantify over them
>> unless you know how to find them and to tell them apart.
>
>Actually, you've got it backwards: you can't find them or tell them apart
>unless you can quantify over them. Properties are expressed in logic as
>1-place relations that range over the objects in the Universe.
I think you've got that backwards. True, most mathematical descriptions
I've seen reason about sets of objects. For instance, in the definition
of state machines, we have a set of symbols and a set of states.
But these are essentially placeholders. The definition doesn't
describe or prescribe what symbols or states are, it only describes
how they are combined into a state machine. Anything may take the role
of a symbol or state, although the formulation suggests otherwise.
There is no such thing as a universal division of objects into
symbols and the non-symbols, or states and the non-states,
independent of a particular formalization in which these
terms are used, such as a particular formalization of state machines.
What we can do is compare objects within an instance of a formalism,
or across different, but comparable instances of the same formalisms
or of comparable formalisms.
[...]
>> Existence is a property of predicates or properties, not of
>> objects or values.
>
>Neither properties nor predicates can have a location in time or space;
>therefore, you're wrong: existence is not a property of predicates or
>properties. It is nonsensical to state that red exists, but one can
>sensibly state that something that does exist is red. "The balloon is red."
You're right, I didn't formulate that correctly. We can't say that red
exists, but we can say that redness exists: it means that some things
are red. That is what I meant to say.
[...]
>> And this is your weak point. You want to express identity beyond
>> identifiability by attributes,
>
>This is not true. I didn't say this, nor did I imply it. I wouldn't even
>think of it because identity is a relation, and has a strict formal
>definition both for ordinary objects and for abstract objects.
OK. I don't think your formal definition completely succeeds but
I see what it tries to do. What I disagree with is your insistence
on objects being universal and absolute.
>You are
>conflating the concept of identity with the concept of identification.
Yes. I don't accepting the difference you claim there to be.
>They
>under the false notion that what identifies something at one time identifies
>the same thing at all times. While that is true of abstract objects since
>abstract objects cannot have a location in time, it is clearly not true for
>ordinary objects, as I have pointed out on numerous occasions.
For most concrete objects, most of the time we mostly agree on what
they are. To that extent you're right. See the window example above.
>I guess this is partly my fault: I should have stuck with the word 'thing'
>rather than 'object' due to all of the OO baggage that 'object' carries with
>it, but for the record: you brought up OO. I didn't!
I don't think there's been a confusion this time.
><snipped fallacious argument based upon the misrepresentation of my
>position>
That argument was the whole point of my posting.
The rest was just an introductory diversion.
I really don't care whether your metaphysical universe
contains absolute objects as long as you don't confuse them
with what we can actually identify. And that is what you appear
to be doing with your argument about the need to separate updates
from delete/insert combinations.
--
Reinier
Tegiri Nenashi
> ... most mathematical descriptions
> I've seen reason about sets of objects. For instance, in the definition
> of state machines, we have a set of symbols and a set of states.
> But these are essentially placeholders. The definition doesn't
> describe or prescribe what symbols or states are, it only describes
> how they are combined into a state machine. Anything may take the role
> of a symbol or state, although the formulation suggests otherwise.
> There is no such thing as a universal division of objects into
> symbols and the non-symbols, or states and the non-states,
> independent of a particular formalization in which these
> terms are used, such as a particular formalization of state machines.
Bad example. It is computer science that defines state machines as 5
tuple something. When I see 5 (and CS routinely offers definitions
longer than that!) tuple I just stop reading. Compare it to math where
automaton is defined by matrix action in a vector space. As somebody
from math forum eloquently put it "computer buffs tend to complicate
things".
none Reinier Post
>Bad example. It is computer science that defines state machines as 5
>tuple something. When I see 5 (and CS routinely offers definitions
>longer than that!) tuple I just stop reading. Compare it to math where
>automaton is defined by matrix action in a vector space. As somebody
>from math forum eloquently put it "computer buffs tend to complicate
>things".
Good point. Now, are states part of Brian's object universe,
or aren't they?
--
Reinier
Gene Wirchenko
[snip]
>Bad example. It is computer science that defines state machines as 5
>tuple something. When I see 5 (and CS routinely offers definitions
>longer than that!) tuple I just stop reading. Compare it to math where
>automaton is defined by matrix action in a vector space. As somebody
>from math forum eloquently put it "computer buffs tend to complicate
>things".
I am studying computation theory right now. The most complex
that I have seen so far is 5-tuples. It is nice to see it all defined
explicitly.
A state machine consists of a set of states, an alphabet, a state
transition function or relation, a starting state, and a set of
accepting states. Putting it in tuple form makes it more compact.
Several types of tuples have been defined. It is obvious from
the notational forms that and how the various automata are related. I
find this useful.
It is still tough slogging through some of the theorems, but I
think it would be worse in English.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Tegiri Nenashi
>
> I am studying computation theory right now. The most complex
> that I have seen so far is 5-tuples. It is nice to see it all defined
> explicitly.
7-tuple:
http://en.wikipedia.org/wiki/Turing_machine#Formal_definition
It is remarkable that among different models of computations the
ugliest one won.
> A state machine consists of a set of states, an alphabet, a state
> transition function or relation, a starting state, and a set of
> accepting states. Putting it in tuple form makes it more compact.
>
> Several types of tuples have been defined. It is obvious from
> the notational forms that and how the various automata are related. I
> find this useful.
Here is the source of my diatribe:
http://www.cs.cornell.edu/Courses/cs786/2004sp/
Lecture 8:
Algebraic Definition of Finite Automata
Def 8.1 A finite automaton over K is a triple A_ = (u,A,v) where u and
v are vectors and A is matrix....
The language accepted by A_ is the element u^T A* v
So, we still have start and stop states, but at least they are
introduced naturally.
Gene Wirchenko
>On Jul 14, 2:26�pm, Gene Wirchenko <ge...@ocis.net> wrote:
>>
>> � � �I am studying computation theory right now. �The most complex
>> that I have seen so far is 5-tuples. �It is nice to see it all defined
>> explicitly.
>
>7-tuple:
>
>http://en.wikipedia.org/wiki/Turing_machine#Formal_definition
I can not see why the input alphabet would be any different from
the tape alphabet. Explicitly naming blank is the sixth.
>It is remarkable that among different models of computations the
>ugliest one won.
Not really. At this level, the simplest set of axioms wins. The
ugliness is called elegance. One builds on top of the simple to get
the pretty stuff.
[snip]
Bob Badour
> Tegiri Nenashi <Tegiri...@gmail.com> wrote:
>
>>On Jul 14, 2:26 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>>
>>> I am studying computation theory right now. The most complex
>>>that I have seen so far is 5-tuples. It is nice to see it all defined
>>>explicitly.
>>
>>7-tuple:
>>
>>http://en.wikipedia.org/wiki/Turing_machine#Formal_definition
>
> I can not see why the input alphabet would be any different from
> the tape alphabet. Explicitly naming blank is the sixth.
>
>
>>It is remarkable that among different models of computations the
>>ugliest one won.
>
> Not really. At this level, the simplest set of axioms wins. The
> ugliness is called elegance. One builds on top of the simple to get
> the pretty stuff.
>
> [snip]
Nah. Turing machines are fugly.
Gene Wirchenko
>Gene Wirchenko wrote:
>
>> Tegiri Nenashi <Tegiri...@gmail.com> wrote:
[snip]
>>>It is remarkable that among different models of computations the
>>>ugliest one won.
>>
>> Not really. At this level, the simplest set of axioms wins. The
>> ugliness is called elegance. One builds on top of the simple to get
>> the pretty stuff.
>>
>> [snip]
>
>Nah. Turing machines are fugly.
You are agreeing with me. Turing machines are simple. Simple
comes at the cost of pretty. You can add pretty, but then you have
something more complex.
Bob Badour
> Bob Badour <bba...@pei.sympatico.ca> wrote:
>
>
>>Gene Wirchenko wrote:
>>
>>
>>>Tegiri Nenashi <Tegiri...@gmail.com> wrote:
>
>
> [snip]
>
>
>>>>It is remarkable that among different models of computations the
>>>>ugliest one won.
>>>
>>> Not really. At this level, the simplest set of axioms wins. The
>>>ugliness is called elegance. One builds on top of the simple to get
>>>the pretty stuff.
>>>
>>>[snip]
>>
>>Nah. Turing machines are fugly.
>
> You are agreeing with me. Turing machines are simple. Simple
> comes at the cost of pretty. You can add pretty, but then you have
> something more complex.
Are you saying lambda calculus is more complex?
Tegiri Nenashi
> Are you saying lambda calculus is more complex?
Complexity is measured by a potential number of bugs. By that criteria
TM simulator, e.g.
http://math.ucsd.edu/~sbuss/CourseWeb/MathLogic160/NobleJava/NobleJava.html
is both complex and fugly.
The underlying TM concepts ("tape", "read/write", "instruction")
appeal to human intuition, but are by no means clean mathematical
entities. I noticed my elevated confidence when programming heavily
mathematical stuff: the code essentially writes itself and the the
bugs are few and between.
Gene Wirchenko
>Gene Wirchenko wrote:
[snip]
>> You are agreeing with me. Turing machines are simple. Simple
>> comes at the cost of pretty. You can add pretty, but then you have
>> something more complex.
>
>Are you saying lambda calculus is more complex?
No. I was discussing Turing machines.
Bob Badour
> Bob Badour <bba...@pei.sympatico.ca> wrote:
>
>>Gene Wirchenko wrote:
>
> [snip]
>
>>> You are agreeing with me. Turing machines are simple. Simple
>>>comes at the cost of pretty. You can add pretty, but then you have
>>>something more complex.
>>
>>Are you saying lambda calculus is more complex?
>
> No. I was discussing Turing machines.
True, but that's not all you were discussing. You were also discussing
prettiness and elegance. The lambda calculus accomplishes the same as
the turing machine only with more beauty and elegance.
I recommend you search the EWD archive for what Dijkstra has to say
about elegance.
David BL
> On Jul 14, 8:06 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
> > Are you saying lambda calculus is more complex?
>
> Complexity is measured by a potential number of bugs. By that criteria
> TM simulator, e.g.
>
>
> is both complex and fugly.
>
> The underlying TM concepts ("tape", "read/write", "instruction")
> appeal to human intuition, but are by no means clean mathematical
> entities. I noticed my elevated confidence when programming heavily
> mathematical stuff: the code essentially writes itself and the the
> bugs are few and between.
In the mid 30's when Church/Kleene introduced the lambda definable
functions and proposed it for a definition of effectively calculable,
Godel was unconvinced calling it "thoroughly unsatisfactory" (in a
letter to Kleene).
Compare to one of Godel's quotes on Turing's work: "That this really
is the correct definition of mechanical computability was established
beyond any doubt by Turing.”
In that sense, the TM has been important.
none Reinier Post
Walter Mitty wrote:
>Among Hindu mystics, the division of the universe into objects is itself an
>illusion. It might be considered "the first great blunder" of someone who
>would understand ultimate reality.
I am neither a Hindu nor a mystic. I don't think objects are illusions,
but I do think that they are, to some extent, constructs of our minds
and of our languages, and that the exact identification of object is
to some extent a matter of convention. Not what the objects consist of,
but how we categorize and divide it up into objects. Most of the time,
this choice is obvious and does not require much explanation; but not
always and not usually when you regard every possible detail.
E.g. consider an entity 'Person'. By and large it's clear what we mean
by a person, and how to identify a person, without having to explain;
but there are unclear border cases. E.g. there may be disagreement on
when exactly a Person comes into being, or when a Person ceases to exist,
and in some cases we may want to categorize persons as one or two
depending on the purpose (e.g. Siamese twins among soccer players).
>http://en.wikipedia.org/wiki/Maya_(illusion)
I don't understand most of that article.
Does it have any implications for conceptual modelling?
>Those of us who use databases for practical purposes, or who build databases
>for others to use, do not think like Hindu mystics. We accept subject
>matter entities as having real existence, and real identity.
Entities can be described in terms of observed and predicted
regularities in our potential and actual observations of the world.
THis is not Hindu mysticism, but roughly what C.S. Peirce said,
if I recall correctly. Existence is real; identity is real, but relative.
There is nothing deep or mystical about this.
>We routinely
>refer to the assertions made inside a database as "facts" rather than
>"opinions". It helps us get our job done, or at least gives us the
>comforting illusion that we are getting our job done. We even think of some
>keys as being "natural" and being subject to discovery rather than
>invention.
But why? We call these assertions "facts" because the usefulness
of the database fundamentally depends on agreement between its users on
how the elements in the database correspond to observations that can be
made in the world, and on the outcomes of those observations.
We call the keys "natural" because their values systematically
correspond to the outcome of (potential) observations in the world.
These are fundamental prerequisites to the usefulness of
relational modelling; but the identification of objects isn't.
We may just as well regard it as *consequence* of conceptual modelling:
e.g. define an object as whatever corresponds to a tuple in a 6NF
relation. But that isn't a complete definition.
I do agree with Brian that in some conceptual models,
we can usefully identify objects across key changes:
the key can be unstable, in principle.
>The fact that all of this is subjective rather than objective usually
>surfaces, in one way or another, during the requirements analysis phase of a
>database project. In interviews with subject matter experts and users of
>the data, you often hear people exclaim something like this: "Don't listen
>to all those other people. They're all idiots. I'm going to tell you how
>it really works." And that's only when you're building a database for
>actual users.
If it wasn't, we could build a universal database schema,
that every database could simply use the relevant part of.
--
Reinier