Estrutura ou algoritmo de dados para encontrar rapidamente diferenças entre cadeias

Eu tenho uma matriz de 100.000 cordas, todas de comprimento . Eu quero comparar cada seqüência de caracteres com todas as outras para ver se existem duas seqüências diferentes por 1 caractere. No momento, enquanto adiciono cada string à matriz, eu a comparo com todas as strings já existentes na matriz, que possuem uma complexidade de tempo de .n ( n - 1 $k$$\frac{n(n-1)}{2} k$

Existe uma estrutura de dados ou algoritmo que possa comparar seqüências de caracteres mais rapidamente do que o que eu já estou fazendo?

Algumas informações adicionais:

• A ordem importa: abcdee xbcdediferem por 1 personagem, enquanto abcdee edcbadiferem por 4 caracteres.

• Para cada par de cadeias que diferem por um caractere, removerei uma dessas cadeias da matriz.

• No momento, estou procurando cadeias que diferem em apenas 1 caractere, mas seria bom se essa diferença de 1 caractere pudesse ser aumentada para, digamos, 2, 3 ou 4 caracteres. No entanto, neste caso, acho que a eficiência é mais importante do que a capacidade de aumentar o limite de diferença de caracteres.

• $k$ está geralmente na faixa de 20 a 40.

É possível obter pior tempo de execução de O ( n k log k ) .$O(nk \log k)$

Vamos começar simples. Se você se preocupa com uma solução fácil de implementar que seja eficiente em muitas entradas, mas não todas, aqui está uma solução simples, pragmática e fácil de implementar, que muitas são suficientes na prática para muitas situações. No entanto, ele volta ao tempo de execução quadrático no pior dos casos.

Pegue cada string e armazene-a em uma hashtable, com chave na primeira metade da string. Em seguida, itere sobre os baldes de hashtable. Para cada par de strings no mesmo bucket, verifique se elas diferem em 1 caractere (ou seja, verifique se a segunda metade difere em 1 caractere).

Em seguida, pegue cada string e armazene-a em uma hashtable, desta vez digitada na segunda metade da string. Verifique novamente cada par de cordas no mesmo balde.

Supondo que as strings sejam bem distribuídas, o tempo de execução provavelmente será de cerca de . Além disso, se existir um par de cadeias que diferem em 1 caractere, ele será encontrado durante uma das duas passagens (como diferem em apenas 1 caractere, esse caractere diferente deverá estar na primeira ou na segunda metade da cadeia, portanto, a segunda ou a primeira metade da string deve ser a mesma). No entanto, no pior caso (por exemplo, se todas as seqüências começarem ou terminarem com os mesmos caracteres k / 2 ), isso degradará para O ( n 2 k ) tempo de execução, portanto, o pior caso de execução não é uma melhoria na força bruta .$O(nk)$$k/2$$O(n^2 k)$

Como uma otimização de desempenho, se algum depósito tiver muitas seqüências, você poderá repetir o mesmo processo recursivamente para procurar um par que diferencie um caractere. A chamada recursiva será em cadeias de comprimento .$k/2$

Se você se preocupa com o pior tempo de execução:

Com a otimização de desempenho acima, acredito que o pior caso de execução é .$O(nk \log k)$

Minha solução é semelhante à do j_random_hacker, mas usa apenas um único conjunto de hash.

Eu criaria um conjunto de strings de hash. Para cada sequência na entrada, adicione ao conjunto strings. Em cada uma dessas cadeias, substitua uma das letras por um caractere especial, não encontrado em nenhuma das cadeias. Enquanto você os adiciona, verifique se eles ainda não estão no conjunto. Se forem, você tem duas cadeias que diferem apenas em (no máximo) um caractere.$k$

Um exemplo com as seqüências de caracteres 'abc', 'adc'

Para abc, adicionamos '* bc', 'a * c' e 'ab *'

Para adc, adicionamos '* dc', 'a * c' e 'ad *'

Quando adicionamos 'a * c' na segunda vez que percebemos que já está no conjunto, sabemos que existem duas cadeias que diferem apenas por uma letra.

O tempo total de execução desse algoritmo é . Isso ocorre porque criamos k novas strings para todas as n strings na entrada. Para cada uma dessas cadeias, precisamos calcular o hash, que normalmente leva tempo O ( k ) .$O(n*k^2)$$k$$n$$O(k)$

Armazenar todas as strings ocupa espaço .$O(n*k^2)$

Melhorias adicionais

Podemos melhorar ainda mais o algoritmo, não armazenando diretamente as cadeias modificadas, mas armazenando um objeto com uma referência à cadeia original e o índice do caractere que está mascarado. Desta forma, não é necessário criar todas as cordas e nós só precisamos de espaço para armazenar todos os objetos.$O(n*k)$

Você precisará implementar uma função de hash personalizada para os objetos. Podemos tomar a implementação Java como um exemplo, consulte a documentação do Java . O java hashCode multiplica o valor unicode de cada caractere por (com k o comprimento da string ei o índice baseado em um). Observe que cada string alterada difere apenas um caractere do original. Podemos calcular facilmente a contribuição desse caractere para o código de hash. Podemos subtrair isso e adicionar nosso caractere de mascaramento. Isso leva O ( 1 ) a ser computado, o que nos permite reduzir o tempo total de execução para O ( $31^{k-i}$$k$$i$$O(1)$$O(n*k)$

Eu criaria hashtables H 1 , … , H k , cada uma das quais com uma string de comprimento ( k - 1 ) como chave e uma lista de números (IDs de string) como valor. A hashtable H i conterá todas as strings processadas até o momento, mas com o caractere na posição i excluída . Por exemplo, se k = 6 , então H 3 [ A B D E F ] conterá uma lista de todas as cadeias vistas até agora que têm o padrão $k$$H_1, \dots, H_k$$(k-1)$$H_i$$i$$k=6$$H_3[ABDEF]$ , onde ⋅ significa "qualquer caractere". Em seguida, para processar a j -ésima sequência de entrada s j :$AB\cdot DEF$$\cdot$$j$$s_j$

1. Para cada no intervalo de 1 a k : $i$$k$
   • Forme a string excluindo o i- ésimo caractere de s j .$s_j'$$i$$s_j$
   • Procure . Cada ID de string aqui identifica uma string original que é igual a s ou difere apenas na posição i . Produza-os como correspondências para a sequência s j . (Se você deseja excluir duplicatas exatas, torne o tipo de valor das tabelas de hash um par (ID da string, caractere excluído), para que você possa testar aqueles que tiveram o mesmo caractere excluído, como acabamos de excluir de s j .)$H_i[s_j']$$s$$i$$s_j$$s_j$
   • Insira em H i para consultas futuras a serem usadas.$j$$H_i$

Se armazenar cada chave de hash explicitamente, em seguida, devemos usar espaço e, portanto, têm complexidade de tempo, pelo menos, que. Mas, como descrito por Simon Prins , é possível representar uma série de modificações em uma string (no caso dele descrita como alterar caracteres únicos para , no meu como exclusões) implicitamente de tal maneira que todas as chaves de hash k de uma string específica precisem apenas O ( k ) espaço, levando a O ( n k ) espaço global e abrindo a possibilidade de O ( n k $O(nk^2)$*$k$$O(k)$$O(nk)$$O(nk)$tempo também. Para atingir essa complexidade de tempo, precisamos de uma maneira de calcular os hashes para todas as variações de uma string de comprimento k em tempo O ( k ) : por exemplo, isso pode ser feito usando hashes polinomiais, conforme sugerido por DW (e isso é provavelmente muito melhor do que simplesmente XORing o caractere excluído com o hash da string original).$k$$k$$O(k)$

O truque implícito de representação de Simon Prins também significa que a "exclusão" de cada caractere não é realmente executada; portanto, podemos usar a representação habitual baseada em array de uma string sem uma penalidade de desempenho (em vez de listas vinculadas, como sugeri originalmente).

Aqui está uma abordagem hashtable mais robusta do que o método polinomial-hash. Em primeiro lugar gerar inteiros positivos aleatórios r 1 .. k que são primos entre si para a tabela de dispersão tamanho M . Ou seja, 0 ≤ r i < M . Em seguida, cada corda de hash x 1 .. k a ( Σ k i = 1 x i r i ) mod M . Não há quase nada que um adversário possa fazer para causar colisões muito desiguais, pois você gera r 1 .. k em tempo de execução e assim como $k$$r_{1..k}$$M$$0 \le r_i < M$$x_{1..k}$$(\sum_{i=1}^k x_i r_i ) \bmod M$$r_{1..k}$$k$aumenta a probabilidade máxima de colisão de um dado par de cadeias distintas passa rapidamente para . Também é óbvio como calcular em O ( k ) tempo todos os hashes possíveis para cada string com um caractere alterado.$1/M$$O(k)$

Se você realmente deseja garantir um hash uniforme, pode gerar um número natural aleatório menor que M para cada par ( i , c ) para i de 1 a ke para cada caractere c , e então hash de cada string x 1 .. k a ( ∑ k i = 1 r ( i , x i ) ) mod $r(i,c)$$M$$(i,c)$$i$$1$$k$$c$$x_{1..k}$$(\sum_{i=1}^k r(i,x_i) ) \bmod M$. Então a probabilidade de colisão de um dado par de cadeias distintas é exactamente . Essa abordagem é melhor se o seu conjunto de caracteres for relativamente pequeno comparado a n .$1/M$$n$

Muitos dos algoritmos postados aqui usam bastante espaço nas tabelas de hash. Aqui está um algoritmo simples de tempo de execução armazenamento auxiliar O ( ( n lg n ) ⋅ k 2 ) .$O(1)$$O((n \lg n) \cdot k^2)$

O truque é usar , que é um comparador entre dois valores um e b que retorna verdadeiro se um < b (lexicograficamente), ignorando o k th personagem. Então o algoritmo é o seguinte.$C_k(a, b)$$a$$b$$a < b$$k$

Primeiro, basta classificar as strings regularmente e fazer uma varredura linear para remover as duplicatas.

Então, para cada :$k$

1. Classifique as seqüências com como comparador.$C_k$

2. As strings que diferem apenas em agora são adjacentes e podem ser detectadas em uma varredura linear.$k$

Duas cadeias de comprimento k , diferindo em um caractere, compartilham um prefixo de comprimento l e um sufixo de comprimento m, de modo que k = l + m + 1 .

A resposta de Simon Prins codifica isso armazenando todas as combinações de prefixo / sufixo explicitamente, ou abcseja *bc, torna-se a*ce ab*. Isso é k = 3, l = 0,1,2 em = 2,1,0.

Como valarMorghulis aponta, você pode organizar as palavras em uma árvore de prefixos. Há também a árvore de sufixos muito semelhante. É bastante fácil aumentar a árvore com o número de nós de folhas abaixo de cada prefixo ou sufixo; isso pode ser atualizado em O (k) ao inserir uma nova palavra.

O motivo pelo qual você deseja essas contagens de irmãos é saber, com uma nova palavra, se deseja enumerar todas as cadeias com o mesmo prefixo ou se deve enumerar todas as cadeias com o mesmo sufixo. Por exemplo, para "abc" como entrada, os possíveis prefixos são "", "a" e "ab", enquanto os sufixos correspondentes são "bc", "c" e "". Como é óbvio, para sufixos curtos, é melhor enumerar irmãos na árvore de prefixos e vice-versa.

Como o @einpoklum aponta, certamente é possível que todas as strings compartilhem o mesmo prefixo k / 2 . Isso não é um problema para essa abordagem; a árvore do prefixo será linear até a profundidade k / 2, com cada nó até a profundidade k / 2 sendo o ancestral de 100.000 nós de folha. Como resultado, a árvore de sufixos será usada até (k / 2-1) de profundidade, o que é bom porque as strings precisam diferir em seus sufixos, uma vez que compartilham prefixos.

[edit] Como otimização, depois de determinar o prefixo único mais curto de uma string, você sabe que se houver um caractere diferente, ele deverá ser o último caractere do prefixo e você teria encontrado a duplicata quase quando verificando um prefixo mais curto. Portanto, se "abcde" tiver um prefixo único mais curto "abc", isso significa que existem outras strings que começam com "ab?" mas não com "abc". Ou seja, se eles diferissem em apenas um personagem, esse seria o terceiro personagem. Você não precisa mais verificar "abc? E".

Pela mesma lógica, se você achar que "cde" é um sufixo mais curto e exclusivo, saberá que precisa verificar apenas o prefixo comprimento 2 "ab" e não o prefixo comprimento 1 ou 3.

Observe que esse método funciona apenas para diferenças de exatamente um caractere e não generaliza para 2 diferenças de caracteres. Ele confia em um caractere, sendo a separação entre prefixos e sufixos idênticos.

Armazenar strings em buckets é uma boa maneira (já existem respostas diferentes descrevendo isso).

Uma solução alternativa poderia ser armazenar seqüências de caracteres em uma lista classificada . O truque é classificar por um algoritmo de hash sensível à localidade . Este é um algoritmo de hash que produz resultados semelhantes quando a entrada é semelhante [1].

Cada vez que você deseja investigar uma série, você pode calcular seu hash e pesquisar a posição desse hash na sua lista ordenada (tomando para arrays ou O ( n ) para listas ligadas). Se você achar que os vizinhos (considerando todos os vizinhos próximos, não apenas aqueles com um índice de +/- 1) dessa posição são semelhantes (desativados por um caractere), você encontrou a sua correspondência. Se não houver seqüências semelhantes, você poderá inserir a nova sequência na posição encontrada (que utiliza O ( 1 ) para listas vinculadas e O ( n ) para matrizes).$O(log(n))$$O(n)$$O(1)$$O(n)$

Um possível algoritmo de hash sensível à localidade pode ser o Nilsimsa (com a implementação de código aberto disponível, por exemplo, em python ).

[1]: Observe que frequentemente algoritmos de hash, como SHA1, são projetados para o contrário: produzindo hashes muito diferentes para entradas semelhantes, mas não iguais.

Isenção de responsabilidade: para ser sincero, eu implementaria pessoalmente uma das soluções de bucket aninhadas / organizadas em árvore para um aplicativo de produção. No entanto, a ideia da lista classificada me pareceu uma alternativa interessante. Observe que esse algoritmo depende muito do algoritmo de hash escolhido. Nilsimsa é um algoritmo que encontrei - existem muitos outros (por exemplo, TLSH, Ssdeep e Sdhash). Não verifiquei se o Nilsimsa funciona com meu algoritmo descrito.

Pode-se obter a solução no tempo e no espaço O ( n k ) usando matrizes de sufixos aprimoradas ( matriz de sufixo juntamente com a matriz LCP ) que permitem consultas LCP (Longest Common Prefix) em tempo constante (ou seja, dados dois índices de uma string, qual é o tamanho do prefixo mais longo dos sufixos começando nesses índices). Aqui, poderíamos tirar proveito do fato de que todas as strings têm o mesmo comprimento. Especificamente,$O(nk+ n^2)$$O(nk)$

1. Crie a matriz de sufixos aprimorada de todas as seqüências concatenadas juntas. Seja X = x 1$n$ onde x i , ∀ 1 ≤ i ≤ n é uma sequência na coleção. Construir a matriz de sufixo e variedade LCP para X .$X = x_1.x_2.x_3 .... x_n$$x_i, \forall 1 \le i \le n$$X$

2. Agora, cada começa na posição ( i - 1 ) k na indexação baseada em zero. Para cada sequência x i , use LCP com cada sequência x j , de forma que j $x_i$$(i-1)k$$x_i$$x_j$ . Se o LCP ultrapassar o final de x j, então x i = x j . Caso contrário, existe um desfasamento (digamos x i [ p ] ≠ x j [ P $j<i$$x_j$$x_i = x_j$$x_i[p] \ne x_j[p]$); nesse caso, pegue outro LCP começando nas posições correspondentes após a incompatibilidade. Se o segundo LCP ultrapassar o final de , x i e x j diferem apenas em um caractere; caso contrário, existem mais de uma incompatibilidade.$x_j$$x_i$$x_j$

   for (i=2; i<= n; ++i){
       i_pos = (i-1)k;
       for (j=1; j < i; ++j){
           j_pos = (j-1)k;
           lcp_len = LCP (i_pos, j_pos);
           if (lcp_len < k) { // mismatch
               if (lcp_len == k-1) { // mismatch at the last position
               // Output the pair (i, j)
               }
               else {
                 second_lcp_len = LCP (i_pos+lcp_len+1, j_pos+lcp_len+1);
                 if (lcp_len+second_lcp_len>=k-1) { // second lcp goes beyond
                   // Output the pair(i, j)
                 }
               }
           }
       }
   }
   

Você pode usar a biblioteca SDSL para criar a matriz de sufixos em formato compactado e responder às consultas do LCP.

Análise: A construção da matriz de sufixos aprimorada é linear no comprimento de ou seja, O ( n k ) . Cada consulta LCP leva tempo constante. Assim, o tempo de consulta é O ( n 2 ) .$X$$O(nk)$$O(n^2)$

$O(nk + qn^2)$$q$

$j<i$$j$

$O(nk)$**bcdea*cde

Você também pode usar essa abordagem para dividir o trabalho entre vários núcleos de CPU / GPU.

Esta é uma versão curta da resposta do @SimonPrins que não envolve hashes.

Supondo que nenhuma de suas seqüências contenha um asterisco:

1. $nk$$k$$\mathcal{O}(nk^2)$
2. $\mathcal{O}(nk^2\log nk)$
3. $\mathcal{O}(nk^2)$

Uma solução alternativa com uso implícito de hashes no Python (não pode resistir à beleza):

def has_almost_repeats(strings,k):
    variations = [s[:i-1]+'*'+s[i+1:] for s in strings for i in range(k)]
    return len(set(variations))==k*len(strings)

Aqui está minha opinião sobre o localizador de incompatibilidades 2+. Observe que, neste post, considero cada string como uma substring circular, fe, de comprimento 2 no índicek-1 consiste no símbolo str[k-1]seguido por str[0]. E a substring de comprimento 2 no índice -1é a mesma!

Mk$mlen(k,M) = \lceil{k/M}\rceil-1$Mk=20M=4abcd*efgh*ijkl*mnop*

Agora, o algoritmo para pesquisar todas as incompatibilidades até os Msímbolos entre as cadeias de ksímbolos:

• para cada i de 0 a k-1
  • divida todas as strings em grupos por str[i..i+L-1], where L = mlen(k,M). Fe se L=4e você tiver um alfabeto de apenas 4 símbolos (do DNA), isso criará 256 grupos.
  • Grupos menores que ~ 100 strings podem ser verificados com o algoritmo de força bruta
  • Para grupos maiores, devemos executar a divisão secundária:
    • Remova de cada sequência nos Lsímbolos de grupo que já correspondemos
    • para cada j de i-L + 1 a kL-1
      • divida todas as strings em grupos por str[i..i+L1-1], where L1 = mlen(k-L,M). Fe se k=20, M=4, alphabet of 4 symbols, então L=4e L1=3, isso fará 64 grupos.
      • o restante é deixado como exercício para o leitor: D

Por que não começamos jdo zero? Como já criamos esses grupos com o mesmo valor i, então trabalhe comj<=i-L será exatamente equivalente ao trabalho com os valores iej trocados.

Otimizações adicionais:

• Em todas as posições, considere também as strings str[i..i+L-2] & str[i+L]. Isso apenas dobra a quantidade de empregos criados, mas permite aumentarL em 1 (se minha matemática estiver correta). Portanto, fe, em vez de 256 grupos, você dividirá os dados em 1024 grupos.
• $L[i]$*0..k-1M-1k-1

Eu trabalho todos os dias inventando e otimizando algos; portanto, se você precisar de todo o desempenho, esse é o plano:

• Verifique com *cada posição independentemente, ou seja, em vez de n*kvariantes de sequência de processamento de tarefa única - inicie ktarefas independentes cada verificação de nsequência. Você pode espalhar estesk trabalhos entre vários núcleos de CPU / GPU. Isso é especialmente importante se você verificar 2 ou mais diferenças de caracteres. Um tamanho menor de trabalho também melhorará a localidade do cache, o que por si só pode tornar o programa 10x mais rápido.
• Se você for usar tabelas de hash, use sua própria implementação empregando análise linear e fator de carga de ~ 50%. É rápido e fácil de implementar. Ou use uma implementação existente com endereçamento aberto. As tabelas de hash STL são lentas devido ao uso de encadeamento separado.
• Você pode tentar pré-filtrar os dados usando o filtro Bloom de 3 estados (distinguindo 0/1/1 + ocorrências) como proposto por @AlexReynolds.
• Para cada i de 0 a k-1, execute o seguinte trabalho:
  • Gere estruturas de 8 bytes contendo o hash de 4-5 bytes de cada sequência (com *a i-ésima posição) e o índice da sequência e, em seguida, classifique-os ou crie uma tabela de hash a partir desses registros.

Para classificação, você pode tentar a seguinte combinação:

• A primeira passagem é a classificação do MSD Radix de 64 a 256 maneiras usando o truque TLB
• segunda passagem é a classificação do MSD radix de 256 a 1024 maneiras sem o truque do TLB (total de 64K maneiras)
• terceira passagem é o tipo de inserção para corrigir as inconsistências restantes