Bob Badour 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, eg.,
mentally 'switch gears', never let the two get mixed up. This because I
remember him saying (which I agree with) that natural language isn't
sufficient to capture human experience. I suspect that no
anthropologist would disagree with this, ie., language we use can't
fully describe our reality. If it could, why would we need any ability
to abstract? After forty or so years of public exposure to computer
systems there seems to be some evidence of this, eg., in the way that
systems 'become' or replace the commonly perceived reality. (Personally
I despair about this but it does seem fact to me.)

Bob Badour wrote:
....
AFAIAC, your Rosie is an indirect, therefore honorary, participant here,
as Cato the cat is and Lady the pointer and Celtie the collie used to
be. The wag of a tail has oft saved readers here from some stupid
contribution or other. What they know that I don't know astounds me,
the distant approach of a coyote for example. They could care less
about what I know that they don't.

I never realized there were so many rabbits in the ground cover around
here until I noticed the owls at night and the eagles in the daytime but
the pets already knew, you could see it in their stance.

On May 19, 4:58*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I assume by "operators" you mean something other than relational
algebra operations. Something like arithmetic plus. I'd suggest the
later is actually a relation and one may benefit from making this idea
explicit:

http://vadimtropashko.wordpress.com/...ing-with-qbql/

On May 19, 5:22*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
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)
into x(t-T). Think about it: it predicts the future! When this has
been discovered many "hands-on" people rushed to make actual
implementations! Than he paused.... Do you understand the difference
between the model and reality?"

Tegiri Nenashi wrote:
I had aggregates in mind. I can think of two uses for plus, one
involving relations per se and the other involving attributes. But
'sum' is something else. I'd say it deals with a set that is not a
relation.

paul c wrote:
Thanks for the pointer Bob, I just ordered it.

I don't know if I really understand what you're talking about,
but a contribution from the realm of fact-oriented modeling
might be helpful here. I'm not sure the ideas are analogous
to what you mean by unary relations, but it's possible.

An "existential fact" is a fact that a certain thing exists.

For example "There is a city called Paris" contains an existential
fact. Two in fact; the existence of the city and the existence of
the city name 'Paris'.

There is also a binary fact which associates the two. Here, this
fact is an instance of a binary fact type which might be described
by the predicate "is called" having the two placeholders (also
called roles) City and CityName, so the full "fact type reading"
for this predicate is "City is called CityName".

A "unary fact type" is a fact type which contains a single placeholder.
An example might be "Person smokes". Here Person is the placeholder,
and smokes is the predicate.

It seems to me that the existential fact types (City, CityName, Person)
are your domains. These are not unary fact types, they're existential
fact types. The unary fact type "Person smokes" delineates a predicate
which is either true or false for each Person (assuming CWA), and thus
it delineates a subset of all actual Persons.

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.

Clifford Heath, Data Constellation.

On May 20, 1:56*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
It sounds like the first one (http://c2.com/cgi/wiki?
FirstGreatBlunder).

After my previous post, I read further (about the calculus of classes,
see http://fair-use.org/bertrand-russell...ematics/ch2sB).
Russell explains at length the difference between a class (the
extension) and a class-concept (the intention). To distinguish OOP
classes from Russell's definition of class, in this post I'll refer to
the former as OOP classes, and to the latter as the class domain.

I suspect now that OOP languages fail to properly distinguish the
difference and relationship between intension and extension. The
specification of the OOP class defines a class-concept, which can be
seen as a relation from an OID to a set of values (and possibly
methods). The constructor can be seen as a function selecting an
object from the class domain. 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. 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.

So this deviates from Date's point of view, in that I equate object
class with relation and not with domain or relvar. I hope my reasons
are sufficient, if not, I await your criticism.

On Wed, 19 May 2010 18:54:45 -0700 (PDT), Tegiri Nenashi
<tegirinenashi (AT) gmail (DOT) com> wrote:

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

Sincerely,

Gene Wirchenko

On 20 mei, 12:27, Nilone <rea... (AT) gmail (DOT) com> wrote:
That is not a world-shocking observation. OOP languages mostly fail
to properly make any relevant distinction (value/variable ?)
whatsoever.



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

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



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.

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



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".



Sorry, sounds like gibberish to me.

Gathering nouns and verbs in the proper order does not a meaningful
sentence make.



Which is exactly one of the two blunders.

At one point, you referred to "extension" and "intension".

I may be stepping out of the bounds of my expertise here, but one
thing I think I do understand is that a relation is the relationally
"encoded" form of an extension of a logical predicate :

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".

(And now the nitpickers are going to say that there are more than
three men in the world.)

Now does such a thing correspond to "object class" ? No, it doesn't.
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.

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".



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

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.

On May 20, 9:24*am, Gene Wirchenko <ge... (AT) ocis (DOT) net> wrote:
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.