> From: josh@agliodbs.com
> To: pgsql-hackers@postgresql.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