Re: Search for identical substrings

Replies are listed 'Best First'.
Re^2: Search for identical substrings by BrowserUk (Patriarch) on Aug 21, 2005 at 07:14 UTC
I've posted code here that seems to be about 7000 times faster than BrowserUk's solution The results I posted were those for finding all the LCSs for all pairings. If I only search for the single longest LCS, and make the same minimum match assumption as you: `[ 8:05:03.68] P:\test>484593-3 -MIN=128 bioman.dat Best match len:1271 between string 0:82 & string 2:82 15 trials of bioman.dat ( 5.443s total), 362.894ms/trial` [download] Which means your still 500+ X faster, but it allows me to save face (a little :). You're making an assumption in your code that you cannot make for a general solution, that of a minimum match length of 128, and produce no output if you set it too high. Whilst your comments say that this can be adjusted to a lower power of 2, when I tried this, I got strangely 'almost correct' values for both length and offset. I tracked this down to ... Your algorithm only produces the correct output if the input strings are an exact multiple of the minimum size specified. To demonstrate, I trimmed 1 character from the front of each line in biomain's data and ran your code with $subStrSize = 128 and got: `P:\test>gf bioman2.dat Completed in 0.009606 Best match: >string 1 - >string 3 . 1273 characters starting at 80 an +d 80.` [download] Note that the length has increased by 2 when it should be the same, and both offsets have reduced by 2 when they should have reduced by 1? I also tried setting $subStrSize = 1, as thought that might correct the problem, but apart from running much more slowly, it still produced the same, slightly wrong output: `[ 7:49:55.56] P:\test>gf bioman2.dat Completed in 76.466764 Best match: >string 1 - >string 3 . 1273 characters starting at 80 an +d 80.` [download] All that said, your algorithm is blazingly fast and the anomolies can probably be corrected. If so, or if bioman only needs the single LCS, and can live with specifying a minimum match and arranging for his input data to always be a multiple of that minimum size, it blow's what I have into dust. At least, until I can adapt my code to use elements of your search technique :). Nice++ Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l] [select]
Re^3: Search for identical substrings by GrandFather (Saint) on Aug 21, 2005 at 09:06 UTC
Actually the code does generate all the LCS's. I used to print those out. If you are interested you can add back the line by copying the print for best match, pasting it after the line `$localBest = expandMatch (@$localBest);` and replacing $bestMatch with $localBest. The run time remains about the same :). I noticed the anomolies, but was so excited by the run rate that I sort of forgot about them and posted the code. The problem will be in the `expandMatch` sub which does a binary search to extend the match at each end to the full extent of the matched run. It's probably trivial to fix and I'll have a look and update the posted code when I find the bug. The minimum match length is where the "blazingly fast" bit comes from. Although it still seems to be pretty fast even for small match lengths. This turned out so much faster than anything else that I couldn't quite believe it! I'm pleased that you have reproduced my results (bugs included). Perl is Huffman encoded by design.	[reply] [d/l] [select]
Re^4: Search for identical substrings by BrowserUk (Patriarch) on Aug 21, 2005 at 23:18 UTC
The thing that really slowed my code down was detecting multiple, equal-length LCS within the same pairing. Eg. In this dataset: `>string1 AAAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTT >string2 AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT` [download] my program detects and reports both the As at the beginning and the Ts at the end: `P:\test>484593-4 duptest.dat 000:001 L[017] (0 0)'AAAAAAAAAAAAAAAAA' (47 47)'TTTTTTTTTTTTTTTTT' 1 trial of duptest.dat ( 1.210ms total), 1.210ms/trial` [download] Where your program will only report the first of the two equal LCSs: `P:\test>gf -MIN=16 duptest.gf Completed in 0.000209 Best match: >string1 - >string2. 17 characters starting at 0 and 0. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAA` [download] Also, if the equal LCSs appear in different relative positions within the pairing, which is reported depends upon which appears first within the first string of the pairing: P:\test>type duptest.gf >string1 TTTTTTTTTTTTTTTTTCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAA >string2 AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT P:\test>gf -MIN=16 duptest.gf Completed in 0.00021 Best match: >string1 - >string2. 17 characters starting at 0 and 47. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 TTTTTTTTTTTTTTTTTCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAA TTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT ...............................................TTTTTTTTTTTTTTTTT P:\test>type duptest.gf >string1 AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT >string2 TTTTTTTTTTTTTTTTTCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAA P:\test>gf -MIN=16 duptest.gf Completed in 0.000209 Best match: >string1 - >string2. 17 characters starting at 0 and 47. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAA TTTTTTTTTTTTTTTTTCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAA ...............................................AAAAAAAAAAAAAAAAA [download] I cannot see how you could adapt your code to handle that without loosing it's performance? This may be just a bug-report rather than a fundemental problem, but I modified the above dataset by deleting one of the As from the start of each line and adding two T's (keeping the length to 64) at the end, making the Ts the LCS for the pair. Ignoring the reporting anomolies, your code still detects the As as the LCS unless I drop the minimum length right down to 2? P:\test>gf -MIN=16 duptest.gf Completed in 0.000207 Best match: >string1 - >string2. 17 characters starting at 0 and 0. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAC AAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAG P:\test>gf -MIN=8 duptest.gf Completed in 0.000296 Best match: >string1 - >string2. 17 characters starting at 0 and 0. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAC AAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAG P:\test>gf -MIN=4 duptest.gf Completed in 0.000611 Best match: >string1 - >string2. 17 characters starting at 0 and 0. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAC AAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAG P:\test>gf -MIN=2 duptest.gf Completed in 0.000909 Best match: >string1 - >string2. 19 characters starting at 44 and 44. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 AAAAAAAAAAAAAAAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCTTTTTTTTTTTTTTTTTT ............................................CCTTTTTTTTTTTTTTTTT AAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGTTTTTTTTTTTTTTTTTT ............................................GGTTTTTTTTTTTTTTTTT [download] Indeed, as it stands, your code always favours a shorter match in the first string over a longer match in the second unless the minimum match is set to a value less than or equal to the difference between the matches. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l] [select]
Re^2: Search for identical substrings by BrowserUk (Patriarch) on Aug 21, 2005 at 02:37 UTC
Note that the claimed match position given in BrowserUk's result is wrong (checked by a manual examination of the data), but the match length is right. The offsets were all +10 because I failed to remove the sequence labels from the strings. This is now corrected. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l]