General semantics

#31

On 20 mei, 22:51, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

Or one would have to leave the much desirable D&D requirement that "if
x == y, then for all f : f(x) == f(y)".

Incidentally, this "requirement" is simply nothing more than an
inevitable consequence (/just a rewording) of what it means in
mathematics to be a function ...

#32

On Thu, 20 May 2010 13:52:24 -0700 (PDT), Tegiri Nenashi
<tegirinenashi (AT) gmail (DOT) com> wrote:

Quote:

On May 20, 9:24*am, Gene Wirchenko <ge... (AT) ocis (DOT) net> wrote:
On Wed, 19 May 2010 18:54:45 -0700 (PDT), Tegiri Nenashi

tegirinena... (AT) gmail (DOT) com> wrote:
On May 19, 5:22*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
... The message I got from the book, at least the practical conclusion, is
that we must always think separately about a system and reality, ...

This is a recurring theme in many science endeavors. I remember a
story told by prof Mark Krasnoselski (RIP). "Here is a linear dynamic
system with a simple positive lookback. It converts an input *x(t)
^^^^

An input on x at time t?

Quote:

into x(t-T). Think about it: it predicts the future! When this has
^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^

An input on x at time t-T?
What is T?

How does this follow?

Quote:

been discovered many "hands-on" people rushed to make actual
implementations! Than he paused.... Do you understand the difference
between the model and reality?"

* * *Could you please unpack this? *I do not have the background to
follow the story, but I understand the conclusion.

Not sure what you are asking. The background
http://www.stanford.edu/class/ee102a/lecture4x4.pdf
It studies systems assembled out of well defined primitive blocks such
as delay, integrator, differentiator, etc. I don't remember the detail
of the system in question, other than it contained a no more than two
elements arranged in a simple feedback loop and one of them was delay.
One reason why it doesn't work as intended is because it is unstable.

Sincerely,

Gene Wirchenko

#33

Gene Wirchenko wrote:

Quote:

On Thu, 20 May 2010 13:52:24 -0700 (PDT), Tegiri Nenashi
tegirinenashi (AT) gmail (DOT) com> wrote:

On May 20, 9:24 am, Gene Wirchenko <ge... (AT) ocis (DOT) net> wrote:

On Wed, 19 May 2010 18:54:45 -0700 (PDT), Tegiri Nenashi

tegirinena... (AT) gmail (DOT) com> wrote:

On May 19, 5:22 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

... The message I got from the book, at least the practical conclusion, is
that we must always think separately about a system and reality, ...

This is a recurring theme in many science endeavors. I remember a
story told by prof Mark Krasnoselski (RIP). "Here is a linear dynamic
system with a simple positive lookback. It converts an input x(t)
^^^^
An input on x at time t?

into x(t-T). Think about it: it predicts the future! When this has
^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
An input on x at time t-T?
What is T?

Graphically, T is the magnitude of the translation along the t axis.

Quote:

How does this follow?

It applies a tranformation (specifically a translation) in the time
dimension.

#34

Clifford Heath wrote:

Quote:

paul c wrote:
....
When you talk of a unary relation, do you really mean a set of unary
facts of a single unary fact type? Or do you also include existential
fact types under the term "unary relation"? Because for me, those are
quite different things.

By unary relation I mean a relation with one attribute (which I think is
pretty standard lingo, surprised that anybody here wouldn't think that)
but I have no idea what a 'fact type' is. I know of relation and tuple
types but don't know what use terms like 'fact type' or 'unary fact'
terms might have.

#35

paul c wrote:

Quote:

By unary relation I mean a relation with one attribute (which I think is
pretty standard lingo, surprised that anybody here wouldn't think that)

Right, that's what I thought you meant. In which case, it could be a
representation of either an existential fact type (an object type),
or a unary predicate over one. The distinction is important. A unary
predicate creates a subset of the object type it involves.

This distinction was, I believe, the cause of your earlier disagreement.

Further, a unary fact type does not have to be mapped as a unary relation.
It could be represented as a boolean value in a table of that object type.

Quote:

but I have no idea what a 'fact type' is. I know of relation and tuple
types but don't know what use terms like 'fact type' or 'unary fact'
terms might have.

Fact oriented modeling has a parallel history with relational modeling.
It's built on logic rather than sets; those are two sides of one coin.
Needless to say, it has its own terminology - I tried to introduce some.
It's a different perspective, equal in power and purity to RM. It has
some advantages in mapping to natural language somewhat better. See
http://ormfoundation.org for more details. Ignore it, or look into it,
but don't scoff at it until you've looked into it.

#36

On 21 mei, 07:57, Clifford Heath <n... (AT) spam (DOT) please.net> wrote:

Quote:

paul c wrote:
By unary relation I mean a relation with one attribute (which I think is
pretty standard lingo, surprised that anybody here wouldn't think that)

Right, that's what I thought you meant. In which case, it could be a
representation of either an existential fact type (an object type),
or a unary predicate over one. The distinction is important. A unary
predicate creates a subset of the object type it involves.

This distinction was, I believe, the cause of your earlier disagreement.

Further, a unary fact type does not have to be mapped as a unary relation..
It could be represented as a boolean value in a table of that object type..

but I have no idea what a 'fact type' is. *I know of relation and tuple
types but don't know what use terms like 'fact type' or 'unary fact'
terms might have.

Fact oriented modeling has a parallel history with relational modeling.
It's built on logic rather than sets; those are two sides of one coin.
Needless to say, it has its own terminology - I tried to introduce some.
It's a different perspective, equal in power and purity to RM. It has
some advantages in mapping to natural language somewhat better. Seehttp://ormfoundation.orgfor more details. Ignore it, or look into it,
but don't scoff at it until you've looked into it.

It seems like the "big brown book" is the bible of the ORM faith.

Looking at the TOC, I see that in the field of constraints, the book
distinguishes between uniqueness constraints, value constraints,
subset constraints, equality constraints, exclusion constraints, ring
constraints, join constraints, ...

That is not an approach that invites to read on.

The RM really has all that is needed to be able to (de facto) do fact-
oriented modeling : relvars having predicates, plus the CWA.

SIRA_PRISE records the predicate of each relvar in its catalog. The
predicate of the catalog relvar that does this, is "<relvarname> is a
relvar whose predicate is <predicate>.". SIRA_PRISE also has a method
that can generate sentences from this predicate, e.g. the sentence
"RELVAR is a relvar whose predicate is "<relvarname> is a relvar whose
predicate is <predicate>.".". Incidentally, and referring to the
subtitle of that website, the name of the method that does this is
getTheFacts().

And I never needed any sort of ORM stuff to achieve that.

Nor did I need to make artificial distinctions between the predicates
of unary catalog relvars (e.g. "<typename> is a DBMS-supported type.")
and the others.

#37

On May 20, 10:51*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Thanks for the feedback. Let's see if I can explain and defend that
argument.

Quote:

You seem to axiomatically assume that OIDs are a necessity, and that
they _must_ exist.

Not at all. However, OOP languages are built on OIDs / references /
pointers. Any relational description of OOP must include them.

Quote:

Assertions of fact _can still be made_ if one does not have OIDs.

Yes, of course.

Quote:

*The constructor can be seen as a function selecting an
object from the class domain.

No it cannot. *If this were really true, then (using java as my
particular OOP dialect) "new Integer(1) == new Integer(1)" would have
to yield true.

My apologies, yes, the constructor always inserts a new tuple into the
domain of the class and returns its reference. It works just like a
SQL table with a hidden row number, and we can understand its problems
by viewing it in relational terms.

Quote:

Or one would have to leave the much desirable D&D requirement that "if
x == y, then for all f : f(x) == f(y)".

I agree with the requirement.

Quote:

OOP interfaces correspond to relations
between class-concepts, while abstract classes correspond to
normalization. *Virtual methods include the signature of a method in
the class-concept, while deferring the implementation to the class
domain.

OOP Interfaces are declarations of which methods are to be available.
Methods are (declarations of) operators.
So OOP interfaces are (declarations of (sets of)) operators.

That is not a type of thing that can possibly "correspond to
relations".

We can describe deterministic methods as binary relations over the
possible states of a set of variables. We can say that OOP classes
embed these methods as RVAs in the class or subclass.

Quote:

*Hence, in a concrete class with virtual methods, we have both
a class-concept and a default value for its domain. *Relations between
class-concepts extend to the class domain, but don't include the
default implementation. *Furthermore, the inability to enumerate the
domain class of an OOP class leads to developers creating ad-hoc
collections, and the failure to distinguish intension from extension
and default values leads to faulty reasoning about all aspects of the
system.

Sorry, sounds like gibberish to me.

Like in SQL tables, virtual methods in OOP classes correspond to
attributes with default values, which subclasses can overwrite. One
source of confusion in OOP comes from the assumption of default
behaviour, which can be overwritten by subclasses.

The mess of collection classes in OOP languages originate in the
inability to query the extensions of classes. The lack of relational
algebra leads to cursors / enumerators.

Quote:

RELATION{TUPLE{Erwin}TUPLE{Nilone}TUPLE{Bob Badour}} corresponds to
the extension of the predicate "x is a man" : "Erwin is a man and
Nilone is a man and Bob Badour is a man".

Now does such a thing correspond to "object class" ? *No, it doesn't.

Why not? I can write object classes that correspond to that
relation. Here's one, somewhat unconventional, in C#:

class Man
{
static Man Erwin = new Man();
static Man Nilone = new Man();
static Man Bob = new Man();

private Man() { }
}

Quote:

To the extent that it is even feasible/justifiable/warranted/... to
imagine any kind of correspondence between the two, I would _always_,
_unequivocally_ say that "object class" corresponds much more to "x is
a man" than that it corresponds to any extension of that predicate.

The actual link I see is really obscure, which is why I said "to the
extent that it is warranted to imagine any kind of correspondence" :
object class corresponds to predicate, predicate corresponds to
relvar, relvar has a (declared) (relation) type, therefore object
class corresponds to (relation) type.

I would like to avoid the word type for now, please? I say an object
class doesn't correspond to the heading of a relation, but to a subset
of a relation with its associated heading.

Quote:

And just so you don't jump on this apparent distinction I might appear
to be making between relation types and scalar types : both are just
types, so what I said was intended to be interpreted as "object class
corresponds to type".

I hope my reasons are sufficient, if not, I await your criticism.

Sorry, but what you thought to be "reasons for your position", has,
imo, to be dismissed on the grounds that they are "gibberish".

I don't see it yet, but I do appreciate that you're trying to point it
out to me.

Quote:

As a matter of fact, I happen to believe that trying to invent
correspondences between "object model" and "relational model" is a
futile waste of time, precisely because of the fact that the "object
model" (which doesn't deserve to be labeled a "model" to boot, but
never mind) fails to make the necessary proper distinctions between
value and variable.

Keith described the binding relation of a variable over time in the
"On Formal IS-A definition" thread. AFAIK, we can express any
mechanism of OOP in relational terms. OOP programs get compiled every
day. Trivially, each compiler corresponds to its own model of OOP.
However, class-based languages share many similarities, so we can
generalize some. I believe any model can be described as a relational
model. Therefore, there must exist a mapping from OOP to RM (I don't
think anyone could invert that mapping, though). By viewing OOP in
relational terms, I hope to understand it and learn how to work around
its idiosyncrasies. I don't want to advocate OOP, and I hold no love
for it, but I have to work with it. How am I to understand its
problems if I refuse to look at it?

#38

On May 21, 7:57*am, Clifford Heath <n... (AT) spam (DOT) please.net> wrote:

Quote:

paul c wrote:
By unary relation I mean a relation with one attribute (which I think is
pretty standard lingo, surprised that anybody here wouldn't think that)

Right, that's what I thought you meant. In which case, it could be a
representation of either an existential fact type (an object type),
or a unary predicate over one. The distinction is important. A unary
predicate creates a subset of the object type it involves.

This distinction was, I believe, the cause of your earlier disagreement.

Further, a unary fact type does not have to be mapped as a unary relation..
It could be represented as a boolean value in a table of that object type..

but I have no idea what a 'fact type' is. *I know of relation and tuple
types but don't know what use terms like 'fact type' or 'unary fact'
terms might have.

Perhaps, fact type = intension while unary fact = proposition?

#39

On 21 mei, 12:45, Nilone <rea... (AT) gmail (DOT) com> wrote:

Quote:

On May 21, 7:57*am, Clifford Heath <n... (AT) spam (DOT) please.net> wrote:

paul c wrote:
By unary relation I mean a relation with one attribute (which I thinkis
pretty standard lingo, surprised that anybody here wouldn't think that)

Right, that's what I thought you meant. In which case, it could be a
representation of either an existential fact type (an object type),
or a unary predicate over one. The distinction is important. A unary
predicate creates a subset of the object type it involves.

This distinction was, I believe, the cause of your earlier disagreement..

Further, a unary fact type does not have to be mapped as a unary relation.
It could be represented as a boolean value in a table of that object type.

but I have no idea what a 'fact type' is. *I know of relation and tuple
types but don't know what use terms like 'fact type' or 'unary fact'
terms might have.

Perhaps, fact type = intension while unary fact = proposition

Instantiating a predicate with attribute values always yields a
proposition, no matter what the degree of the relation is.

#40

Snipped

Quote:

It seems like the "big brown book" is the bible of the ORM faith.
*Faith* is the right word. Science is a different matter.

Quote:

Looking at the TOC, I see that in the field of constraints, the book
distinguishes between uniqueness constraints, value constraints,
subset constraints, equality constraints, exclusion constraints, ring
constraints, join constraints, ...
Having tried for more than 30 years to discard RM, OO crowd is now

reinventing (attempting to) RM. In other words 30 years of OO
*inquisitiveness* has produced quite an achievement !
Snipped...

Regards...