# Re: Example of expression bias?

From: Cimode <cimode_at_hotmail.com>
Date: 21 Jun 2006 08:51:26 -0700

J M Davitt wrote:
> 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
> >>>>>>...
> >>>>>
> >>>>>"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
Not quite. I say they are a part of data type definition.
> - 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?
What id "D+D" definition? I am not familiar with acronyms.
> >>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?"
IPO stands for Input Process Output computational basic definition.

Input is what gets in, Process is what occurs in the middle and Output is what is produced.

What does
> type declaration have to do with integrity? What does "integrity
> 'as a value holder'" mean?
data type application on relvar is what allows to define contraints on values that can or can not be in datum. That's datum integrity at elementary level.
I suggest you read a bit. I can not educate you.

> Are we to understand that the results of operations are typeless?
I have not said they are typeless. I have said they are an independent issue than the one we are discussing. Of course they are not typeless (thanks god).
> > 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?
random was meant as *arbitrarily* defined. RM does not put restriction on Integers and Rationals. A data type may be anything. Integers and Rationals are simple ensembles of math still they can produce a different data types in output for a one type operation. RM does not restrict output data type to such ensembles.

How can operations be
> "much more complex" if their declaration is part of the data type
> declaration?
See above...
> >>[snip]
Received on Wed Jun 21 2006 - 17:51:26 CEST

Original text of this message