Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fOm9N-0007rT-Jp for pgsql-docs@arkaria.postgresql.org; Fri, 01 Jun 2018 15:39:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fOm9J-0007us-7s for pgsql-docs@arkaria.postgresql.org; Fri, 01 Jun 2018 15:39:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fOm9I-0007ug-TS for pgsql-docs@lists.postgresql.org; Fri, 01 Jun 2018 15:39:29 +0000 Received: from mail-oi0-x22f.google.com ([2607:f8b0:4003:c06::22f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fOm9E-00018J-UM for pgsql-docs@postgresql.org; Fri, 01 Jun 2018 15:39:28 +0000 Received: by mail-oi0-x22f.google.com with SMTP id e8-v6so4672865oii.2 for ; Fri, 01 Jun 2018 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YrU6mnPOXmGdzyK2NCziuJ/SnuUxwLBp+7jJVxets7g=; b=KtFG2GeudtUMXUzoJ9y/E3wZwqdOLWhzYATa+bZwmfb3ftMQcR4d75kwc3Z2dT69M8 4n8affGIugAazAcZKJJeuYW/y2JxQbiB2YnBnodelCyTmKpNVDWpwPDo3HeSin7nP2ov dtz3gkk9qPv6jlDBLkT9yZD5U6Yk/2HKnEhHu1kEt8sXbw+J63ZHlQgs1P1SnfDzIOPZ pyT+clJLCX0gDq09FvI8UJMDUVUUQl6VQ5DM3qLOUegP3uibgxtgsfx9eDQBgxjHkpCz dLVy+pLsJIydsWsZ/SQV5FWoQYPZ5wWxXLZBUJN/UftXam0HfMg1dDw1+DoZs4hm40kX jCjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YrU6mnPOXmGdzyK2NCziuJ/SnuUxwLBp+7jJVxets7g=; b=H0o/Wrq/xjhtbZdjWG5wk15NxGF8ZDLML9RLICz6FHWgZeFW0FelRRJDIek2aMBcz6 taM+eSlX3ggstlB1nyD3aJb7K/uY4QkdF5PXcG9UwIkx6GtWIU2CoyheHnkI1/hZBF1r PYBoROx0nRu7LSsqnSKBZLgQBMC+50aGc0etQKrBkahJERO7ZiI4Gva837dJJ+7z2HJl o5iL8Mw3g/ci8OdBO0//8H80mLj71cjKmNdGaYCzhv7/PBX8RH7KxMXgpABkK9kBMQWJ j0bI7NpCNJ4W4BdM2xK97pZMos8aY2j3HLYP2mvdNUwsA+AY8w4FN8ayKnVLJ8Encuxe 1AmA== X-Gm-Message-State: APt69E1AZgsh0WgtgLAW9vKtoorqWfl26QBk8XjM0a2Or8H5Z2XUoOJI w/N8GQnE8EUK2ttJgPtfVkIn4PworGBsSB+XGd83G0f0 X-Google-Smtp-Source: ADUXVKLnsHA/ZNOUpL8JNOosJ6yc5niHTelcxmCug0/fviMVxCuHngJUW1d6CZOOILG2IFDUaO3qBTm3f3RpRsHyLIg= X-Received: by 2002:aca:f594:: with SMTP id t142-v6mr1355628oih.56.1527867562929; Fri, 01 Jun 2018 08:39:22 -0700 (PDT) MIME-Version: 1.0 References: <20180526165648.GB12510@momjian.us> In-Reply-To: <20180526165648.GB12510@momjian.us> From: Alexander Korotkov Date: Fri, 1 Jun 2018 18:39:11 +0300 Message-ID: Subject: Re: Improving docs for strict_word_similarity() To: Bruce Momjian Cc: pgsql-docs@postgresql.org, Teodor Sigaev Content-Type: multipart/alternative; boundary="0000000000005a36f6056d9663d9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000005a36f6056d9663d9 Content-Type: text/plain; charset="UTF-8" Hi, Bruce! On Sat, May 26, 2018 at 7:56 PM Bruce Momjian wrote: > While creating the release notes, I was confused by the description for > strict_word_similarity(), particularly "extent boundaries". The > attached patch clarifies, at least for me, how word_similarity() and > strict_word_similarity() differ. > Thank you for your efforts on improving documentation of pg_trgm. However, I don't find all of them correct. I've following notes regarding the edits you propose. --- 112,119 ---- real ! Same as word_similarity(text, text), but ! considers the set of trigrams to be of the same length. This doesn't look a correct description. In short, strict_word_similarity() is searching for extent of words in the second string, which is best match for the first string. So, this function takes care about using whole words from the second strings, not parts of words. However, this is not matter of length of trigrams sets. --- 164,182 ---- This function returns a value that can be approximately understood as the greatest similarity between the first string and any substring of the second string. However, this function does not add padding to the boundaries of ! the extent. Thus, the number of additional characters present in the ! second string is not considered, except for the mismatched word boundry. This looks correct for me. ! The function strict_word_similarity(text, text) ! does consider additional characters in the second string. In the ! example above, strict_word_similarity(text, text) ! would use the full trigram for the second string when computing ! similarity, not just the part of the trigram that matches the ! first string. For example, it would use the {" w"," ! wo","wor","ord","rds","ds "}, which corresponds to the whole ! word 'words'. After your edits, it looks like strict_word_similarity() matches full set of first string trigrams to full set of second string trigrams. However, this is description of just similarity() function. Actually, strict_word_similarity() matches set of trigrams of first string to set of trigrams of conjuncted subset of second string words. --- 189,197 ---- Thus, the strict_word_similarity(text, text) function ! is useful for finding the similarity to whole words, while word_similarity(text, text) is more suitable for ! finding the similarity for parts of words. This also looks correct to me. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --0000000000005a36f6056d9663d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Bruce!

On Sat, May 26, 2018 at 7:56 PM Bruce Momjian <= ;bruce@momjian.us> wrote:
While creating the rel= ease notes, I was confused by the description for
strict_word_similarity(), particularly "extent boundaries".=C2=A0= The
attached patch clarifies, at least for me, how word_similarity() and
strict_word_similarity() differ.

Thank = you for your efforts on improving documentation of pg_trgm.
H= owever, I don't find all of them correct.=C2=A0 I've following note= s regarding
the edits you propose.

= --- 112,119 ----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </entry>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <entry><type>real</type= ></entry>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <entry>
!=C2=A0 =C2=A0 =C2=A0 =C2=A0 Same as <function>word_similarity(= text, text)</function>, but
!=C2=A0 =C2=A0 =C2=A0 =C2=A0 co= nsiders the set of trigrams to be of the same length.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 </entry>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</= row>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<row>
This doesn't look a correct description.=C2=A0 In short,= =C2=A0strict_word_similarity() is searching
for extent of words i= n the second string, which is best match for the first string.
So= , this function takes care about using whole words from the second strings,=
not parts of words.=C2=A0 However, this is not matter of length = of trigrams sets.

--- 164,182 ----
<= div>=C2=A0 =C2=A0 =C2=A0This function returns a value that can be approxima= tely understood as the
=C2=A0 =C2=A0 =C2=A0greatest similarity be= tween the first string and any substring of the second
=C2=A0 =C2= =A0 =C2=A0string.=C2=A0 However, this function does not add padding to the = boundaries of
!=C2=A0 =C2=A0 the extent.=C2=A0 Thus, the number o= f additional characters present in the
!=C2=A0 =C2=A0 second stri= ng is not considered, except for the mismatched word boundry.
=C2= =A0 =C2=A0 </para>

This looks correct = for me.

!=C2=A0 =C2=A0 The function <funct= ion>strict_word_similarity(text, text)</function>
!=C2= =A0 =C2=A0 does consider additional characters in the second string.=C2=A0 = In the
!=C2=A0 =C2=A0 example above, <function>strict_word_= similarity(text, text)</function>
!=C2=A0 =C2=A0 would use = the full trigram for the second string when computing
!=C2=A0 =C2= =A0 similarity, not just the part of the trigram that matches the
!=C2=A0 =C2=A0 first string. For example, it would use the <literal>= {" w","
!=C2=A0 =C2=A0 wo","wor",&q= uot;ord","rds","ds "}</literal>, which corre= sponds to the whole
!=C2=A0 =C2=A0 word <literal>'words= '</literal>.

After your edits, it = looks like=C2=A0strict_word_similarity() matches full
set of first string trigrams to full set = of second string trigrams.=C2=A0 However,
this is description of just=C2=A0similarity() functio= n.=C2=A0 Actually,
strict_word_similarity() matches set of trigrams= of first string to
<= span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;fon= t-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-= weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tran= sform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255= ,255);text-decoration-style:initial;text-decoration-color:initial;float:non= e;display:inline">set of trigrams of conjuncted subset o= f second string words.
=

--- 189,197 ----
=C2=A0=C2=A0
= =C2=A0 =C2=A0 <para>
=C2=A0 =C2=A0 =C2=A0Thus, the <func= tion>strict_word_similarity(text, text)</function> function
<= div>!=C2=A0 =C2=A0 is useful for finding the similarity to whole words, whi= le
=C2=A0 =C2=A0 =C2=A0<function>word_similarity(text, text= )</function> is more suitable for
!=C2=A0 =C2=A0 finding th= e similarity for parts of words.
=C2=A0 =C2=A0 </para>

This also looks correct to me.

------
Alexander Korotkov=
Postgres Professional:=C2=A0http://www.postgrespro.com<= br style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-= style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we= ight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transf= orm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,2= 55);text-decoration-style:initial;text-decoration-color:initial">The Russian Postgres Company=C2=A0
--0000000000005a36f6056d9663d9--