A fórmula que todo mundo decora e ninguém usa direito
A distancia entre dois pontos no plano cartesiano se calcula com a raiz quadrada da soma dos quadrados das diferenças nas coordenadas. O que parece simples na papeleta é onde a maioria das pessoas trava na prática, especialmente quando mistura escalas diferentes ou esquece que o resultado é sempre positivo. Eu já vi engenheiro juniores gastarem dois dias depurando um problema de renderização 3D porque o cálculo de distância retornava negativo em um dos eixos e o sistema de colisão não esperava isso. O frame-rate caiu pra quase zero e o bug parecia estar em outro lugar. Achei a solução apenas isolando o módulo que processava as coordenadas de teste.
Como calcular distancia entre dois pontos na prática
Pegue dois pontos, A com coordenadas (x1, y1) e B com (x2, y2). Subtraia x2 menos x1, eleva ao quadrado. Faça o mesmo com y2 menos y1, soma os dois resultados e tira a raiz quadrada da soma. A fórmula d = ((x2-x1)² + (y2-y1)²) é só uma forma curta de escrever isso. O detalhe que ninguém conta é que em computação gráfica você vai usar essa conta milhares de vezes por frame. Se seu código faz a raiz quadrada sem otimização, dependendo da linguagem e do hardware, o custo pode sair de 4 nanossegundos para 12 nanossegundos por chamada. Em um loop que roda 60 vezes por segundo com milhares de objetos, isso se acumula rápido.
Uma otimização que funciona na maioria dos casos é evitar a raiz quadrada quando você só precisa comparar distâncias, não o valor absoluto. Comparar d² com um threshold é sufficientee evita a operação mais cara. Isso reduz o tempo de processamento em cerca de 30 a 40 por cento em cenários de detecção de proximidade. No contexto de GPS e navegação, a coisa muda. A Terra não é plana, então a fórmula euclidiana padrão começa a introduzir erros que crescem conforme a distância aumenta. Para distâncias curtas, abaixo de 10 quilômetros, o erro fica na casa dos metros. Para rotas transcontinentais, o erro pode passar de 100 quilômetros. Nesses casos, usa-se a fórmula de Haversine ou a de Vincenty, que consideram o achatamento da esfera terrestre.
O problema que eu encontrei recentemente foi num sistema de geocercas para frotas. O cliente queria um raio de 500 metros como zona de alerta. A distância calculada com a fórmula plana funcionava bem perto do escritório, mas nas áreas mais ao sul do estado, onde a curvatura da Terra passa a importar mais, o sistema liberava veículos que estavam efetivamente fora da zona. Ajustei para usar o haversine nas proximidades maiores e mantive a fórmula plana só para distâncias abaixo de 2 quilômetros, onde a diferença é desprezível.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas que custaram horas do meu tempo
A ordem dos pontos não altera o resultado final, porque o quadrado elimina o sinal negativo. Mas se você calcular vetor direção primeiro e depois aplicar a norma, precisa ter cuidado com a normalização. Um erro comum é normalizar antes de calcular a distância, o que transforma tudo em uma unidade e destrói a informação de comprimento original. Outro problema que aparece com frequência é a precisão de ponto flutuante. Em linguagens como JavaScript, somar muitos números pequenos pode gerar erros de arredondamento que se acumulam. Se seu projeto trabalha com coordenadas de alta resolução, como mapeamento de precisão centimétrica, considere usar bibliotecas de número racional ou big decimal em vez de float padrão.
Quando se trata de espaços com mais de duas dimensões, a lógica se mantém. A distância euclidiana em 3D é apenas uma extensão natural: adiciona-se (z2-z1)² ao cálculo. Em n dimensões, o princípio é o mesmo, mas a visualização fica mais abstrata. Algoritmos de clustering e machine learning dependem fortemente desse conceito em espaços de alta dimensionalidade. Existe ainda a questão dos custos computacionais em tempo real. Se você precisa calcular distância entre múltiplos pares de pontos simultaneamente, como em simulações de física ou pathfinding, a abordagem ingênua de pares pode escalar mal. Estruturas como kd-trees e octrees reduzem a complexidade de O(n²) para algo próximo de O(n log n) na maioria dos casos práticos.
Um exemplo concreto: num projeto de simulação de tráfego urbano, calculávamos a distância de cada veículo a cada interseção a cada frame. Com 10 mil veículos e 500 interseções, o número de cálculos por frame era da ordem de 5 milhões. Implementando um kd-tree para consulta próxima, o tempo de processamento caiu de 80 milissegundos para cerca de 12 milissegundos por frame em máquinas padrão.
Quando a fórmula não serve mais
A distância euclidiana é a mais intuitiva, mas nem sempre a mais adequada. Em grafos e redes, a distância real entre dois pontos é a soma dos pesos das arestas no caminho mais curto, não a linha reta. Isso se chama distância de Manhattan ou distância de rede, e é o que aplica em cidades com quadras ortogonais onde você não pode atravessar edifícios. Em imagens digitais, a métrica de distância também varia. A distância Chebyshev considera apenas a maior diferença em qualquer eixo, o que é útil para movimentos de rei no xadrez digital. A distância de City Block soma todas as diferenças absolutas, refletindo o caminho que um táxi faria em Manhattan.
Se o seu problema envolve dados categóricos ou não geométricos, essas fórmulas desaparecem completamente. Aí entra a distância de Jaccard para conjuntos, ou a distância de Hamming para strings de mesma. Cada métrica carrega suposições diferentes sobre a natureza dos dados, e escolher a errada pode levar a conclusões completamente equivocadas em análises estatísticas. A lição que levei pra vida é simples: antes de aplicar qualquer fórmula de distância, entenda o que ela está realmente medindo e quais as suposições implícitas. O cálculo em si leva três linhas de código. A escolha certa da métrica leva horas de reflexão sobre o problema.
