Um computador tentará dividir por zero?

Todos nós sabemos que 0/0é Undefinede retorna um erro se eu o colocasse em uma calculadora e se eu criasse um programa (pelo menos em C) o sistema operacional o encerraria quando tento dividir por zero.

Mas o que eu queria saber é se o computador tenta dividir por zero , ou apenas possui "proteção interna", de modo que, quando "vê" 0/0, retorna um erro antes mesmo de tentar calculá-lo?

A CPU foi incorporada na detecção. A maioria das arquiteturas de conjunto de instruções especifica que a CPU interceptará um manipulador de exceção para a divisão de números inteiros por zero (não acho que se importe se o dividendo for zero).

É possível que a verificação de um divisor zero ocorra paralelamente no hardware, juntamente com a tentativa de fazer a divisão; no entanto, a detecção da condição ofensiva efetivamente cancela a divisão e intercepta, portanto, não podemos realmente dizer se alguma parte disso, tentou a divisão ou não.

(O hardware geralmente funciona dessa maneira, fazendo várias coisas em paralelo e depois escolhendo o resultado apropriado, porque todas as operações podem começar imediatamente, em vez de serializar a escolha da operação apropriada.)

O mesmo mecanismo de interceptação para exceção também será usado quando a detecção de estouro estiver ativada, o que você solicita geralmente usando instruções add / sub / mul diferentes (ou um sinalizador nessas instruções).

A divisão de ponto flutuante também tem detecção embutida para dividir por zero, mas retorna um valor diferente ( IEEE 754 especifica NaN ) em vez de interceptar um manipulador de exceção.

Hipoteticamente, se a CPU omitir qualquer detecção por tentativa de dividir por zero, os problemas podem incluir:

• travar a CPU (por exemplo, em um loop inf.) - isso pode acontecer se a CPU usar um algoritmo para dividir que para quando o numerador for menor que o divisor (em valor absoluto). Um travamento como esse contaria praticamente como travar a CPU.
• uma resposta de lixo (possivelmente previsível), se a CPU usar um contador para terminar a divisão no número máximo possível de etapas de divisão (por exemplo, 31 ou 32 em uma máquina de 32 bits).

Depende do idioma, do compilador, se você está usando números inteiros ou de ponto flutuante, e assim por diante.

Para número de ponto flutuante, a maioria das implementações usa o padrão IEEE 754 , onde a divisão por 0 é bem definida. 0/0 fornece um resultado bem definido de NaN (não um número), e x / 0 para x ≠ 0 fornece + Infinity ou -Infinity, dependendo do sinal de x.

Em linguagens como C, C ++ etc., a divisão por zero invoca um comportamento indefinido. Portanto, de acordo com a definição da linguagem, tudo pode acontecer. Especialmente coisas que você não quer que aconteça. Como tudo funcionando perfeitamente quando você escreve o código e destrói os dados quando o cliente o usa. Portanto, do ponto de vista do idioma, não faça isso . Alguns idiomas garantem que seu aplicativo falhe; cabe a eles como isso é implementado. Para esses idiomas, a divisão por zero falhará.

Muitos processadores possuem algum tipo de instrução de "divisão" integrada, que se comportará de maneira diferente dependendo do processador. Nos processadores Intel de 32 bits e 64 bits, as instruções "dividir" travam o aplicativo quando você tenta dividir por zero. Outros processadores podem se comportar de maneira diferente.

Se um compilador detectar que uma divisão por zero ocorrerá quando você executar algum código, e o compilador for bom para seus usuários, provavelmente fornecerá um aviso e gerará uma instrução interna de "divisão" para que o comportamento seja o mesmo.

Parece que você está se perguntando o que aconteceria se alguém fizesse uma CPU que não verifica explicitamente zero antes de dividir. O que aconteceria depende inteiramente da implementação da divisão. Sem entrar em detalhes, um tipo de implementação produziria um resultado com todos os bits definidos, por exemplo, 65535 em uma CPU de 16 bits. Outro pode desligar.

Mas o que eu queria saber é se o computador tenta dividir por zero, ou apenas possui "proteção interna", de modo que, quando "vê" 0/0, retorna um erro antes mesmo de tentar calculá-lo?

Como x/0não faz sentido, ponto final, os computadores devem sempre verificar a divisão por zero. Há um problema aqui: os programadores querem calcular (a+b)/csem ter que se preocupar em verificar se esse cálculo ainda faz sentido. A resposta secreta à divisão por zero pela CPU + tipo de número + sistema operacional + idioma é fazer algo bastante drástico (por exemplo, travar o programa) ou fazer algo excessivamente benigno (por exemplo, criar um valor que não prejudique sentido como o ponto flutuante IEEE NaN, um número que é "Não é um número").

Em um ambiente comum, espera-se (a+b)/cque um programador saiba se faz sentido. Nesse contexto, não há razão para verificar a divisão por zero. Se a divisão por zero ocorrer, e se a resposta da linguagem de máquina + linguagem de implementação + tipo de dados + sistema operacional a isso for travar o programa, tudo bem. Se a resposta for criar um valor que possa eventualmente poluir todos os números do programa, tudo bem também.

Nem "algo drástico" ou "excessivamente benigno" é a coisa certa a se fazer no mundo da computação de alta confiabilidade. Essas respostas padrão podem matar um paciente, derrubar um avião ou fazer uma bomba explodir no lugar errado. Em um ambiente de alta confiabilidade, um programador que escreve (a+b)/cserá morto durante a revisão de código ou, nos tempos modernos, talvez morto automaticamente por uma ferramenta que verifica construções de verboten. Nesse ambiente, esse programador deveria ter escrito algo como div(add(a,b),c)(e possivelmente alguma verificação do status do erro). Sob o capô, as div(e também as add) funções / macros protegem contra a divisão por zero (ou transbordamento no caso de add). O que essa proteção implica é muito específico da implementação.

Já sabemos disso x/0e 0/0não temos respostas bem definidas. O que acontece se você tentar calcular de 0/0qualquer maneira?

Em um sistema moderno, o cálculo é passado para a MPU na CPU e é sinalizado como uma operação ilegal, retornando NaN.

Em um sistema muito mais antigo, como os computadores domésticos dos anos 80 que não tinham divisão no chip, o cálculo era feito por qualquer software que estivesse sendo executado. Existem algumas opções possíveis:

• Subtraia cópias cada vez menores do divisor até o valor chegar a zero e acompanhe quais cópias de tamanho foram subtraídas
  • Se verificar zero antes da primeira subtração, sairá rapidamente e o resultado será 0
  • Se considerar que deve poder subtrair pelo menos uma vez, o resultado será 1
• Calcule os logaritmos de ambos os números, subtraia-os e aumente e à potência do resultado. Um método muito ineficiente comparado ao método de subtração acima, mas matematicamente válido
  • Pode ocorrer um estouro tentando calcular log(0)e o software usa suas rotinas de tratamento de erros ou falha
  • O software pode assumir que todos os logaritmos podem ser calculados em um número fixo de etapas e retornar um valor grande, mas incorreto. Como os dois logaritmos seriam os mesmos, a diferença seria 0e e ⁰ = 1, resultando em1

Em outras palavras, seria dependente da implementação o que aconteceria e seria possível escrever um software que produza resultados corretos e previsíveis para todos os valores, mas valores aparentemente estranhos para 0/0isso, no entanto, ainda são internamente consistentes.