SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
[SA 7.3.430 Pro] - Name matching methods

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
[SA 7.3.430 Pro] - Name matching methods
Author Message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post [SA 7.3.430 Pro] - Name matching methods Reply with quote
There are two new name matching methods introduced in 7.3 by splitting the old one (Name Contains Characters from Key String) into two similar ones that should have a slight difference in behavior. The new name match methods are:

Name Contains Characters from Key String, Order Alphabetically
and
Name Contains Characters from Key String, Order by Best Match

The screenshot below was captured using Name Contains Key String, Order by Best Match for the search term "jarat":


And this one below was captured using Name Contains Characters from Key String, Order by Best Match for the same search term "jarat":


I'd expect more or less the same results since the characters that occur in that order are next to each other meaning that the result set for "jarat" is the same using both methods. The table named "jarat" should be on the top of the list but it turned out that the order of the items in the popup is the same for both Name Contains Characters from Key String, Order Alphabetically and Name Contains Characters from Key String, Order by Best Match.

Unless I'm mistaken by what the Best match should mean (and that it should mean the same order as with Name Contains Key String, Order by Best Match) the Name Contains Characters from Key String, Order by Best Match does not work as it was intended, does it?
Wed Oct 21, 2015 5:41 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
Any hints on why this is not working as I presumed? Am I misunderstanding the concept?
Mon Nov 30, 2015 12:03 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
After analyzing your results we came to conclusion that the second list is sorted alphabetically after filtering is applied, while the first one is sorted by best match. It looks like you get reversed results. Can you reproduce this issue if you revert SA settings to the factory default?
Tue Dec 01, 2015 11:43 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
SysOp wrote:
After analyzing your results we came to conclusion that the second list is sorted alphabetically after filtering is applied, while the first one is sorted by best match. It looks like you get reversed results. Can you reproduce this issue if you revert SA settings to the factory default?


Affirmative. It yields the same results with factory defaults restored and Name matching method (which was also reset to Name Starts with Key String) set to Name Contains Characters from Key String, Order by Best Match.
Wed Dec 02, 2015 4:49 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
I received new feedback from the team. They say the results are actually correct. Here is where we think the confusion was

I guess you meant to compare
1. Name Contains Characters from Key String, Order Alphabetically
and
2. Name Contains Characters from Key String, Order by Best Match

but then you captured screenshots comparing
3. Name Contains Key String, Order by Best Match
and
4. Name Contains Characters from Key String, Order by Best Match

Please note that option #3 isn't the same as option #1. Characters from Key String don't have to be matched as a continuous segment of the name, they can be anywhere in the name as long as they are sequential. For example, if you type jrt, it will match all names containing jarat too because j, r, t characters appear in that name.

The best match rules for "characters from key string" are a bit different then best match rules for the "key string" option. In a nut shell, best match rules for the key string break all items into 4 groups
1. Name begins with key string, for example, JaratPart2.
2. Key string represents a word within the name separated by space or _, for example, Part1_Jarat_Part2.
3. Word-break at the start or end of the key string, for example IsThisJarat_Part2.
4. All other cases

Best match rules for "characters from key string" use different grouping method, they evaluate the proximity of characters to each other, and also to the beginning of the name. Word breaks are not considered in this case.
Thu Dec 03, 2015 2:21 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
Hmm... Well, not really. I do understand the contrast between matching method types Name Contains Characters from Key Strings and Name Contains Key String. I strongly favor the first one for it reduces the number of characters required to type to filter down the candidates for objects drastically. I can select objects having names matching dozens of characters long at the beginning with 4 or 5 keypresses. It works brilliantly. Except in a very few special cases where it could work just as well if it worked the way I'd find logical, but id does not. It's nothing essential but it turned out to be slightly annoying :)

The comparison of #3 and #4 was intentional, because I thought upon producing the same result set, which might or might not be the case every time, but it is for this specific character string (or set for #4), that is, "jarat" (I understand it would be completely different for j, r, and t) , they would also produce the same order (best match) in the result set as well. Based on your description of the differences between groupings methods of the two this similarity is not to be expected. That's fine.

But I'm not quite sure I understand the grouping method for #4. If you take a glance at the second screenshot, you can see, that for all the items in the result set the characters, namely j, a, r, a, and t, are all tightly packed next to each other, so that should put them all in the same group regarding the proximity as criterion. I'd guess if the proximity to the beginning of the name also plays role, the table that bears the name jarat, and therefore has the strongest cohesion of the characters from Key string, being the shortest one, having all the character as close to each other as possible, and being closest to the beginning of the name at the same time, should be qualified the winner, and be the first one in the list. But it isn't.

Don't you feel it wrong putting an item, that actually matches the Key String perfectly and ultimately, in the middle of the list? If table "jarat" is the target, it takes 5 keypresses to filter the list. It cannot be narrowed down any further because any consequent keypress would filter it out. And then (using no mouse and not fiddling with page up/down) it would take another 25(!!!) keypresses to select table "jarat".
Thu Dec 03, 2015 5:00 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
Quote:
I'd guess if the proximity to the beginning of the name also plays role, the table that bears the name jarat, and therefore has the strongest cohesion of the characters from Key string, being the shortest one, having all the character as close to each other as possible, and being closest to the beginning of the name at the same time, should be qualified the winner, and be the first one in the list. But it isn't.


I agree with you. It's my expectation too. But it looks like there is something else in that method that throws that logic off or has a precedence over "closest to the beginning of the name" rule.

There is a pending enhancement for name matching methods to add word recognition within camel-case text. If I get it correctly, it would change results in your example too, but not like the way you describe it.
Sun Dec 06, 2015 6:36 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
I don't know when did this change but I noticed that lately my jarat table is at the top of the list even using Name Contains Characters from Key String, Order by Best Match. It gave another boost to my performance and I reached 9K% in productivity gain a few days ago.

Thank you very much :)
Mon Apr 25, 2016 3:28 am View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.