Maior Que Menor Que Sinais

Operadores de comparação no dia a dia

Todo mundo já se deparou com maior que menor que sinais numa planilha ou num script e ficou na dúvida se era > ou <, principalmente quando o código já estava legado e sem documentação. Eu passei uma tarde inteira debugando um relatório financeiro porque um funcionário tinha escrito `if valor < 1000` achando que aquilo filtrava os valores acima da milhar. Óbvio que não. O sinal funciona do jeito que a seta aponta: a abertura larga fica do lado do número maior. Ficou confuso? Vai ficar mais claro abaixo. A regra prática que eu uso desde 2008 é a seguinte: imagine que o símbolo é uma boca de crocododo que quer comer o número maior. O lado aberto sempre aponta para o valor predominante. Então `5 > 3` lê-se "cinco é maior que três", porque a abertura larga fica virada para o cinco. Inverter isso — colocar `5 < 3` — inverte o sentido e o teste falha silenciosamente em qualquer linguagem séria. Tem um detalhe que quase ninguém menciona e que já me custou duas horas de manutenção em um sistema de estoque: em Python, você pode encadear comparações semanticamente corretas, como `10 < x < 20`, e o interpretador avalia como `(10 < x) and (x < 20)` automaticamente. Isso é útil, mas perigoso se você vier de C ou Java, onde `10 < x

20` devolve um booleano travado e nunca faz o que você espera. O mesmo vale para JavaScript, que até hoje tem comportamentos estranhos de coerção de tipo nesse contexto. Sempre verifique a documentação da linguagem antes de encadear.

Outro problema real que encontrei foi num query SQL legado com condições mistas de `>=` e `<`. O banco de dados interpreta esses operadores de forma literal, mas quando você junta com `BETWEEN` ou com subconsultas que retornam NULL, o comportamento muda completamente. NULL comparado com qualquer operador de maior/menor retorna UNKNOWN, e a linha simplesmente some do resultado. Eu resolvi isso adicionando um `COALESCE(coluna, 0)` nos filtros, mas o efeito colateral é que zeros reais e valores nulos passam a ser tratados igual. Se o seu domínio admite zero como valor legítimo, essa workaround introduz bug disfarçado. A alternativa mais segura é usar `IS NOT NULL` explícito antes de aplicar a comparação numérica.

Uso em diferentes contextos

Em matemática, os símbolos são universais: `>` (maior que), `<` (menor que), `>=` (maior ou igual), `<=` (menor ou igual). A confusão aparece mesmo entre estudantes porque a orientação visual é idêntica à de setas, e o cérebro tende a associar "abertura para a direita = maior" de forma inconsistente dependendo do hábito de leitura. Na programação, a coisa fica mais interessante. Em linguagens como Rust e Go, os mesmos símbolos existem mas o type checker é rigoroso: você não pode comparar string com inteiro sem fazer cast explícito, e tentar `if "10" > 5` gera erro em tempo de compilação. Isso evita aquela categoria de bug que aparece só em produção, quando os dados entram com formatação diferente. Já em Python, a flexibilidade é maior, mas a ambiguidade também: `True > False` retorna True porque True é coerado para 1 e False para 0. Não é um bug, é uma escolha de design que pega todo mundo de surpresa na primeira vez. Em eletrônica digital, os sinais aparecem em diagramas de fluxo de decisão e em portas lógicas. O operador `>` correspondente à porta comparadora de magnitude, que em chips como o 74LS85 compara dois bits simultaneamente. A limitação prática aqui é que chips de 4 bits encadeados perdem precisão se você não ligar corretamente os pinos de carry, e o resultado do maior/menor fica errado nos bits mais significativos. Eu já vi engenheiros junior gastarem dias procurando um bug que na verdade era um pinout errado no breadboard.

Pegadinhas que não estão no manual

A primeira: floating point. Comparar `0.1 + 0.2 > 0.3` em quase todas as linguagens retorna False, porque a representação binária de ponto flutuante não é exata. A diferença é da ordem de 1e-17, mas o comparador não sabe disso. A solução profissional é usar uma tolerância, tipo `abs(a - b) <= epsilon`, onde epsilon é algo como 1e-9 para aplicações financeiras e 1e-12 para simulações científicas. Esquecer disso é a causa número um de bugs discretos em sistemas de pagamento. A segunda: ordem de precedência. Em Expressões matemáticas escritas à mão, `>` e `<` têm precedência menor que `+` e `-`, mas maior que `=`. Em Python, a cadeia de comparação tem precedência ainda mais baixa que operações bit a bit. O resultado é que `a > b &c` pode ser interpretado de formas radicalmente diferentes dependendo da linguagem e do parêntese que você esqueceu. Sempre use parênteses explícitos quando misturar operadores de comparação com bitwise ou lógicos. O código fica mais longo, mas a intenção fica clara. A terceira, e mais sutil: internacionalização de símbolos. Em alguns contextos tipográficos, especialmente em publicações acadêmicas europeias, você encontra `` e `` (Unicode U+2264 e U+2265) em vez de `<=` e `>=`. Isso é puramente estético, mas se o seu sistema faz parsing manual de strings sem normalizar para Unicode NFC, esses caracteres podem passar despercebidos. Eu levei três dias para descobrir que um relatório gerado por um sistema legado francês continha esses glyphs e meu script de extração estava ignorando linhas inteiras porque o regex esperava o ASCII equivalente.

Quando esses sinais realmente falham

Comparação de strings lexicográficas não segue a intuição humana. `"10" < "2"` é verdadeiro em praticamente todas as linguagens, porque a comparação é caractere por caractere, e o dígito "1" vem antes do "2" no código Unicode. Se o seu objetivo é ordenar números escritos como texto, faça o cast antes. Caso contrário, você vai ter listas ordenadas que parecem erradas e vai levar tempo demais para perceber a causa raiz. Valores NaN (Not a Number) quebram todas as regras. `NaN > 5`, `NaN < 5`, `NaN == NaN` — tudo retorna False. Isso é definido pelo padrão IEEE 754 e não é um bug de implementação. Se o seu sistema lida com dados científicos ou sensoriais, espere NaNs e trate-os explicitamente com funções como `math.isnan()` ou `Number.isNaN()`, não com comparações diretas. Tentar usar `>` ou `<` para detectar NaN é perda de tempo garantida. Em bancos de dados, índices não são usados de forma eficiente quando você aplica funções nos lados da comparação. `WHERE ABS(valor) > 100` força um scan completo porque o otimizador não pode mapear a expressão para um intervalo de índice. Se a consulta precisa ser rápida, reescreva como `WHERE valor > 100 OR valor < -100`. O resultado é o mesmo, mas o plano de execução muda drasticamente em tabelas com milhões de linhas.