Fraud Number 3: U-Gene
Cimode
RM issues I pointed out...I will begin quoting some of their posts to
demonstrate their incoherence, ignorance or both...I will let the
people judge for themselves...
------------------------------------------------------------------------------------------------------------------------------
BEGIN
------------------------------------------------------------------------------------------------------------------------------
U-Gene
//Two relations (relvalues) exists. These relations have different
headers (schemas). Are these relvalues the values of different types?
OK this one's funny...and presents so many confusions I can't count...
This ignorant trully believes that relations = relvalues and asks
whether these values have different types thanks to the previous
assumption if the relation have different schemas??
SO I tried pointing that out to him...
//Me//
Your question is confusing...
when you ask ...
<<Two relations (relvalues) exists. These relations have different
headers (schemas). Are these relvalues the values of different types?
The tenure of your question seems to indicate you confuse a relvar and
its projection as a table....These are 2 different concepts...
..relvars do not have header..header is associated to a projection as a
human need for interpretation. only the body of the table represents a
projection of a relvar...
a relvar can define a type only if it has set of operators associated
to it...(see data type definitions). In case the operators and other
data type prereq are defined... 2 different relvars are necessarily are
possibly defining 2 separate types.
BUT as usual, ignorants persist and sign (always funny seeing them
being so sure;))
//U-Gene//
Do you understand the differense between relvalues (I asked about) and
relvar(iables) ? --> This ignorant actually truly believes he can
educate me
//Me// --> gave some extra shot to help him make some sense out of
it...Using sound proofs...I demonstrated his nonsense just
demonstrating the consequence if==of confusing relvalue and
relations...
Given the level of confusion your question implies, I do not believe
you are not a position to test my knowledge of difference between
relvar and relvalue...
While I had a doubt you meant *relvar* for *relavlue* as a TYPO which
would have has sense, I now clearly see you have no clue about what a
relation is...Confusing a relvalue, a relation and its projection as
table...
Here's the proof...
You state...
<<Two relations (relvalues) exists.>>
Your question implies relations = relvalues...which if I follow this
false premise reasonning would lead to relations that have similar
relvalues being equal which is totally false...2 relvar with same
relvalues are NOT necessarily equal.
<<These relations have different
headers (schemas). Are these relvalues the values of different >>
This question is totally irrelevant if you consider a relation as being
equal to a relvalue...
I rest my case...and let people judge from themselves....
Cimode
<<IMHO all relvalues have the same type and the headers is just data>>
Tony D
Cimode wrote:
> This ignorant trully believes that relations = relvalues and asks
> whether these values have different types thanks to the previous
> assumption if the relation have different schemas??
>
Now, I did read this thread, and I really like to sort this out. Can
you describe, without any bluster or invective, what is meant to you by
the terms "relvar", "relation" and "relvalue" ? You said that "I am
more a follower of the FP, McGoveran approach who advocate a tighter
commitment to terminilogy (sic) ..." (16th June, 2:27pm). Since you
then went on to say that a relation is both the variable and a value (I
think : what you said was "A relation is BOTH a relvar which represent
the abstract structure of the relvar and the relvalues which represents
its matter at a specific point in time.") I'd like an explicit
description of your view of these three terms, because, like others on
this thread I've so far taken the CJ Date line on this (even if it can
lead to overly structural thinking about relations). If it's in one of
Fabian Pascal's papers, by all means note which one and I'll spend the
$10 to read it.
In addition to that, I think U-gene isn't a native English speaker
either (I think he's Russian ?), so given that a non-native speaker is
arguing with another non-native speaker, the potential for confusion
multiplies.
Tony D
Cimode
Tony D wrote:
> Cimode wrote:
> > This ignorant trully believes that relations = relvalues and asks
> > whether these values have different types thanks to the previous
> > assumption if the relation have different schemas??
> >
>
> Now, I did read this thread, and I really like to sort this out. Can
> you describe, without any bluster or invective, what is meant to you by
> the terms "relvar", "relation" and "relvalue" ? You said that "I am
> more a follower of the FP, McGoveran approach who advocate a tighter
> commitment to terminilogy (sic) ..." (16th June, 2:27pm). Since you
> then went on to say that a relation is both the variable and a value (I
> think : what you said was "A relation is BOTH a relvar which represent
> the abstract structure of the relvar and the relvalues which represents
> its matter at a specific point in time.") I'd like an explicit
> description of your view of these three terms, because, like others on
> this thread I've so far taken the CJ Date line on this (even if it can
> lead to overly structural thinking about relations). If it's in one of
> Fabian Pascal's papers, by all means note which one and I'll spend the
> $10 to read it.
education (my time is as limited as yours)...
Therefore I believe you should read first so that we can discuss...As
you request, here are pointers...
http://www.dbdebunk.com/page/page/629796.htm
http://www.dbdebunk.com/page/page/1145637.htm
If you want to understand better the true nature of RM, I suggest you
purchase ALL papers too as well as Practical Issues in Data
Management...
> In addition to that, I think U-gene isn't a native English speaker
> either (I think he's Russian ?), so given that a non-native speaker is
> arguing with another non-native speaker, the potential for confusion
> multiplies.
True but declaring that relation = relvalue does not represent a
sufficient level of complexity to justify that cultural barrier would
be an excuse...
Cimode
I stated...
//A relation is BOTH a relvar which represent the abstract structure of
the relvar and the relvalues which represents its matter at a specific
point in time//
...I realize I made a TYPO mistake
as it should read..
//A relation is BOTH a relvar which represent the abstract structure of
the relation and the relvalues which represents its matter at a
specific point in time//
You ask
// I'd like an explicit description of your view of these three terms//
First of all, the mathematical aspect of a relation.
One could define a mathematical relation as an absract construct that
has purpose of representing and operating a specific time-dependent
*combination* of values drawn from arbitrarily defined ensembles of
values. In short, a relation can be viewed as a specific
ensemblist-combinatory function.
The consequence of admitting the premice that a relation is a specific
subset of functions is that you apply all characteritics of a function:
--> variables are defined as elementary *placeholders* for values
(variable is therefore a time independent concept)
--> values are defined as the elementary occurrence (or placefiller) of
a variable in a specifc point in time (value is therefore a time bound
concept)
--> the function as a whole defines a more new more complex ensemble of
values.
By using predicate logic and characteristics of ensemblist calculus,
the whole genius of Tedd Codd was to apply the 3 above characteristics
into bridging the gap between informal representation of meaning at
human level and formal representation of logical data at mechanized
computing level. As a result of his work was defined RM.
--> in RM, mathematical variables were refered to as relation-variable
known also as relvar
--> in RM, Codd tried to apply the concept of mathematical values
elementary occurrence as being a specific datum.
--> By using the concept of domains (representing ensemble of values of
arbitrary complexity), he established that a relation defines a new
domain of its own.
--> To define the logical operations and characteristics of relvars in
RM, Codd used logical tables (refered as R-Tables) as a possible
projection of a relvar in time.
--> In R-tables, he defined the rules by which values (sometime called
relvalues) could be drawn from and possibly operated from a specific
domain. THe unique combination of these rules constitute a *data
type*. By using R-Tables, he associated the representation of the
relvar in a column\row logical construct where columns are defined as
attributes and rows (respecting predicate theory prerequisites)
represent *tuples*.
Knowing this should avoid further confusion:
--> relations, relvars, relvalues are on different level of definition.
They certainly are not to be equated.
--> attribute data type directly refers to formal definition and
*possible* operations that can carry on single domain drawn
*permissible* values.
--> relvar type refers to the rule that defines the new domain induced
by definition of attributes data types. Therefore, relvar type is not
the same as attribute data type.
--> R-tables are ONE possible representation of relvars.
--> Considering they do not support sufficiently domain characteritics,
SQL Tables are not R-Tables.
Hope this clarified.
Erwin
> The consequence of admitting the premice that a relation is a specific
> subset of functions is that you apply all characteritics of a function:
Funny. For some reason I thought that in math, the functions were a
subset of the relations. And therefore, the relations are a superset
of the functions. It hurts to discover one's own ignorance.
> --> relations, relvars, relvalues are on different level of definition.
Do I understand you correctly that by "relvalue" you mean "any possible
value from any possible domain that can occur within a relation" ? You
have already pointed out that, acoording to Codd, each defined relation
establishes a new domain of its own. I take it that the values of such
a domain are indeed "relation values". It would then follow, if I
understand you correctly, that all relation values are "relvalues" but
not all "relvalues" are relation values.
Then I think that what you mean by "relvalue" is just "value".
> --> R-tables are ONE possible representation of relvars.
Sorry. R-tables are one possible representation of RELATION VALUES.
Variables simply do not *need* "being represented". They have a name,
a declared type, and they contain a value. Date models variables as a
triple of exactly these three components.
> Hope this clarified.
I wouldn't bet on it.
Cimode
> subset of functions is that you apply all characteritics of a function:
> Funny. For some reason I thought that in math, the functions were
a
> subset of the relations. And therefore, the relations are a
superset
> of the functions. It hurts to discover one's own ignorance.
I have to admit I have struggled with that concept a few years but I
came to the conclusion that relations were indeed a subset and not a
superset of function as you are stating.
Think about it...
For a an ensemblist mathematical set to be declared a subset of an
other ensemblist mathematical set it must first inherit ALL
characteritics of the superset...In short,
IF set1 INCLUDE set2
then set2 (caracteristics on elements of set2) = set1(caracteristics on
elements of set2) + set2(caracteristics on elements of set2)
An application for instance of the above is between rationals and
integers
Integers are a subset of Rationals because they inherit all
characteristics common to ALL Rationals. but have characteristics of
their own....
You can have for instance the following hierarchy
RATIONALS
I
INTEGER DECIMAL
If I follow your reasoning and based on the above. If you state that a
function is a subset of relation then you must admit that a function
ANY function share the characteristics of relation.....Let's see one
characteristic of relations: multidimensionality. ARE ALL functions
multidimensional? linear functions are not multidimensional.
OTOH, if you consider the opposite, meaning relations as a subset of
functions then you realize the definition applies correctly...For
instance, functions use variables to represent dynamic value place
holders. You will realize that characteristics applies to all
functions whether relations, linear etc.....One could represent it as
follows...
FUNCTIONS
RELATIONS LINEAR TRIGO. Etc...
But you seem convinced of the opposite...Thanks for demonstrating
logically your point B4 stating anything. LIstenning.
> > --> relations, relvars, relvalues are on different level of definition.
>
> Do I understand you correctly that by "relvalue" you mean "any possible
> value from any possible domain that can occur within a relation" ? You
> have already pointed out that, acoording to Codd, each defined relation
> establishes a new domain of its own. I take it that the values of such
> a domain are indeed "relation values". It would then follow, if I
> understand you correctly, that all relation values are "relvalues" but
> not all "relvalues" are relation values.
Not quite...Relations are higher level concept than relvar. One Domain
defined at relation level is not the same as a domain from which
values are drawn at attribute data type level. The relationship
between the two is a complex relationship to define (for instance how
operators apply between attribute data type and operator which apply to
the relation as a data type)
Does it make better sense.
> Then I think that what you mean by "relvalue" is just "value".
You are correct.
I personally prefer *value* but some people brought the issue of
*relvalue* in a pedagogical. Some of the people stated that relation
= relvar = relvalue which as you seem to understand is not quite the
same.
> > --> R-tables are ONE possible representation of relvars.
>
> Sorry. R-tables are one possible representation of RELATION VALUES.
You are correct. This definition may lead to confusion. Instead, I
should have stated
"R-Tables are a projection or representation of relvars in a specific
point in time"
which is basically equivalent to
...You are also correct asserting that they represent values rather
than variables. I tend to look at it in a time perspective..I consider
that values are *variable fillers* in time.
Thank you for bringing that out.
> Variables simply do not *need* "being represented". They have a name,
> a declared type, and they contain a value. Date models variables as a
> triple of exactly these three components.
Represented seems to be a non consensual term. Projected seems to be a
better term.
Nevertherless, I am curious about your statement...Do you consider that
relvar do not need to be projected...In that case, how do you operate
them?
Cimode
comments...
> Sorry. R-tables are one possible representation of RELATION VALUES.
> Variables simply do not *need* "being represented". They have a name,
> a declared type, and they contain a value. Date models variables as a
> triple of exactly these three components.
First, I am aware of Date's definition and I do not quite feel
confortable with it because it focuses too much on structural
definition and not enough on the characteristics values extraction from
domains. Neverthless, Date's is logically correct: it's a matter of
perspective.
I also believe some of Date's definition can also lead to
confusion..For instance, Date's definition relvar could lead to
confusion with the definition of an attribute. (both have a name, a
data type and may hold a value in time). If we define, attribute and
relvar alike, one take the risk of confusing them...
For establishing etymological meaning, I advocate Pascal approach
which rather makes a more direct binding between values, domains and
operations possibles on the values. As you probably guessed, it is a
matter of perpective...I consider relation on an ensemblist perspective
rather than algebric perspective....
For instance, Pascal defines a data type as the combination of:
--> a name
--> set of constraints regulating *extraction* of values from a
specific domain
--> set of operators applyable in specifc context
Tony D
> First, I am aware of Date's definition and I do not quite feel
> confortable with it because it focuses too much on structural
> definition and not enough on the characteristics values extraction from
> domains. Neverthless, Date's is logically correct: it's a matter of
> perspective.
>
Well that's reassuring; although you're right on the potential for
overemphasising structure.
> I also believe some of Date's definition can also lead to
> confusion..For instance, Date's definition relvar could lead to
> confusion with the definition of an attribute. (both have a name, a
> data type and may hold a value in time). If we define, attribute and
> relvar alike, one take the risk of confusing them...
>
But I'm not sure how you could confuse an attribute with a relvar. A
relvar is a variable and can indicate different values at different
times. A relation value is value; like an integer value, it never
changes. You can change which relation value a relvar indicates, but
you can't change the relation value itself. So, you can't "change" an
attribute.
[ snippage ]
> For instance, Pascal defines a data type as the combination of:
>
> --> a name
> --> set of constraints regulating *extraction* of values from a
> specific domain
> --> set of operators applyable in specifc context
Which marks a difference between domains and types that I don't
currently hold; the definition of a type as a set of acceptable values
(or equations defining a set of acceptable values) plus a set of
operators over those values seems simpler and no less expressive.
Cimode
Tony D wrote:
> Cimode wrote:
> > First, I am aware of Date's definition and I do not quite feel
> > confortable with it because it focuses too much on structural
> > definition and not enough on the characteristics values extraction from
> > domains. Neverthless, Date's is logically correct: it's a matter of
> > perspective.
> >
>
> Well that's reassuring; although you're right on the potential for
> overemphasising structure.
>
> > I also believe some of Date's definition can also lead to
> > confusion..For instance, Date's definition relvar could lead to
> > confusion with the definition of an attribute. (both have a name, a
> > data type and may hold a value in time). If we define, attribute and
> > relvar alike, one take the risk of confusing them...
> >
>
> But I'm not sure how you could confuse an attribute with a relvar.
distinguished..It's an open highway for unexperienced audiences to
confuse both. This is the last explanation I will give on that
point...I have already answered above and I will stop reexplaining....
> A
> relvar is a variable and can indicate different values at different
> times. A relation value is value; like an integer value, it never
> changes. You can change which relation value a relvar indicates, but
> you can't change the relation value itself. So, you can't "change" an
> attribute.
*change* is a verb that leads to confusion in defining the relationship
between variables and values. *change* supposes a modification of
state which. I prefer the definition of variable as a *value holder*
which give a much more clearer indication .
> [ snippage ]
>
> > For instance, Pascal defines a data type as the combination of:
> >
> > --> a name
> > --> set of constraints regulating *extraction* of values from a
> > specific domain
> > --> set of operators applyable in specifc context
>
> Which marks a difference between domains and types that I don't
> currently hold; the definition of a type as a set of acceptable values
> (or equations defining a set of acceptable values) plus a set of
> operators over those values seems simpler and no less expressive.
You are confusing domain and type...
A domain is what hold the *possible* values...
A data type is defined (thanks to type constraints and operators) to
express *permissible* values extracted from a domain...You could
perceive a type as a subset of domain defining all specific operations
to the syste + inheriting all characteristics of the domain superset +
defining all constraints defining the rules by which the values are
made *permissible* AFTER domain extraction...
Tony D
> > But I'm not sure how you could confuse an attribute with a relvar.
> As I stated B4 if their definition are too similar to be clearly
> distinguished..It's an open highway for unexperienced audiences to
> confuse both. This is the last explanation I will give on that
> point...I have already answered above and I will stop reexplaining....
>
But a variable is time varying; an attribute is, for want of a better
word, an attribute of a relation *value*, so it can't change. I simply
don't see how this confusion can come about.
> *change* is a verb that leads to confusion in defining the relationship
> between variables and values. *change* supposes a modification of
> state which. I prefer the definition of variable as a *value holder*
> which give a much more clearer indication .
>
I don't see that. Values never change. Which value is indicated by a
variable can.
> You are confusing domain and type...
I'm not confusing them; I'm saying that I don't see a need for the
separation between them that you're describing. Can you say why you
would separate them in such a way ?
Cimode
Tony D wrote:
> Cimode wrote:
> > > But I'm not sure how you could confuse an attribute with a relvar.
> > As I stated B4 if their definition are too similar to be clearly
> > distinguished..It's an open highway for unexperienced audiences to
> > confuse both. This is the last explanation I will give on that
> > point...I have already answered above and I will stop reexplaining....
> >
>
> But a variable is time varying; an attribute is, for want of a better
> word, an attribute of a relation *value*, so it can't change. I simply
> don't see how this confusion can come about.
the variable that is time varying but the "variable filler".
Try to imagine a bus at different point during the day circuit and
people that get up in the bus in each station.
Now consider the bus as a variable and the people as value. (variable
placeholders)...What is time varying? the bus? or the set of people
that get in the bus?
The fact that the set of people are drawn from the *citizen* domain and
are unique is a different concept. it is the concept of *uniqueness*
you are confusing with the concept of variability...
> > *change* is a verb that leads to confusion in defining the relationship
> > between variables and values. *change* supposes a modification of
> > state which. I prefer the definition of variable as a *value holder*
> > which give a much more clearer indication .
> >
>
> I don't see that. Values never change. Which value is indicated by a
> variable can.
Neither values, variable or function change. I told you this term is
confusing but you choose to ignore my warning.
Could you stop using that term..Use "vary" instead
> > You are confusing domain and type...
> I'm not confusing them; I'm saying that I don't see a need for the
> separation between them that you're describing. Can you say why you
> would separate them in such a way ?
Because you must define at some point in time what makes a difference
between *possible* values and *permissible* values...*possible* values
are domain values. *permissible* values is a definition of
restrictions should be applied in extraction of possible values from a
specific domain. For instance, if you consider an domain representing
all integer and consider the following relation
odd_numbers(odd_number datatype1)....If you do not make a difference
between datatype1 (data type) and the domain of integer (domain) , how
do you actually implement integrity verification in values stored?
odd_number must only contain odd numbers not all integers..Right?
I am sorry but I can not make more explicit example and analogy...You
really need to get further in RM education.
Tony D
> > But a variable is time varying; an attribute is, for want of a better
> > word, an attribute of a relation *value*, so it can't change. I simply
> > don't see how this confusion can come about.
> In the perspective of any definition of what a function is, it is not
> the variable that is time varying but the "variable filler".
>
That was loose of me; I meant that at different points in time, a
reference to the same variable will return different results (variable
here, and in the following, in the sense of a C/Pascal/etc variable,
not a variable in the mathematical (and indeed FP !), place holder
sense). So the variable appears to be time varying.
> Try to imagine a bus at different point during the day circuit and
> people that get up in the bus in each station.
>
> Now consider the bus as a variable and the people as value. (variable
> placeholders)...What is time varying? the bus? or the set of people
> that get in the bus?
>
Alternatively; each time a person gets on or off the bus, there is a
new and different set of people on the bus. The variable "bus"
indicates a different possible set of people at different times. The
sets of people don't change. (I'm not sure what your parenthetical
(variable placeholders) meant; was it a typo for variable fillers ?)
> The fact that the set of people are drawn from the *citizen* domain and
> are unique is a different concept. it is the concept of *uniqueness*
> you are confusing with the concept of variability...
>
No, I think we're bumping into a minor language and definition barrier.
> > I don't see that. Values never change. Which value is indicated by a
> > variable can.
> Neither values, variable or function change. I told you this term is
> confusing but you choose to ignore my warning.
> Could you stop using that term..Use "vary" instead
>
I think (for once) we're arguing to agree. "Change" and "vary" are very
close to synonyms anyway. What changes over time is the result you get
when you ask for the value indicated by a variable.
> Because you must define at some point in time what makes a difference
> between *possible* values and *permissible* values...*possible* values
> are domain values. *permissible* values is a definition of
> restrictions should be applied in extraction of possible values from a
> specific domain. For instance, if you consider an domain representing
> all integer and consider the following relation
>
> odd_numbers(odd_number datatype1)....If you do not make a difference
> between datatype1 (data type) and the domain of integer (domain) , how
> do you actually implement integrity verification in values stored?
> odd_number must only contain odd numbers not all integers..Right?
>
I can see where you're coming from; I just don't see what it's adding
apart from complexity when compared with "a set of acceptable values
(or equations defining acceptable values)". I suppose in the specific
case of subtyping it's reasonable, but would come under the "equations
defining acceptable values" banner. But, in a system with proper
support for user defined types, the number of times situations like the
one you describe above should occur a tiny (and shrinking) number of
times.
> I am sorry but I can not make more explicit example and analogy...You
> really need to get further in RM education.
We aren't really discussing RM at the moment; we're discussing types,
domains and variables, all of which are surrounds to RM - actually, the
place where FP should be. (In which case the whole discussion of
variables becomes irrelevant.)
Cimode
Tony D wrote:
> Cimode wrote:
> > > But a variable is time varying; an attribute is, for want of a better
> > > word, an attribute of a relation *value*, so it can't change. I simply
> > > don't see how this confusion can come about.
> > In the perspective of any definition of what a function is, it is not
> > the variable that is time varying but the "variable filler".
> That was loose of me; I meant that at different points in time, a
> reference to the same variable will return different results (variable
> here, and in the following, in the sense of a C/Pascal/etc variable,
> not a variable in the mathematical (and indeed FP !), place holder
> sense).
RM is a direct application of Mathematics therefore we are exclusively
at abstract logical level. Logical Abstract level and Logical
implementational must be separated, the latest derives from the first.
RM definitions of relvar and values are purely at logical level.
Pay attention to the terminology your definition brings you to use.
Just think about it...
So the variable ***appears*** to be time varying. Therefore you are
clearly at implementation level. At abstract logical level,
*variables* are not time varying.
Do you understand the difference.
> > Try to imagine a bus at different point during the day circuit and
> > people that get up in the bus in each station.
> >
> > Now consider the bus as a variable and the people as value. (variable
> > placeholders)...What is time varying? the bus? or the set of people
> > that get in the bus?
> >
>
> Alternatively; each time a person gets on or off the bus, there is a
> new and different set of people on the bus. The variable "bus"
> indicates a different possible set of people at different times. The
> sets of people don't change. (I'm not sure what your parenthetical
> (variable placeholders) meant; was it a typo for variable fillers ?)
If you don't bother answering the simple multiple choice question I
asked you and ask another question instead, I will stop answering.
This is my last warning.
> The variable "bus" indicates a different possible set of people at different times.
Do you see what you are stating? You end defining a bus according to a
set of people at different times ? This is an example of fuzzy logic.
A bus is not a set of people: the two are unrelated. According to your
definition, a bus is a set of people varying in time. But a bus is
also a set of wheels and mechanical components varying in-time...
people and wheels do not belong to the same domain and are totally
unrelated.
Following your definition leads to assume that a variable draws values
from several domains. What kind of variable draws values from several
domains. Define it
> > The fact that the set of people are drawn from the *citizen* domain and
> > are unique is a different concept. it is the concept of *uniqueness*
> > you are confusing with the concept of variability...
> >
>
> No, I think we're bumping into a minor language and definition barrier.
I don't think so.
RM concept of uniqueness is what you call variability.
> > > I don't see that. Values never change. Which value is indicated by a
> > > variable can.
> > Neither values, variable or function change. I told you this term is
> > confusing but you choose to ignore my warning.
> > Could you stop using that term..Use "vary" instead
> >
>
> I think (for once) we're arguing to agree. "Change" and "vary" are very
> close to synonyms anyway. What changes over time is the result you get
> when you ask for the value indicated by a variable.
Could you define *result*? result of what? an operation?
You should not define a variable or a value according to a vague term.
> > Because you must define at some point in time what makes a difference
> > between *possible* values and *permissible* values...*possible* values
> > are domain values. *permissible* values is a definition of
> > restrictions should be applied in extraction of possible values from a
> > specific domain. For instance, if you consider an domain representing
> > all integer and consider the following relation
> >
> > odd_numbers(odd_number datatype1)....If you do not make a difference
> > between datatype1 (data type) and the domain of integer (domain) , how
> > do you actually implement integrity verification in values stored?
> > odd_number must only contain odd numbers not all integers..Right?
> >
>
> I can see where you're coming from; I just don't see what it's adding
> apart from complexity when compared with "a set of acceptable values
> (or equations defining acceptable values)". I suppose in the specific
> case of subtyping it's reasonable, but would come under the "equations
> defining acceptable values" banner. But, in a system with proper
> support for user defined types, the number of times situations like the
> one you describe above should occur a tiny (and shrinking) number of
> times.
It allows the property of derivability and coherence because values can
derive from one another. It also has a better reusability in an
implementation layer.
> > I am sorry but I can not make more explicit example and analogy...You
> > really need to get further in RM education.
>
> We aren't really discussing RM at the moment; we're discussing types,
> domains and variables, all of which are surrounds to RM - actually, the
> place where FP should be. (In which case the whole discussion of
> variables becomes irrelevant.)
All my discussion is about RM as I doubt FP as a basis for model for a
simple reason: it is obviously an implementaion model with no logical
abstract model backing it up.
Bob Badour
> Cimode wrote:
>
>>First, I am aware of Date's definition and I do not quite feel
>>confortable with it because it focuses too much on structural
>>definition and not enough on the characteristics values extraction from
>>domains. Neverthless, Date's is logically correct: it's a matter of
>>perspective.
>
> Well that's reassuring; although you're right on the potential for
> overemphasising structure.
>
>>I also believe some of Date's definition can also lead to
>>confusion..For instance, Date's definition relvar could lead to
>>confusion with the definition of an attribute. (both have a name, a
>>data type and may hold a value in time). If we define, attribute and
>>relvar alike, one take the risk of confusing them...
>
> But I'm not sure how you could confuse an attribute with a relvar. A
> relvar is a variable and can indicate different values at different
> times. A relation value is value; like an integer value, it never
> changes.
Ah, but an attribute is a variable a la predicate calculus. See 'bound
variable' and 'free variable' for what I mean.
Bob Badour
> Cimode wrote:
>
>>>But I'm not sure how you could confuse an attribute with a relvar.
>>
>>As I stated B4 if their definition are too similar to be clearly
>>distinguished..It's an open highway for unexperienced audiences to
>>confuse both. This is the last explanation I will give on that
>>point...I have already answered above and I will stop reexplaining....
>
> But a variable is time varying; an attribute is, for want of a better
> word, an attribute of a relation *value*, so it can't change. I simply
> don't see how this confusion can come about.
But an attribute is a variable in the sense that predicate calculus uses
'variable' even if one cannot use imperative statements to change it.
>>*change* is a verb that leads to confusion in defining the relationship
>>between variables and values. *change* supposes a modification of
>>state which. I prefer the definition of variable as a *value holder*
>>which give a much more clearer indication .
>
> I don't see that. Values never change. Which value is indicated by a
> variable can.
>
>
>>You are confusing domain and type...
>
> I'm not confusing them; I'm saying that I don't see a need for the
> separation between them that you're describing. Can you say why you
> would separate them in such a way ?
I have no opinion on the remainder.
Tony D
> But an attribute is a variable in the sense that predicate calculus uses
> 'variable' even if one cannot use imperative statements to change it.
>
Indeed, but that's a different kettle of fish from a relvar, and why I
later clarified the use of variable - I realised (too late) we were
headed for confusing the two.
Tony D
> Ah, but an attribute is a variable a la predicate calculus. See 'bound
> variable' and 'free variable' for what I mean.
Indeed. But an attribute is not the same kind of variable as a relvar.
Cimode
Bob Badour wrote:
> Tony D wrote:
>
> > Cimode wrote:
> >
> >>>But I'm not sure how you could confuse an attribute with a relvar.
> >>
> >>As I stated B4 if their definition are too similar to be clearly
> >>distinguished..It's an open highway for unexperienced audiences to
> >>confuse both. This is the last explanation I will give on that
> >>point...I have already answered above and I will stop reexplaining....
> >
> > But a variable is time varying; an attribute is, for want of a better
> > word, an attribute of a relation *value*, so it can't change. I simply
> > don't see how this confusion can come about.
>
> But an attribute is a variable in the sense that predicate calculus uses
> 'variable' even if one cannot use imperative statements to change it.
varying. Variable is a value holder whith its content extracted from a
domain (values) that vary over time. I have proved that point with an
analogy and a question, Tony D has refuses to respond to because it
constitutes a paradow to his definition that proves him wrong.
Cimode
Anything in RM that can be a value holder in RM indeed as relvar. An
attribute actually is an *elementary* relvar. It has a data type
defining all restrictions applied on the values that are drawn from
some domain.
Cimode
assumption that I would be a crank. LOL
Tony D
> > But an attribute is a variable in the sense that predicate calculus uses
> > 'variable' even if one cannot use imperative statements to change it.
> Again a variable be it an elementary relvar (attribute), is not
> varying. Variable is a value holder whith its content extracted from a
> domain (values) that vary over time. I have proved that point with an
> analogy and a question, Tony D has refuses to respond to because it
> constitutes a paradow to his definition that proves him wrong.
>
I think we are at cross purposes on the definition of variable here.
Variables come in (at least) two distinct kinds : the 3GL kind, which
is basically a name for an updateable bit of store, or the
mathematical/propositional logic place holder kind. So far, I've been
going on the basis that relvars are of the 3GL kind. Is this merely a
Tutorial D-ism ?
I don't think there is any "paradow", or even paradox (which I assume
you meant) here. Only a difference in definition.
Cimode
Tony D wrote:
> Cimode wrote:
>
> > > But an attribute is a variable in the sense that predicate calculus uses
> > > 'variable' even if one cannot use imperative statements to change it.
>
> > Again a variable be it an elementary relvar (attribute), is not
> > varying. Variable is a value holder whith its content extracted from a
> > domain (values) that vary over time. I have proved that point with an
> > analogy and a question, Tony D has refuses to respond to because it
> > constitutes a paradow to his definition that proves him wrong.
> >
>
> I think we are at cross purposes on the definition of variable here.
> Variables come in (at least) two distinct kinds : the 3GL kind, which
> is basically a name for an updateable bit of store, or the
> mathematical/propositional logic place holder kind. So far, I've been
> going on the basis that relvars are of the 3GL kind. Is this merely a
> Tutorial D-ism ?
implementation language definition level.
Defining variables at implementation level produces anything but
confusion...
Tony D
> > I think we are at cross purposes on the definition of variable here.
> > Variables come in (at least) two distinct kinds : the 3GL kind, which
> > is basically a name for an updateable bit of store, or the
> > mathematical/propositional logic place holder kind. So far, I've been
> > going on the basis that relvars are of the 3GL kind. Is this merely a
> > Tutorial D-ism ?
> Variable and values are defined at logical abstract level not at
> implementation language definition level.
> Defining variables at implementation level produces anything but
> confusion...
This is rapidly becoming circular. Can you accept that the term
variable is used in two different ways, *whatever level of abstraction
you may be talking about* ? Can you pin down, once and for all, which
sense of the word variable you are using ? Clearly, Tutorial D uses the
term "relvar" or "relation variable" in the sense of a 3GL kind of
updateable variable. Are you using "relvar" in the sense of a
mathematical, non-updateable variable ?
Cimode
I know since the beginning that you are defining variable at
implementation level. I warned you about it but you don't listen.
Variable can be defined and manipulated soundly only at logical level.
Manipulating and defining them at implementation such as 3GL level
leads only to confusion. You don't define logical models principles
through defining implementation. Onlyt the opposite works..
Tony D
Could you answer the question ? "Yes" or "no" will do fine.
Cimode
analogy and variables, why would I comply?
Cimode
Obvious.
An attribute is nothing but an single-domain elementary relvar whose
values are defined by data type definition. Confusion made by Tony D
is that values holding place in relvars change: they don't --> they
belong to a domain from which they are simply extracted.
Cimode
mathematical application of mathematics in RM.
An attribute is indeed an single domain elementary relvar.