 | |
#291
 
| |||
| |||
|
Re: MV Keys -
03-09-2006
, 03:34 PM
|
Jon Heggland wrote: marshall.spight (AT) gmail (DOT) com says... [... lots of disagreement ...] I was thinking about this thread, and how we seem to be talking past each other, and an idea occurred to me. I notice that much of what you're talking about is syntactic issues, while I'm trying to focus on the semantic. What if we're both right? What if, in fact, the element-of-a-set is a necessary *syntactic* construct, but not a necessary *semantic* one? |
disagree. You might have noticed that Jan H. challenged me when I
called a tuple in the GIRLS paper a relation, so I thought about it at
that time and figured that from his perspective this was a semantic
issue. Are you both a person and a set of one person? I would think
so, but one is a person and the other is a set. Is the lack of
something an empty set? Sure, but then it is something (a set) and not
just the lack of something.
Quote:
|
I notice you've brought up the issue of how one writes a relation literal a few times. Certainly, one needs a *syntactic* way to distinguish when one is entering values for one "row" and when one moves on to the next row. But at the semantic level, perhaps there is no need for a separate type, a separate abstraction, to model that element. The RA has no tuple-level operations, after all. Yet (1,b) is obviously not a relation, and equally obviously not a tuple by your definition! It is not the subset of anything, because it is not a set. Do you still not see the problem? Yes, I still don't see the problem. The problem is that you contradict yourself. You say (1,b) is a tuple, and you say that a tuple is a set. (1,b) is not a set. Syntactically, that is true. Semanticly, it may not be true. |
can be modeled as a set with one tuple element. So you are right that
you don't need a tuple type separate from a relation type IMO. If you
have relation operators, you can take any tuple and treat it as a set
of one tuple. --dawn
<snip lots of good stuff for brevity>
#292
| |||
| |||
|
|
Marshall Spight wrote: Maybe the way to say it is that anything that can be modeled as a tuple can be modeled as a set with one tuple element. So you are right that you don't need a tuple type separate from a relation type IMO. If you have relation operators, you can take any tuple and treat it as a set of one tuple. --dawn |
do exist, but only in the context of relations, and even though
they exist, there are no operators to extract them from the
relations they are in.
Like with an array: an array is a collection of updatable cells,
but there's no cell primitive. You can't have a cell in isolation
by itself, but if you really wanted one, you could make a
one-long array that had a single cell in it, and use that.
Marshall
#293
| |||
| |||
|
#294
| |||
| |||
|
|
Or, maybe another approach would be for me to say that tuples do exist, but only in the context of relations, and even though they exist, there are no operators to extract them from the relations they are in. |
Quote:
|
Like with an array: an array is a collection of updatable cells, but there's no cell primitive. You can't have a cell in isolation by itself, but if you really wanted one, you could make a one-long array that had a single cell in it, and use that. |
but frankly I'm getting tired of this discussion.
--
Jon
#295
| |||||||||||
| |||||||||||
|
|
Jon Heggland wrote: marshall.spight (AT) gmail (DOT) com says... [... lots of disagreement ...] I was thinking about this thread, and how we seem to be talking past each other, and an idea occurred to me. I notice that much of what you're talking about is syntactic issues, while I'm trying to focus on the semantic. What if we're both right? What if, in fact, the element-of-a-set is a necessary *syntactic* construct, but not a necessary *semantic* one? |
You can't "semantically" have sets without elements. Whether you let
users of your system have access to such elements outside the context of
a set, is a design decision---which intuitively sounds more syntactic
than semantic to me. I don't feel those labels fit all that well,
though.
Quote:
|
I notice you've brought up the issue of how one writes a relation literal a few times. Certainly, one needs a *syntactic* way to distinguish when one is entering values for one "row" and when one moves on to the next row. But at the semantic level, perhaps there is no need for a separate type, a separate abstraction, to model that element. The RA has no tuple-level operations, after all. |
between relations and tuples. In *practise*, you may not need to worry
about it. A weak analogy: You don't need to fiddle with tuples in order
to use relations, like you don't need to fiddle with bits to work with
integers. The tuples and the bits still exist, though.
As for the RA not having tuple operations, true, but I find it very
convenient to be able to talk about tuples when explaining how the RA
operators work to my students.
Anyway, I think there are two relatively independent issues here. One is
whether your system will be complete and usable without tuple types.
That is to a certain degree a matter of taste; I'll admit it may be
possible.
The other issue is your redefinition of "tuple" and the inconsistencies
I claim arise because of that. I have the impression you dodge all my
questions about infinite nesting of relations (a tuple being a set of
one tuple which is a set of one tuple and so on ad infinitum), so to my
mind, you don't take your own definition seriously. I'd guess you have
discovered that you don't need tuple types/variables, and so you reuse
the "tuple" term for convenience---without really thinking about the
theoretical consequences. I guess that since you are convinced your
system can work, you see no fault with your tuple definition---but I say
that your system might work because you don't really take the
consequences of your definition.
Quote:
|
The problem is that you contradict yourself. You say (1,b) is a tuple, and you say that a tuple is a set. (1,b) is not a set. Syntactically, that is true. Semanticly, it may not be true. |
*define* (1,b) to represent a set (though you sun into trouble if you
want it to represent the same set as { (1,b) }---what does (1,b)
represent in the second case?). But I am using standard set notation
here. I can say "Syntactically, 'orange' is not a number; semantically
it may be", but it is not very sensible to say, IMHO.
Quote:
|
Do you also agree that the cardinality-1 relation literals must (or at least should) be specified in such a way that the compiler knows that the cardinality is 1? Sure. How could it not know? |
the size of it at compile time. I was a bit muddled in my thinking,
though. The compiler of course knows the size of the literal, but the
size of an array is not part of its type. So you cannot in your system
define a procedure that requires a tuple as an argument---but you don't
need to or want to anyway?
Quote:
|
I believe tuple types as distinct from relation types exists by necessity/definition, since { (1,b) } is distinct from (1,b) What if "(1, b)" is just shorthand syntax for "{ (1,b) }"? |
It may be possible to do, but you will have a horribly confusing
syntax/grammar, IMO.
Quote:
|
Yes, I've seen this idea in TTM, and I think it is elegant (in theory, but cumbersome in practise). How well it works in practice will have a lot to do with how well the idea is executed. A convenient syntax could help a lot. |
and just define the result using such relational terms. I.e. more an
intellectual game than an actual language design / operator
implementation strategy.
Quote:
|
I just wonder how the code implementing the (infinite) relation "add" looks like. Do you envision this as implemented in a separate language and thus irrelevant to this discussion? Should the users / developers be able to make their own "operation relations" à la "add"? In the specific case of add, it's likely to be a built-in, to take advantage of machine instructions, but that's probably not what you were asking. No, I don't envision a separate language; users will certainly be able to write their own functions; it would not be a general purpose language otherwise. |
time envisioning how this will work, but maybe I'm just unimaginative.
Quote:
|
Fair enough. I disagree on both points, however. I think you need special syntax and behaviour for tuples; not considering them distinct from relations is therefore confusing, not simple. Special syntax: okay, sure; if only for the purposes of constructing relation literals. Behavior? What behavior do we need for tuples? |
Quote:
|
So, I can see how you could argue that this is cumbersome, or likely to be verbose, or badly done, or whatever. I can see how you can say that I've removed a valuable, useful abstraction, the tuple. But I don't see any contradiction, or any lack of computational power or generality. |
"tuple". You say that a relation is a subset of a cross product of sets.
An element of such a product is called a tuple; this is really not up
for debate, I think. It is *not* a set. When you say that it is, you are
gainsaying elementary set theory. You don't need to do this in order to
simplify your system by removing tuple types!
Quote:
|
I also believe that not taking advantage of tuples being fixed-size (as opposed to relations with a variable number of tu... I mean elements makes theimplementation more complicated than it needs to be. I'm not sure what you mean by "take advantage." If you mean at the implementation level, nothing prevents me from taking such advantage; it's possible to encapsulate the singleton idea. |
of considering them to be the same thing?
Quote:
|
If you mean at the syntactic level, again, I can have whatever syntactic level construct I want, even within the given semantics. At the semantic level, the concept of tuples is redundant, and removing it reduces complexity. And how would you do the variable assignment (if that is applicable---do you plan to have string variables?)? I had assignment for a while, but I dropped it; it was redundant with UPDATE. |
But are you saying that you don't have scalar variables, only relvars? Or that you use
UPDATE to change a scalar variable?
--
Jon
#296
| |||||||||||||||
| |||||||||||||||
|
|
marshall.spight (AT) gmail (DOT) com says... As for the RA not having tuple operations, true, but I find it very convenient to be able to talk about tuples when explaining how the RA operators work to my students. |
Quote:
|
Anyway, I think there are two relatively independent issues here. One is whether your system will be complete and usable without tuple types. That is to a certain degree a matter of taste; I'll admit it may be possible. |
Quote:
|
The other issue is your redefinition of "tuple" and the inconsistencies I claim arise because of that. |
Quote:
|
I have the impression you dodge all my questions about infinite nesting of relations (a tuple being a set of one tuple which is a set of one tuple and so on ad infinitum), so to my mind, you don't take your own definition seriously. |
the design, I pretty much stopped thinking about tuples per
se. I have enough trouble getting relations and scalars right.
Quote:
|
I'd guess you have discovered that you don't need tuple types/variables, and so you reuse the "tuple" term for convenience---without really thinking about the theoretical consequences. |
Quote:
|
I guess that since you are convinced your system can work, you see no fault with your tuple definition---but I say that your system might work because you don't really take the consequences of your definition. |
which I will now correct.
Quote:
|
The problem is that you contradict yourself. You say (1,b) is a tuple, and you say that a tuple is a set. (1,b) is not a set. Syntactically, that is true. Semanticly, it may not be true. No, the other way around. Through creative use of syntax, you can *define* (1,b) to represent a set (though you sun into trouble if you want it to represent the same set as { (1,b) }---what does (1,b) represent in the second case?). |
analogy with {} in Java; they don't mean the same thing everywhere
they appear. Likewise with parentheses here.
And just for fun, here's an alternative semantics for the syntax
above, in which the parentheses *do* mean the same thing.
(1,b)
Above, "(" means "introduce a new set, cardinality 1, with
the following attributes."
{ (1,b), (2,a) }
Here, "{" means "introduce a new set of arbitrary cardinality".
"(1,b)" means the same as it did before, and the comma
after it means "union".
Ha!
Quote:
|
Do you also agree that the cardinality-1 relation literals must (or at least should) be specified in such a way that the compiler knows that the cardinality is 1? Sure. How could it not know? When a method in Java takes an array as a parameter, it does not know the size of it at compile time. |
Quote:
|
The compiler of course knows the size of the literal, but the size of an array is not part of its type. |
I'm not far enough along to discuss well. But there are, in a
very few experimental systems, quite interesting things one
can do with considering list size as a static quality.
Quote:
|
So you cannot in your system define a procedure that requires a tuple as an argument---but you don't need to or want to anyway? |
(But I do allow nested relations, so it's possible to have an
attribute of relation type that has just one row. But there's
no point to an attribute with a relation type that's statically
one row; it's identical to flattening the attribute up a level.)
Quote:
|
How well it works in practice will have a lot to do with how well the idea is executed. A convenient syntax could help a lot. Sure. I guess what one does in practise, is to use conventional syntax, and just define the result using such relational terms. I.e. more an intellectual game than an actual language design / operator implementation strategy. |
terms, I'll just say that design *is* an intellectual game. A hard
one, with potentially significant benefits. The relational algebra
is also an intellectual game.
Quote:
|
... I don't envision a separate language; users will certainly be able to write their own functions; it would not be a general purpose language otherwise. But they won't be able to use anything but relation types? I have a hard time envisioning how this will work, but maybe I'm just unimaginative. |
and it's relationally complete. Allow recursive functions and now
it's turing complete. Add sum types so users can define their own
scalars, along with a few scalars that are predefined for efficiency
and convenience. Add lists for more convenience. Stir.
Quote:
|
My main issue is your definition of relation, and your use of the term "tuple". You say that a relation is a subset of a cross product of sets. An element of such a product is called a tuple; this is really not up for debate, I think. It is *not* a set. |
Quote:
|
When you say that it is, you are gainsaying elementary set theory. You don't need to do this in order to simplify your system by removing tuple types! |
Quote:
|
And how would you do the variable assignment (if that is applicable---do you plan to have string variables?)? I had assignment for a while, but I dropped it; it was redundant with UPDATE. There are some who say UPDATE *is* assignment. But are you sayingthat you don't have scalar variables, only relvars? Or that you use UPDATE to change a scalar variable? |
not the same thing. Also, I am saying no scalar variables.
Marshall
#297
| |||||
| |||||
|
|
And just for fun, here's an alternative semantics for the syntax above, in which the parentheses *do* mean the same thing. (1,b) Above, "(" means "introduce a new set, cardinality 1, with the following attributes." |
that element? Not "an attributes".
Quote:
|
{ (1,b), (2,a) } Here, "{" means "introduce a new set of arbitrary cardinality". "(1,b)" means the same as it did before, and the comma after it means "union". |
Quote:
|
Ha! |
on the important stuff.
Quote:
|
Sure. I guess what one does in practise, is to use conventional syntax, and just define the result using such relational terms. I.e. more an intellectual game than an actual language design / operator implementation strategy. That's a bit dismissive, don't you think? |
examples of how verbose the concrete syntax for it might be (not to
mention strange and unintuitive for the relation-unaware masses). But it
might be like lambda calculus: I wouldn't want to do any actual
programming in it, but it might be useful for theoretical research, or
as a scientific foundation for a system, cf. Date&Darwen's minimal
algebra.
Quote:
|
There are some who say UPDATE *is* assignment. But are you saying that you don't have scalar variables, only relvars? Or that you use UPDATE to change a scalar variable? Update and assignment are both imperative operators, but they are not the same thing. |
precise.
--
Jon
#298
| |||
| |||
|
|
In article <1142006381.942511.18190 (AT) v46g2000cwv (DOT) googlegroups.com>, marshall.spight (AT) gmail (DOT) com says... And just for fun, here's an alternative semantics for the syntax above, in which the parentheses *do* mean the same thing. (1,b) Above, "(" means "introduce a new set, cardinality 1, with the following attributes." A set has attributes? No, a set with card 1 has one element. What is that element? Not "an attributes". |
conflating terminology, but isn't the cardinality of a set an attribute? A
uniform set is a set of something, so wouldn't the type (or domain) of its
elements be an attribute?
Quote:
|
{ (1,b), (2,a) } Here, "{" means "introduce a new set of arbitrary cardinality". "(1,b)" means the same as it did before, and the comma after it means "union". But then you will have a set of set(s), won't you? Ha! We are bickering over details again. I believe we now agree sufficiently on the important stuff. Sure. I guess what one does in practise, is to use conventional syntax, and just define the result using such relational terms. I.e. more an intellectual game than an actual language design / operator implementation strategy. That's a bit dismissive, don't you think? Perhaps. I just don't see this paradigm as very practical, cf. my examples of how verbose the concrete syntax for it might be (not to mention strange and unintuitive for the relation-unaware masses). But it might be like lambda calculus: I wouldn't want to do any actual programming in it, but it might be useful for theoretical research, or as a scientific foundation for a system, cf. Date&Darwen's minimal algebra. There are some who say UPDATE *is* assignment. But are you sayingthat you don't have scalar variables, only relvars? Or that you use UPDATE to change a scalar variable? Update and assignment are both imperative operators, but they are not the same thing. They say update is a special kind/case of assignment, to be more precise. -- Jon |
#299
| |||
| |||
|
|
"Jon Heggland" <heggland (AT) idi (DOT) ntnu.no> wrote in message news:MPG.1e7e1f4d25e871bb98979e (AT) news (DOT) ntnu.no... In article <1142006381.942511.18190 (AT) v46g2000cwv (DOT) googlegroups.com>, marshall.spight (AT) gmail (DOT) com says... And just for fun, here's an alternative semantics for the syntax above, in which the parentheses *do* mean the same thing. (1,b) Above, "(" means "introduce a new set, cardinality 1, with the following attributes." A set has attributes? No, a set with card 1 has one element. What is that element? Not "an attributes". A set has at least one attribute, though it can have more. I may be conflating terminology, but isn't the cardinality of a set an attribute? A uniform set is a set of something, so wouldn't the type (or domain) of its elements be an attribute? |
'fusion'). It's most important property is that of membership (and so
consequently no. of members or cardinality). This is a formal
attribute, and is used by set theory to distinguish the set concept
from an individual (or atom). Thinking about the properties of the
empty set emphasises the importance of this notion.
A while back in the thread I also read talk of an individual being a
set of one item, or x = {X}. This is actually an area that was explored
most prominently by Quine early last century, but currently held in
scant regard by contemporary mathematics.
(In set theory an individual is an item that has no membership
property. With x ={x} this goes out the window and the definition of an
individual becomes an item that contains itself - a definition wholly
frowned upon as a contrived artifice).
All best, Jim.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.