GH: Improve command search algorithm

Serengeti (Rhino 8 BETA) Grasshopper2
1

I am always impressed by how Rhino’s command search adapts over time and brings to the top the commands you use often, so after a while you only have to type a few letters usually and get the command you want.

That would be so good to have in GH as well. I would say that even as a pro GH user you still only use about 10% of the nodes 90% of the time. Yet some commands you use constantly like “list item” are particularly annoying. Often times you need to basically write down the whole command, even though you use it all the time.

Searching for “list item”. Typing “lis” so far so good:

lis
lis430×592 31.1 KB

When you get to “list” there are actually LESS options that start with “list” then before and list item actually disappears from the list:

list
list424×607 30.8 KB

Then you add the i and type “list i” and now list item reappears although it should clearly be the “best” match:

list i
list i454×637 30.7 KB

All of a sudden as you think the search should get MORE specific, it actually seems to get LESS specific.

Construct Domain is another good example. Its the “construct …” node I use by far the much, yet when I type it I get 12 options I never use.

Lastly the search algorithm just doesn’t seem to be working in a way that I find logical. I know a lot of algorithms dont work as our human logic would assume, but there has to be a better search algorithm.

So I would really like it if a) GH can remember what commands we use often and give them a higher weight the same way Rhino does and b) GH uses a search algorithm which aligns a bit more with how we expect to find things.

5 Likes
2

curious:

if you type “list i” then list item is at position 7, yet when you type “item l” it is position 1. In other cases it doesn’t have that inversion.

Like when you type “domain construct” then it still puts “domain” at position 1 and “construct domain” always stays at position 2.

So definitely something in the matching distance calculation that does not align with how we think it should match.

Maybe a phonetic search algorithm would be better here, since it will also mean that slight typos or other phonetic misspellings still surface the right commands, especially since GH has a lot of international users.

Is there a list of all the commands in GH that we can get somewhere to test out which search algorithm would be better?

3

You can get a list of all loaded components like this:

private void RunScript(ref object Names, ref object NickNames)
  {
    var objects = Grasshopper.Instances.ComponentServer.ObjectProxies;
    var names = new List<string>();
    var nickNames = new List<string>();
    foreach(var obj in objects)
    {
      var desc = obj.Desc;
      names.Add(desc.Name);
      nickNames.Add(desc.NickName);
    }
    Names = names;
    NickNames = nickNames;
  }

Components
Components1784×672 58.2 KB

Components.gh (15.9 KB)

Here I tried to experience how it would feel using String.StartsWith to search for components:


ComponentsStartsWith.gh (19.9 KB) (RealTimeTextBox)
2 Likes
4

Do right click on an icon in the components ribbon > Component alias > Set your search name for that component. Now you can find that component in the component search box using your custom name.

For me the component searcher is one of the most incomplete functionalities of GH, perhaps the most important one. The experience could really be improved a lot by enhancing this, and it has a huge margin to be improved. Instead of being based on name matching, it should be based on a scoring system that not only takes into account the characters, but also, as you say, the frequency, or the context of the document or all the metadata that the components can have (like category, subcategory, and others that could be added). And aliases should have a more global support, like taggers or hashtags, nested alisases and it should be easy to tag more than one component at the same time.

When you have a lot of things that are so similar to each other, with hierarchies and other relationships, a graph database type solution can give incredible support in addition to providing other features such as smart recommendations and analysis.

5

FWIW, adapting to the search limitations I have learned to (in this case) skip the “list” part and go directly for “item” part of the component name, like so:

image

// Rolf

6

Just thought I’d have a brief look online on “string search algorithms”. I didn’t think it would be such a rabbit hole and so many different algorithms. Holy shit!

So yeah, its definitely not for a lack of other options to try. The current algorithm at least is pretty unintuitive.