Formula De Permutação

O básico que todo mundo explica errado

Você tem um conjunto de elementos e quer saber de quantas formas diferentes eles podem ser organizados quando a ordem importa. A resposta é simples: se são n elementos distintos, você multiplica n × (n-1) × (n-2) × ... × 1. Isso é o fatorial. Mas a fórmula de permutação vai além disso quando há repetição ou quando você só seleciona parte dos elementos. O caso mais comum que as pessoas encontram é a permutação simples P(n) = n!. Usada quando todos os n elementos são diferentes e todos precisam ser posicionados. Um exemplo prático: cinco peças em um assembly onde a sequência altera o resultado final. São 5! = 120 arranjos possíveis. Não precisa complicar.

O que quase ninguém destaca é que a permutação com repetição é onde a maioria erra. Se você tem elementos iguais, o resultado diminui drasticamente. Imagine a palavra "BANANA" — três A's, dois N's, um B. A conta é 7! dividido por (3! × 2! × 1!). O resultado é 4.200, não 5.040. Eu perdi duas horas num projeto de otimização logística porque tratava itens repetidos como distintos. A correção foi identificar os duplicados com um dicionário antes de aplicar a fórmula.

Entendendo a fórmula de permutação na prática

A regra geral para permutação com repetição é: P = n! / (n! × n! × ... × n!)

Onde n é o total de elementos e n, n etc. são as quantidades de cada elemento repetido. Para permutação simples, todos os n são 1, então o denominador vira 1 e sobra n!. Já para a permutação de n elementos tomados k a k (chamada de arranjo simples em muitos manuais), a fórmula é P(n,k) = n! / (n-k)!. A diferença é sutil mas crítica: no arranjo você não usa todos os elementos, só escolhe k deles e organiza. No dia a dia, o problema mais frequente é confundir permutação com combinação. A diferença é uma coisa só: na combinação a ordem não importa. Se você está formando comitês, grupos de trabalho ou combinações de ingredientes onde "A+B" é o mesmo que "B+A", use combinação. Se a sequência faz diferença — senha, ordem de execução, disposição em fileira — use permutação. Eu já vi gente aplicar C(n,k) quando deveria usar P(n,k) e o resultado saía exatamente k! vezes menor. Nunca esquece isso.

Quando a fórmula quebra e o que fazer

Permutação com repetição assume que os elementos repetidos são indistinguíveis. Se eles forem na verdade diferentes (mesmo que pareçam iguais visualmente), a fórmula errou. Esse é um cenário comum em engenharia, onde parafusos do mesmo modelo podem ter sido fabricados em lotes diferentes e precisam ser rastreados individualmente. A solução é tratar cada item como único, mesmo que a classificação aparente diga o contrário. Antes de rodar qualquer cálculo, pergunte se a distinção entre os elementos altera o resultado que você está medindo. Outro ponto cego: valores grandes de n. Fatorial cresce de forma exponencial. 20! já é 2,4 × 10¹. Se você precisa trabalhar com n maior que 170, o fatorial transborda o limite de precisão double em praticamente qualquer linguagem de programação. Nesse caso, use logaritmos. Calcule log(n!) com a função gammaln() — que é basicamente log(gamma(n+1)) — e depois exponencie apenas no final se precisar do valor exato. Em Python, isso seria math.lgamma(n+1). Em planilhas, a função LOGFATORIAL resolve. Corta o tempo de cálculo para praticamente zero e evita overflow.

Para quem precisa processar permutações em lote, uma dica operacional: não gere todas as permutações explicitamente. Só conte. Gerar 10! = 3.628.800 arranjos na memória é desnecessário na grande maioria dos casos. Se o objetivo é comparar eficiência de sequências, use geradores lazy e itere sem armazenar tudo. Em meus testes, isso reduziu o uso de RAM de cerca de 2 GB para menos de 50 MB num dataset de 12 elementos.

Um caso que aprendi na marra

Num projeto de scheduling de manutenção industrial, tínhamos 8 máquinas idênticas e 8 ordens de serviço. A intuição dizia para calcular 8! = 40.320 combinações. Mas duas das ordens de serviço eram idênticas — mesmo equipamento, mesma tarefa, mesmo tempo estimado. O espaço real de busca era 8! / 2! = 20.160. O otimizador estava gastando o dobro do necessário explorando estados duplicados. A correção foi adicionar uma restrição de simetria no solver, forçando que a ordem entre aquelas duas tarefas fosse fixa. O tempo de resolução caiu de 47 minutos para 11 minutos. Não é trivial perceber isso só olhando a fórmula.