Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^5: Search for identical substrings

by BrowserUk (Pope)
on Aug 20, 2005 at 00:49 UTC ( #485338=note: print w/ replies, xml ) Need Help??


in reply to Re^4: Search for identical substrings
in thread Search for identical substrings

Here are my results from the 6 sequences you posted on your scratchpad. I must assume that this is a "constructed dataset" as all the LCSs are found at the same offset in both sequences in which they occur? I thought this was a bug when I first saw it, but it doesn't happen with any of my test data.

There were no duplicate equal length matches. Some of the LCSs shown below are truncated for posting, but the Length and (offsets) and first 80 or so characters should be enough to verify the results. Confirmation or otherwise would be nice to have.

If this data is representative, the time taken for the 15 pairing projects to a total runtime for your 300x3k of around 58 hours. Somewhat more palatable that 3 years:)

Had you only wanted the single longest common string in the dataset, I can do that in under 6 hours.

Updated: The offsets originally shown were all +10 due to my failing to remove the sequence labels. This has now been corrected.

P:\test>484593-4 bioman.dat 000:001 L[ 72] (1557 1557) 'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCGCATGGAGACCACCGTGAACG +CCC' 000:002 L[1271] ( 82 82) 'CAGAACCCTGCTCCGACTATTGCCTCTCTCACATCATCAATCTTCTTGAAGACTGGGGGCCCTGCTACG +AACATGGACA 000:003 L[ 225] (1128 1128) 'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCCAAGTGTTTGCTGACGCAACC +CCCACTGGTT 000:004 L[ 191] ( 619 619) 'TGGGCTTTAGGAAAATACCTATGGGAGTGGGCCTCAGCCCGTTTCTCCTGGCTCAGTTTACTAGTGCAA +TTTGTTCAGT 000:005 L[269] ( 292 292) 'GGGTGTCCTGGCCAAAATTCGCAGTCCCCAACCTCCAATCACTTACCAACCTCCTGTCCTCCAACTTGT +CCTGGCTATC 001:002 L[ 72] (1557 1557) 'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCGCATGGAGACCACCGTGAACG +CCC' 001:003 L[ 72] (1557 1557) 'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCGCATGGAGACCACCGTGAACG +CCC' 001:004 L[ 80] (1764 1764) 'TCTTTGTACTAGGAGGCTGTAGGCATAAATTGGTCTGTTCACCAGCACCATGCAACTTTTTCACCTCTG +CCTAATCAT 001:005 L[ 72] (1557 1557) 'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCGCATGGAGACCACCGTGAACG +CCC' 002:003 L[ 320] (1128 1128) 'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCCAAGTGTTTGCTGACGCAACC +CCCACTGGTT 002:004 L[ 191] ( 619 619) 'TGGGCTTTAGGAAAATACCTATGGGAGTGGGCCTCAGCCCGTTTCTCCTGGCTCAGTTTACTAGTGCAA +TTTGTTCAGT 002:005 L[ 269] ( 292 292) 'GGGTGTCCTGGCCAAAATTCGCAGTCCCCAACCTCCAATCACTTACCAACCTCCTGTCCTCCAACTTGT +CCTGGCTATC 003:004 L[ 161] (1128 1128) 'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCCAAGTGTTTGCTGACGCAACC +CCCACTGGTT 003:005 L[ 510] (2693 2693) 'AAACCCTATTATCCTGATAACGTGGTTAATCATTATTTTAAGACCAGACACTATTTGCATACTTTATGG +AAGGCAGGCA 004:005 L[ 148] (1138 1138) 'ACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCCAAGTGTTTGCTGACGCAACCCCCACTGGTT +GGGGCTTGGC 15 trials of bioman.dat ( 70.142s total), 4.676s/trial

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.


Comment on Re^5: Search for identical substrings
Download Code
Re^6: Search for identical substrings
by bioMan (Beadle) on Aug 22, 2005 at 16:54 UTC

    The data are not constructed but actual. The reason why the same offset is seen in strings with a match is because these are biological data. The string are in essence biological "computer programs" coding for objects having almost exactly the same function. In a way my problem is similar to that in Perl Quiz of the Week #14, except I'm looking for identical code in different biological "programs".

    I like your time estimates. I will definitely try your program.

      The reason why the same offset is seen in strings with a match is because these are biological data.

      Are you saying that the substrings you are interested in will always appear at the same offset in both strings?

      This is important, because if it is the case, your entire dataset can be processed in under 90 seconds.

      P:\test>484593-9 bioman.dat 000:001 L[072] (0072,0072)'TTCAGAGACACAGAACCCTGCTCCGACTATTGCCTCTCTCACATCATCA +A' 000:002 L[1271] (1271,1271)'TGCGGAACTCCTTGCAGCTTGTTTCGCTCGCAGCCGGTCTGGAGCGAAA +C' 000:003 L[225] (0225,0225)'AATCCTCACAATACCACAGAGTCTAGACTCGTGGTGGACTTCTCTCAAT +T' 000:004 L[191] (0191,0191)'TCGTGTTACAGGCGGTGTGTTTCTTGTTGACAAAAATCCTCACAATACC +A' 000:005 L[269] (0269,0269)'TCAATTTTCTAGGGGGAACACCCGGGTGTCCTGGCCAAAATTCGCAGTC +C' 001:002 L[072] (0072,0072)'TTCCGGAACAGTAAACCCTGTTCCGACTACTGCCTCACCCATATCGTCA +A' 001:003 L[072] (0072,0072)'TTCCGGAACAGTAAACCCTGTTCCGACTACTGCCTCACCCATATCGTCA +A' 001:004 L[080] (0080,0080)'CAGTAAACCCTGTTCCGACTACTGCCTCACCCATATCGTCAATCTTCTC +G' 001:005 L[072] (0072,0072)'TTCCGGAACAGTAAACCCTGTTCCGACTACTGCCTCACCCATATCGTCA +A' 002:003 L[320] (0320,0320)'CAACCTCCAATCACTTACCAACCTCCTGTCCTCCAACTTGTCCTGGCTA +T' 002:004 L[191] (0191,0191)'TCGTGTTACAGGCGGTGTGTTTCTTGTTGACAAAAATCCTCACAATACC +A' 002:005 L[269] (0269,0269)'TCAATTTTCTAGGGGGAACACCCGGGTGTCCTGGCCAAAATTCGCAGTC +C' 003:004 L[161] (0161,0161)'ACATCACATCAGGACTCCTAGGACCCCTGCTCGTGTTACAGGCGGTGTG +T' 003:005 L[510] (0510,0510)'ACCATGCAAAACCTGCACAACTCTTGCTCAAGGAACCTCTATGTTTCCC +T' 004:005 L[148] (0148,0148)'ATGAACATGGAGAACATCACATCAGGACTCCTAGGACCCCTGCTCGTGT +T' 15 trials of bioman.dat ( 27.018ms total), 1.801ms/trial

      That projects to a total time for your 300x3k strings of 80.78 seconds!

      There is no trick to that result. Very simple pure perl code that just makes use of the knowledge that the sequences of interest always appear at the same offsets in both strings.


      If that is not the case, then a much faster solution will be possible if you can guarentee that all equal-length matching sequences within a given pair will be in the same relative order, even if at different offsets?

      To clarify that. Say that there are three equal-length, matching strings (xxx, yyy & zzz) in a given pair of sequences (A & B). If they will always appear such that offset(xxx) < offset(yyy) < offset(zzz) in both A & B. Eg.

      A: ....xxx...yyy...zzz B: xxx....yyy.......zzz.... or A: .xxx........yyy...zzz....... b: .............xxx.yyy.zzz etc.

      Then a much faster solution is possible than the general case where the matching strings might appear in any order.

      A: ...xxx...yyy...zzz B: yyy...xxx...zzz...

      Likewise, if equal-length matching sequences would appear with the same ordering and the same relative offsets:

      A: xxx...yyy...zzz........... B: .....xxx...yyy...zzz......

      That knowledge would also speed up the search considerably.


      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.
      I like your time estimates. I will definitely try your program.

      Then you'll like this estimate even better:

      P:\test>484593-5 bioman.dat 000:001 L[072] (1557,1557)'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCG +CATGGAGACC 000:002 L[1271] (0082,0082)'CAGAACCCTGCTCCGACTATTGCCTCTCTCACATCATCAATCTTCTTGA +AGACTGGGGG 000:003 L[225] (1128,1128)'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCC +AAGTGTTTGC 000:004 L[191] (0619,0619)'TGGGCTTTAGGAAAATACCTATGGGAGTGGGCCTCAGCCCGTTTCTCCT +GGCTCAGTTT 000:005 L[269] (0292,0292)'GGGTGTCCTGGCCAAAATTCGCAGTCCCCAACCTCCAATCACTTACCAA +CCTCCTGTCC 001:002 L[072] (1557,1557)'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCG +CATGGAGACC 001:003 L[072] (1557,1557)'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCG +CATGGAGACC 001:004 L[080] (1764,1764)'TCTTTGTACTAGGAGGCTGTAGGCATAAATTGGTCTGTTCACCAGCACC +ATGCAACTTT 001:005 L[072] (1557,1557)'CCTTCTCATCTGCCGGACCGTGTGCACTTCGCTTCACCTCTGCACGTCG +CATGGAGACC 002:003 L[320] (1128,1128)'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCC +AAGTGTTTGC 002:004 L[191] (0619,0619)'TGGGCTTTAGGAAAATACCTATGGGAGTGGGCCTCAGCCCGTTTCTCCT +GGCTCAGTTT 002:005 L[269] (0292,0292)'GGGTGTCCTGGCCAAAATTCGCAGTCCCCAACCTCCAATCACTTACCAA +CCTCCTGTCC 003:004 L[161] (1128,1128)'CAATACATGAACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCC +AAGTGTTTGC 003:005 L[510] (2693,2693)'AAACCCTATTATCCTGATAACGTGGTTAATCATTATTTTAAGACCAGAC +ACTATTTGCA 004:005 L[148] (1138,1138)'ACCTTTACCCCGTTGCTCGGCAACGGCCAGGCCTGTGCCAAGTGTTTGC +TGACGCAACC 15 trials of bioman.dat ( 1.948s total), 129.853ms/trial

      That projects to a total time for your 300x3k of 1hr 37 minutes.

      This is a Inline C (or could be XS) implementation and is the full monty with no restrictions on position or ordering, and will report multiple equal-length matches for all pairings. It is linear in both time (O(n*m)) and space (O(n+1) upto the capacity of your machine). It also supports a "minimum match" parameter though it makes little difference on performance.

      It is much faster (2-orders of maginitude (or more)) than anything else I have been able to compare it against.

      I would like to compare it against Bio::Tools::dpAlign, but I cannot even work out where to obtain this package. I (re-) installed the lastest Bioperl package, but it was not installed with that, and the install link takes you to the entire BioPerl distribution, but I cannot find either a Bio::Tools::dpAlign, or Bio::Tools package to download. If you succeeded in installing and using B::T::dpAlign, I'd realy like to see your results and timings?

      I'm currently working out the best way to package what I have--with Inline::C as a dependancy or using the .xs it produces--as I think this would be useful even if dpAlign is faster. For anyone wanting a Least Common SubString function for simple/non-bioperl use, installing the whole bioperl behemoth is just overkill. I'm also thinking of sticking the Least Common SubSequences algo in there if my optimisation prove to be equally effective on it as on the SubStrings algo.

      If you have/are comfortable installing Inline C and want to try this out, left me know and I'll send you the unpackaged version. You can be my guinea pig:)


      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://485338]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2014-07-31 05:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (245 votes), past polls