Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
Date: Thu, 03 May 2007 14:52:07 GMT
Message-ID: <rGm_h.7590$Hd1.7231_at_trndny07>
"Cimode" <cimode_at_hotmail.com> wrote in message
news: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.
>
I apologize for my part in hijacking your thread.
One thing you might want to pursue that would interest me is "what kinds of
data lend themselves to interpolation, regression, or any other kind of
smoothing, and what kinds do not."
Is it only numerical data that lend themselves to the kind of approximation and/or inference that you are exploring? Received on Thu May 03 2007 - 16:52:07 CEST