Skip site navigation (1) Skip section navigation (2)

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

From: Jim Nasby <decibel(at)decibel(dot)org>
To: Tasneem Memon <tasneememon(at)hotmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: To all the pgsql developers..Have a look at the operators proposed by me in my research paper.
Date: 2007-06-02 00:13:54
Message-ID: 082EA5EC-E37C-4A0D-996C-2281721073EF@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun 1, 2007, at 8:24 AM, Tasneem Memon wrote:
> NEAR
>
> It deals with the NUMBER and DATE datatypes simulating the human  
> behavior and processing the

Why just number and date?

> information contained in NEAR in the same way as we humans take it.  
> This is a binary operator with the syntax:
> op1  NEAR  op2
> Here, the op1 refers to an attribute, whereas op2 is a fixed value,  
> both of the same datatype.
> Suppose we want a list of all the VGAs, price of which should be  
> somewhere around 30$ .. the query will look like:
>
> SELECT    *
> FROM      accessories
> WHERE    prod_name = ‘VGA’
> AND                prod_price NEAR 30
>
> A query for the datatype DATE will look like:
>
> SELECT    *
> FROM      sales
> WHERE    item = ’printer’
> AND                s_date NEAR 10-7-06
>
>
> The algorithm for the NEAR operator works as follows:
>
> 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.

How would one change 0.8 to some other value?

> 4.      It is very much possible that the result set is empty since  
> no values within the range exist in the column. Thus, the algorithm  
> checks for empty result set, and in that case, decreases the target  
> md by 0.2 and jumps to step 3. This is the reason big margins to  
> the op2 are added.
> 5.      In case there are no values in op1 that are between m1 and  
> m2 (where the membership degree of the values with respect to NEAR  
> becomes 0.1) and the result set is empty, the algorithm fetches the  
> two nearest values (tuples) to op2, one smaller and one larger than  
> the op2, as the result.
>
> The algorithm will give an empty result only if the table referred  
> to in the query is empty.
>
> 2. NOT NEAR
>
>             This operator is also a binary operator, dealing with  
> the datatype NUMBER and DATE. It has the syntax:
> op1  NOT NEAR  op2
> The op1 refers to an attribute, whereas op2 is a fixed value, both  
> of the same data type.
>             A query containing the operator looks like:
>
> SELECT id, name, age, history
> FROM    casualties
> WHERE  cause = ‘heart attack’
> AND      age NOT NEAR 55
>
> Or suppose we need a list of some event that is not clashing with  
> some commitment of ours:
>
> SELECT *
> FROM    events
> WHERE  e_name= ‘concert’
> AND      date NOT NEAR 8/28/2007
>
> The algorithm for NOT NEAR works like this:
> First of all it adds the margins to the op2, i.e. m1 and m2,  
> dynamically on both the sides, considering the value op2 contains.
> op1 values outside the scope of the op2 (m1, m2) are retrieved and  
> added to the result.
> If the result set is empty, the farthest values within the op2  
> fuzzy set (those possessing the least membership degree) are  
> retrieved. This is done by continuing the search from values with  
> md=0.1 till the md=0.6, where the md for NOT NEAR reaches 0.4.

Why isn't this just the exact opposite set of NEAR?
--
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)



In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-06-02 01:11:54
Subject: Re: syslogger line-end processing infelicity
Previous:From: Jim NasbyDate: 2007-06-02 00:08:26
Subject: Re: Postmaster startup messages

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group