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
[download]

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.
[download]

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...
[download]

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......
[download]

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
[download]

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.