Re: To all the pgsql developers..Have a look at the operators proposed by me in my researc

From: Tasneem Memon <tasneememon(at)hotmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: To all the pgsql developers..Have a look at the operators proposed by me in my researc
Date: 2007-06-16 00:46:55
Message-ID: BAY126-W528DCA6A5AF23A83DF4364A31D0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> From: josh(at)agliodbs(dot)com> To: pgsql-hackers(at)postgresql(dot)org> Tasneem,> > > > The margins to the op2, i.e. m1 and m2, are added dynamically on > > > both the sides, considering the value it contains. To keep this > > > margin big is important for a certain reason discussed later.> > > The NEAR operator is supposed to obtain the values near to the op2, > > > thus the target membership degree(md) is initially set to 0.8.> > > The algorithm compares the op1(column) values row by row to the > > > elements of the set that NEAR defined, i.e. the values from md 1.0 > > > to 0.8, adding matching tuples to the result set.> > Are we talking about a mathematical calculation on the values, or an algorithm > against the population of the result set? I'm presuming the latter or you > could just use a function. If so, is NEAR an absolute range or based on > something logarithmic like standard deviation?>

It is based on fuzzy logic.. we take the operand2 (which is a crisp value, given by the end user) as a fuzzy set.. assign membership degree to its elements.. and then get the values between 1.0 to 0.8 as the values NEAR to the operand2, and output those as the result.
I have made the initial membership degree constant, i.e 0.8. But that doesn’t mean that the size of the set defined by NEAR (md=0.8) remains constant. The larger the operand2 set, the larger the range of the set defined by NEAR.

> Beyond that, I would think that this mechanism would need some kind of extra > heuristics to be at all performant, otherwise you're querying the entire > table (or at least the entire index) every time you run a query. Have you > given any thought to this?>

Yes u are right.. that’s my main concern. Here I have just put forward an idea to incorporate fuzziness in current database systems through the ANSI SQL; but still I have to look into that problem if it is to be functional at all with large amount of data.

Tasneem Memon

_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline

Browse pgsql-hackers by date

  From Date Subject
Next Message Tasneem Memon 2007-06-16 01:27:44 Re: To all the pgsql developers..Have a look at the operators proposed by me in my researc
Previous Message Joshua D. Drake 2007-06-16 00:22:39 Re: CSVlog vs tabs