Progressões Aritméticas E Geométricas

Achar o enésimo termo sem perder a sanidade

A gente começa pela PA porque é mais simples de entender na prática. Progressão aritmética é só uma sequência onde cada termo nasce da soma do anterior mais um valor fixo. Esse valor fixo se chama razão. Se você tem uma fila de estoque que sobe 15 unidades por dia, isso é uma PA com razão igual a 15. O primeiro termo é o que já existia no início. A fórmula do enésimo termo, a_n = a_1 + (n - 1) * r, funciona porque você vai somando a razão n-1 vezes a partir do primeiro termo. Não tem mistério. Já a PG, progressão geométrica, é outra coisa. Cada termo vem da multiplicação do anterior por uma razão fixa. Juros compostos são PG pura. Se você aplica R$ 1.000 a 5% ao mês, o montante todo mês vira uma sequência geométrica com razão 1,05. A fórmula é a_n = a_1 * q^(n-1). A diferença prática entre as duas aparece logo: em PA a variação é linear, em PG a variação é exponencial, e isso muda tudo quando você precisa projetar algo para longe no futuro.

Quando progressões aritméticas e geométricas se encontram

No meu dia a dia, a coisa mais comum é ter que decidir qual modelo usar para projetar dados. Às vezes a planilha pede uma PA e o negócio real se comporta como PG. Eu descobri isso de um jeito bem chato há uns anos quando fiquei responsável por projetar a demanda de peças sobressalentes para uma linha de produção. Os números dos três primeiros meses davam uma PA perfeita com razão 230 unidades. Achei que era isso mesmo, apliquei a fórmula do termo geral, fiz a previsão anual inteira baseada em PA, e fui aprobar o orçamento. Dois meses depois, olhando os dados reais, a curva tinha virado. O crescimento não era mais linear. Estávamos em uma PG com razão aproximadamente 1,12, porque o aumento vinha de um efeito de adoção, não de reposição fixa. A correção foi simples mas custou tempo: refiz todas as projeções do zero usando a soma da PG, que é S_n = a_1 * (q^n - 1) / (q - 1) quando q é diferente de 1. O erro no orçamento havia ficado na casa das centenas de milhares de reais porque uma PG cresce muito mais rápido do que uma PA parece crescer à primeira vista. A lição que ficou é básica e ninguém ensina bem: sempre verifique se a razão se mantém constante antes de assumir qualquer coisa. Olhe os dois primeiros degraus, depois os dois seguintes. Se a diferença entre diferenças não é zero, você provavelmente não está lidando com uma PA.

Outro ponto que as pessoas costumam errar é confundir soma parcial com termo geral. O termo geral te dá um único valor isolado. A soma parcial te dá o acumulado. Na prática, você quase sempre quer a soma parcial. Saber calcular a soma de uma PA, S_n = n/2 * (a_1 + a_n) ou S_n = n/2 * [2*a_1 + (n-1)*r], economiza muito tempo de cálculo manual, mas só faz sentido quando você entende que está somando blocos, não individualmente. Para PG, a soma parcial S_n = a_1 * (q^n - 1) / (q - 1) é igualmente útil, mas aqui surge um problema real: se q for igual a 1, a fórmula quebra porque o denominador zera. Nesse caso específico, a soma é simplesmente n * a_1, e muita gente esquece desse detalhe nas provas e nos cálculos rápidos. Tem mais uma armadilha que eu vejo todo mundo tropeçar: progressões com razão negativa ou frações entre zero e um. Em PG com |q|

1, a soma dos termos infinitos existe e é dada por S_infinito = a_1 / (1 - q). Isso é útil para modelar decaimento, amortização de dívidas com parcelas decrescentes, ou até certos processos de controle de qualidade onde a taxa de defeito cai proporcionalmente a cada lote. O problema é que pessoas tratam a fórmula infinita como se fosse válida para qualquer razão. Não é. Se q for maior ou igual a 1 em valor absoluto, a série diverge e esse cálculo infinito não tem sentido. Já vi gente aplicar S_infinito com q = 2 e terminar com um número que não representa nada no mundo real.

Na prática operacional, eu costumo usar uma verificação rápida antes de confiar em qualquer fórmula de soma. Multiplico manualmente os dois primeiros termos por 2 e comparo com a soma direta. Se não bate, revise a razão ou o primeiro termo antes de partir para n maior. Em planilhas, isso vira uma validação condicional que roda em segundos e evita horas de depuração quando o resultado final não faz sentido. A maior parte dos erros que eu enxergo em projetos reais vem de pessoas que pularam essa verificação básica porque acharam que a fórmula era infalível. A fórmula é correta, o problema é o input.