Re: Example of expression bias?

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Wed, 21 Jun 2006 15:13:41 GMT
Message-ID: <Fmdmg.79352$P2.3278_at_tornado.ohiordc.rr.com>

Cimode wrote:

> J M Davitt wrote:
> 

>>Cimode wrote:
>>
>>>J M Davitt wrote:
>>>
>>>
>>>>paul c wrote:
>>>>
>>>>
>>>>>Tony D wrote:
>>>>>
>>>>>
>>>>>>...
>>>>>>
>>>>>>
>>>>>>>A data type in RM = (a domain1 to draw values from) + (restrictions
>>>>>>>implemented on domain1 --> domain constraint) + (operators that can be
>>>>>>>defined using that data type)
>>>>>>>...
>>>>>>
>>>>>>This may be one definition of a data type (not quite one I'd accept, as
>>>>>>we've thrashed over elsewhere), but there is nothing particular to RM
>>>>>>about this.
>>>>>>...
>>>>>
>>>>>"domain constraint" seems an uncommon term to me because we usually talk
>>>>>of constraints on relations. but I often puzzle over constraints,
>>>>>thinking that they could be as fundamental as any other notion, e.g.,
>>>>>once one arrives at a similar conception of relations to Codd's, one
>>>>>could view everything that one does with them as either adding or
>>>>>subtracting constraints.
>>>>
>>>>CJD calls them type constraints; they define the set of values
>>>>that constitute the type. Types are named, so the sets are named.
>>>>
>>>>The only thing I'd argue about in Cimode's definition is that
>>>>operators are part of the data type. In fact, D+D make the point
>>>>that the declaration of operators is orthogonal to the declaration
>>>>of types -- given that the types are extant before the operators.
>>>
>>>No need to argue on that, operators are indeed a part of a data type
>>>definition. I would personally define *possible* operators applyable
>>>at domain level then define attribute *permissible* operators at data
>>>type level .
>>
>>Then, would you explain why D+D are wrong? And you should probably
>>elaborate on what the "domain level" and the "data type level" are.
>
> Domain level refers to possible value.

*This* is why you think D+D are wrong?

Considering the possibility that you have as much difficulty reading as you do writing, let me recap:
- You said that operators are a part of a data type - I said that D+D said they are not - with the exception of the

   selector and the /THE_/operators.
- You said, "No need to argue...operators are...part of a data type."

Again: why do you feel D+D are wrong?

>>And, while you're at it, explain in which data type definition [sic]
>>an operation like, say, division, defined on integers and returning
>>a rational, belongs?

> 
> Data type definition is independent of output.
> In RM, data type definition concerns exclusively input (IPO speaking)
> because the primary focus of RM data type definition is datum integrity
> 'as a value holder'.

Why do you bring up input and output? What is "IPO?" What does type declaration have to do with integrity? What does "integrity 'as a value holder'" mean?

Are we to understand that the results of operations are typeless?

> operations between randomly defined data types are a much more complex > issue. It's pure ensemblist math. It has not been discussed.

What's random about integers and rationals? How can operations be "much more complex" if their declaration is part of the data type declaration?

>>[snip]
Received on Wed Jun 21 2006 - 17:13:41 CEST