Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

From: Cimode <cimode_at_hotmail.com>
Date: 3 May 2007 04:42:31 -0700
Message-ID: <1178192551.663643.78380_at_o5g2000hsb.googlegroups.com>


On May 3, 12:05 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:1178174344.866049.272810_at_h2g2000hsg.googlegroups.com...
>
>
>
> > On 2 mai, 21:47, paul c <toledobythe..._at_oohay.ac> wrote:
> > > Cimode wrote:
>
> > > ...
>
> > > > Brian,
>
> > > > Don't you think you are overcomplicating things?
>
> > > I certainly do. RT isn't as complicated or subtle as this thread is
> > > making it out to be.
> > I was not thinking about *subtleness*. I am having trouble following
> > Brian's wordy line of thought. I am not sure he and I have do not
> > have the same perception of what logical and physical independence
> > is. I was also refering to terms I am not familiar with such as
> > *database state*. To me they are totally foreign to RM formal
> > theory.
>
> > Maybe you could clarify. Thanks.
> > Regards...
>
> > [Snipped]
>
> I think that "state" is a fundamental concept in computing. As such, Brian
> and others ought to be able to use it to communicate rather precisely,
> without needing to present a formal definition. If you know what a
> "database" is and you know what a "state" is, I think you know what a
> "database state" is.
>
> Having said that, I'll admit that I'm often lost by Brian's argument. He
> seems to be arguing that transaction atomicity is an undesirable feature of
> our data model. If I'm reading that right, I abandon the effort to
> understand the rest of what he's saying.
I am not sure formal theory requires the need for *state* concept. The fundamental concepts of relation value, relations variable or simply relation are sufficient to describe the evolution of a specific relation in time. What does bringing concepts that are clearly OO oriented (I have heard about db *state*, db *instantiation*, db *instance*) add to the equation? Not much I am afraid.

Quite frankly, I am not interested that much into a terminology debate but rather into *how interpolation could eventually serve as a way to handle missing information*. So far, Vadim has brought some interesting insight through the addition of a theorical regression method implemented in SQL (I will try to adapt it as soon as I find sometime). I am afraid the discussions about *design quality*, *SQL critiscism* are in fact off topic. Received on Thu May 03 2007 - 13:42:31 CEST

Original text of this message