//This takes about 6 seconds each search for song*
for (id key in songsDictionary) {
NSString *thisSong = key;
int suppliedCount = [stringValue length];
int keyCount = [thisSong length];
//Fuzzy matching
Thanks for the reply. I've since broken up the songs into buckets depending
on the title length and I use a Dictionary to retrieve arrays based on the
length, then I am only searching a subset. It's WAY faster than searching
the entire collection of songs. I just pre-build this during app start up
I have an NSMutableArray that contains a MPMediaItem and song title as it's
key.
I then take a search string and loop through the entire NSMutableArray
looking for a fuzzy match. It works very well, the problem is that the array
contains 1,777 items (could contain more) and the search takes
I have an NSMutableArray that contains a MPMediaItem and song title as it's
key.
I then take a search string and loop through the entire NSMutableArray
looking for a fuzzy match. It works very well, the problem is that the array
contains 1,777 items (could contain more) and the search takes
Oops - I meant to say it's an NSMutableDictionary!
What might a quick stubbed example of that be? Not sure I am following. How
much speed would it generally gain?
Google Voice: (508) 656-0622
Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki
http://blog.ericd.net
On
Oops - I meant to say it's an NSMutableDictionary!
What might a quick stubbed example of that be? Not sure I am following. How
much speed would it generally gain?
Simple example. Init a NSMutableDictionary. For each string, compute a hash key
as the sum of all chars composing it (in a
Someone told me to look into -enumerateKeysAndObjectsWithOptions:usingBlock:
(using NSEnumerationConcurrent) Would that be a better way? If so, I haven't
seen this used before - how could I apply it?
- Eric
Simple example. Init a NSMutableDictionary. For each string, compute a hash
key as the
Someone told me to look into -enumerateKeysAndObjectsWithOptions:usingBlock:
(using NSEnumerationConcurrent) Would that be a better way? If so, I haven't
seen this used before - how could I apply it?
You can try to use that, but, basically, it is the same problem: you enumerate
all entries
Thanks. The distance is computed because the entry string is dynamic and
it's providing a distance between the title of the song and what was entered
as text. So I can't pre-compute that data and stuff into a dictionary. Each
time the method is called, the *stringValue* will be different.
On Tue,
Thanks. The distance is computed because the entry string is dynamic and it's
providing a distance between the title of the song and what was entered as
text. So I can't pre-compute that data and stuff into a dictionary. Each time
the method is called, the stringValue will be different.
I think I see what you're onto here now. So I might only have about 30 or so
keys to search through instead of all 1,777 items, and then just grab an
array (or probably a dictionary) of stuff out of that to search on...
resulting in a lot less searching to hopefully get to a potential match.
a
On Jul 19, 2011, at 6:22 AM, Vincent Habchi wrote:
It's not easy, but I would recommend using a hash table instead. You can
compute a hash code that depends more or less on the spelling of your
strings, then use that hash key to access a set of candidate for your fuzzy
search.
I take it
Eric E. Dolecki wrote:
//Get the very best match there is to be found for
song.
if(match currentFoundValue){
currentFoundValue = match;
test = [songsDictionary objectForKey:thisSong];
dis = [NSArray
When computing the string distance depending on the chosen algorithm you can
exit the function earlier if the distance is becoming too high.
An other possible way is to do some fuzzy string search:
http://en.wikipedia.org/wiki/Fuzzy_string_searching
HTH
--
mathk
- Message d'origine
14 matches
Mail list logo
