Re: Fraud Number 3: U-Gene

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). 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.) Received on Tue Jun 20 2006 - 16:20:00 CEST