guix search doesn't weigh word matches higher than subword matches

  • Open
  • quality assurance status badge
Details
4 participants
  • aurtzy
  • bokr
  • Richard Sent
  • Simon Tournier
Owner
unassigned
Submitted by
Richard Sent
Severity
normal
R
R
Richard Sent wrote on 1 May 04:18 +0200
(address . bug-guix@gnu.org)
87bk5qcm1w.fsf@freakingpenguin.com
Hi Guix!

When running guix search, relevance in synopsis and description fields
are computed strictly by the number of matches, both as a word and as a
subword. Ideally, if a search string matches an isolated word in a
search, that result should be considered more relevant than simply
matching a subword, even multiple times.

To illustrate, imagine trying to find what package provides the `rsh`
binary and running running `$ guix search rsh`. This binary is part of
`inetutils` and the description field contains:

Toggle quote (4 lines)
> Inetutils is a collection of common network programs, such as an ftp
> client and server, a telnet client and server, an rsh client and
> server, and hostname.

Most likely, this is what the user is interested in. However, inetutils
does not show up until roughly the ~75th result with a relevance of 2
(the lowest possible relevance).

Almost every search result beforehand contains the string "rsh" as a
component of another word, such as "marshaling", "powershell", and
"hershey". However, these match multiple times and are weighted
significantly higher.

Ideally, guix search should rate inetutils higher because the string
"rsh" occurs as its own word, not as a component of another, unrelated
word. (Very, very people would search "rsh" looking for matches with
"hershey", even if "hershey" occurs multiple times.)

Another example of where this can happen is with "dig", part of the bind
package. Searching for "dig" returns garbage because "dig" is a common
subword. Bind is scored with a relevance of 2, even though bind's
description emphasises that dig is part of it.

This would improve the experience when searching with strings that
commonly occur as subwords.

Since this change can't occur in a vacuum, care should be taken not to
reduce the effectiveness of other reasonably forseeable search queries.

--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
B
B
bokr wrote on 1 May 15:45 +0200
(name . Richard Sent)(address . richard@freakingpenguin.com)(address . 70689@debbugs.gnu.org)
20240501134505.GA10144@LionPure
On +2024-04-30 22:18:03 -0400, Richard Sent wrote:
Toggle quote (49 lines)
> Hi Guix!
>
> When running guix search, relevance in synopsis and description fields
> are computed strictly by the number of matches, both as a word and as a
> subword. Ideally, if a search string matches an isolated word in a
> search, that result should be considered more relevant than simply
> matching a subword, even multiple times.
>
> To illustrate, imagine trying to find what package provides the `rsh`
> binary and running running `$ guix search rsh`. This binary is part of
> `inetutils` and the description field contains:
>
> > Inetutils is a collection of common network programs, such as an ftp
> > client and server, a telnet client and server, an rsh client and
> > server, and hostname.
>
> Most likely, this is what the user is interested in. However, inetutils
> does not show up until roughly the ~75th result with a relevance of 2
> (the lowest possible relevance).
>
> Almost every search result beforehand contains the string "rsh" as a
> component of another word, such as "marshaling", "powershell", and
> "hershey". However, these match multiple times and are weighted
> significantly higher.
>
> Ideally, guix search should rate inetutils higher because the string
> "rsh" occurs as its own word, not as a component of another, unrelated
> word. (Very, very people would search "rsh" looking for matches with
> "hershey", even if "hershey" occurs multiple times.)
>
> Another example of where this can happen is with "dig", part of the bind
> package. Searching for "dig" returns garbage because "dig" is a common
> subword. Bind is scored with a relevance of 2, even though bind's
> description emphasises that dig is part of it.
>
> This would improve the experience when searching with strings that
> commonly occur as subwords.
>
> Since this change can't occur in a vacuum, care should be taken not to
> reduce the effectiveness of other reasonably forseeable search queries.
>
> --
> Take it easy,
> Richard Sent
> Making my computer weirder one commit at a time.
>
>
>

I like your proposal :)

I'm wondering how [1] compares in what it does for your use(ful) case.
(I am not familiar with Hyper Estraier beyond being prompted for gnu.org searching)


--
Regards,
Bengt Richter
A
A
aurtzy wrote on 13 Sep 09:13 +0200
Re: guix search doesn't weigh word matches higher than subword matches
(address . 70689@debbugs.gnu.org)
b1592bd0-cd96-4e3a-9f79-a7b793cd5d5c@gmail.com
Hi Richard and bokr,

I've proposed changes to relevance scoring that should help with this
issue, if you'd like to try it out here: https://issues.guix.gnu.org/73220

Cheers,

aurtzy

> On +2024-04-30 22:18:03 -0400, Richard Sent wrote:
> > Hi Guix!
> >
> > When running guix search, relevance in synopsis and description fields
> > are computed strictly by the number of matches, both as a word and as a
> > subword. Ideally, if a search string matches an isolated word in a
> > search, that result should be considered more relevant than simply
> > matching a subword, even multiple times.
> >
> > To illustrate, imagine trying to find what package provides the `rsh`
> > binary and running running `$ guix search rsh`. This binary is part of
> > `inetutils` and the description field contains:
> >
> > > Inetutils is a collection of common network programs, such as an ftp
> > > client and server, a telnet client and server, an rsh client and
> > > server, and hostname.
> >
> > Most likely, this is what the user is interested in. However, inetutils
> > does not show up until roughly the ~75th result with a relevance of 2
> > (the lowest possible relevance).
> >
> > Almost every search result beforehand contains the string "rsh" as a
> > component of another word, such as "marshaling", "powershell", and
> > "hershey". However, these match multiple times and are weighted
> > significantly higher.
> >
> > Ideally, guix search should rate inetutils higher because the string
> > "rsh" occurs as its own word, not as a component of another, unrelated
> > word. (Very, very people would search "rsh" looking for matches with
> > "hershey", even if "hershey" occurs multiple times.)
> >
> > Another example of where this can happen is with "dig", part of the
bind
> > package. Searching for "dig" returns garbage because "dig" is a common
> > subword. Bind is scored with a relevance of 2, even though bind's
> > description emphasises that dig is part of it.
> >
> > This would improve the experience when searching with strings that
> > commonly occur as subwords.
> >
> > Since this change can't occur in a vacuum, care should be taken not to
> > reduce the effectiveness of other reasonably forseeable search queries.
> >
> > --
> > Take it easy,
> > Richard Sent
> > Making my computer weirder one commit at a time.
> >
> >
> >
>
> I like your proposal :)
>
> I'm wondering how [1] compares in what it does for your use(ful) case.
> (I am not familiar with Hyper Estraier beyond being prompted for
gnu.org searching)
>
>
> --
> Regards,
> Bengt Richter
S
S
Simon Tournier wrote on 13 Sep 17:08 +0200
Re: bug#70689: guix search doesn't weigh word matches higher than subword matches
(name . Richard Sent)(address . richard@freakingpenguin.com)
877cbfvbfg.fsf@gmail.com
Hi,

On Tue, 30 Apr 2024 at 22:18, Richard Sent <richard@freakingpenguin.com> wrote:

Toggle quote (8 lines)
>> Inetutils is a collection of common network programs, such as an ftp
>> client and server, a telnet client and server, an rsh client and
>> server, and hostname.
>
> Most likely, this is what the user is interested in. However, inetutils
> does not show up until roughly the ~75th result with a relevance of 2
> (the lowest possible relevance).

Using Guix 056910e, I get:

$ guix search rsh | recsel -CP name | grep -n inetutils
76:inetutils

Then using the proposed v2 patch#73220 [1], I get:

$ ./pre-inst-env guix search rsh | recsel -CP name | grep -n inetutils
34:inetutils

Well, that’s not perfect but a bit better.


Toggle quote (5 lines)
> Almost every search result beforehand contains the string "rsh" as a
> component of another word, such as "marshaling", "powershell", and
> "hershey". However, these match multiple times and are weighted
> significantly higher.

Well, if we consider the current implementation, the relevance scoring
reads for the highest:

4 * 0 name
+ 2 * 0 upstream-name
+ 1 * 0 outputs
+ 3 * 2 * 1 synopsis
+ 2 * 4 * 1 description
+ 1 * 0 file-name
= 14

where it means: field-weigh * match * weight-match

Compared to inetutils:

4 * 0 name
+ 2 * 0 upstream-name
+ 1 * 0 outputs
+ 3 * 0 synopsis
+ 2 * 1 * 1 description
+ 1 * 0 file-name
= 2

Well, this case cannot be improved much. First, the field-weights are
almost optimal [2]. Second the number of occurrences depends on the
description; maybe it could be improved, I have not checked yet.

And v2 of #73220 replace the value of weight-match: the term ’rsh’ in
“an rsh client” should have an higher score than in “uses `json.Marshal'
and `json.Unmarshal'”.

In other words, it reads:

4 * 0 name
+ 2 * 0 upstream-name
+ 1 * 0 outputs
+ 3 * 0 synopsis
+ 2 * 1 * 3 description
+ 1 * 0 file-name
= 6

I think this address your suggestion, I guess.


Toggle quote (5 lines)
> Ideally, guix search should rate inetutils higher because the string
> "rsh" occurs as its own word, not as a component of another, unrelated
> word. (Very, very people would search "rsh" looking for matches with
> "hershey", even if "hershey" occurs multiple times.)

Again, considering the case at hand: If instead of 3 randomly picked in
v2 of #73220, we would pick 7, then inetutils is ranked first.

Yeah, maybe 3 isn’t enough… And maybe 7 is a good choice.

Do you have other examples than ’rsh’?


Toggle quote (5 lines)
> Another example of where this can happen is with "dig", part of the bind
> package. Searching for "dig" returns garbage because "dig" is a common
> subword. Bind is scored with a relevance of 2, even though bind's
> description emphasises that dig is part of it.

Please note that using v2 of #73220 with the weight of 7, the package is
returned “third“: a relevance of 14 (behind 24 and 20).

However, it appears 8th in the list because the appearance for packages
having the same relevance scoring is arbitrary. It just depends on how
the modules are walked. Therefore, we cannot do much, IMHO.


Cheers,
simon



2: Re: Search improvements (Was: Opposition to new single-letter package name "t")
zimoun <zimon.toutoune@gmail.com>
Tue, 09 Mar 2021 19:37:23 +0100
id:CAJ3okZ3+hn0nJP98OhnZYLWJvhLGpdTUK+jB0hoM5JArQxO=zw@mail.gmail.com
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 70689@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70689
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch