Un computer tenterà di dividere per zero?

Sappiamo tutti che 0/0è Undefinede restituisce un errore se dovessi inserirlo in una calcolatrice e se dovessi creare un programma (almeno in C) il sistema operativo lo terminerebbe quando provo a dividere per zero.

Ma quello che mi chiedevo è se il computer tenta persino di dividere per zero , o ha solo "protezione integrata", in modo che quando "vede" 0/0restituisce un errore anche prima di tentare di calcolarlo?

La CPU ha un rilevamento integrato. La maggior parte delle architetture del set di istruzioni specifica che la CPU eseguirà il trap a un gestore di eccezioni per la divisione di numeri interi per zero (non credo che importi se il dividendo è zero).

È possibile che il controllo per un divisore zero avvenga in parallelo nell'hardware insieme al tentativo di fare la divisione, tuttavia, il rilevamento della condizione offensiva annulla effettivamente la divisione e le trappole, quindi non possiamo davvero dire se una parte ne tentò la divisione o no.

(L'hardware spesso funziona in questo modo, facendo più cose in parallelo e quindi scegliendo il risultato appropriato in seguito perché in seguito ciascuna delle operazioni può iniziare immediatamente invece di serializzare sulla scelta dell'operazione appropriata.)

Lo stesso meccanismo trap to exception verrà utilizzato anche quando viene attivato il rilevamento di overflow, che di solito si richiede utilizzando diverse istruzioni add / sub / mul (o un flag su tali istruzioni).

Anche la divisione in virgola mobile ha un rilevamento incorporato per la divisione per zero, ma restituisce un valore diverso ( IEEE 754 specifica NaN ) invece di eseguire il trapping a un gestore eccezioni.

Ipoteticamente parlando, se la CPU omettesse qualsiasi rilevamento per tentare di dividere per zero, i problemi potrebbero includere:

• sospensione della CPU (ad es. in un loop inf.): ciò potrebbe accadere se la CPU utilizza un algoritmo per dividere che si arresta quando il numeratore è inferiore al divisore (in valore assoluto). Un blocco come questo conta praticamente come crash della CPU.
• una risposta di immondizia (probabilmente prevedibile), se la CPU utilizza un contatore per terminare la divisione al numero massimo possibile di passaggi di divisione (ad es. 31 o 32 su una macchina a 32 bit).

Dipende dalla lingua, dal compilatore, dal fatto che si utilizzino numeri interi o numeri in virgola mobile e così via.

Per il numero in virgola mobile, la maggior parte delle implementazioni utilizza lo standard IEEE 754 , dove la divisione per 0 è ben definita. 0/0 fornisce un risultato ben definito di NaN (non un numero) e x / 0 per x ≠ 0 indica + Infinito o -Infinito, a seconda del segno di x.

In linguaggi come C, C ++ ecc. La divisione per zero invoca un comportamento indefinito. Quindi, secondo la definizione della lingua, tutto può succedere. Soprattutto cose che non vuoi che accadano. Come tutto funziona perfettamente quando si scrive il codice e si distruggono i dati quando il cliente lo utilizza. Quindi dal punto di vista linguistico, non farlo . Alcune lingue garantiscono il crash dell'applicazione; dipende da loro come questo è implementato. Per quelle lingue, la divisione per zero andrà in crash.

Molti processori hanno una sorta di istruzione "divide" integrata, che si comporterà in modo diverso a seconda del processore. Sui processori Intel a 32 bit e 64 bit, le istruzioni "divide" causeranno il crash dell'applicazione quando si tenta di dividere per zero. Altri processori potrebbero comportarsi diversamente.

Se un compilatore rileva che si verificherà una divisione per zero quando si esegue del codice e il compilatore è utile per i suoi utenti, probabilmente ti darà un avvertimento e genererà un'istruzione di "divisione" incorporata in modo che il comportamento sia il stesso.

Sembra che ti stia chiedendo cosa succederebbe se qualcuno creasse una CPU che non controlla esplicitamente lo zero prima della divisione. Cosa succederebbe dipende interamente dall'attuazione della divisione. Senza entrare nei dettagli, un tipo di implementazione produrrebbe un risultato con tutti i bit impostati, ad esempio 65535 su una CPU a 16 bit. Un altro potrebbe riattaccare.

Ma quello che mi chiedevo è se il computer tenta persino di dividere per zero, o ha solo "protezione integrata", in modo che quando "vede" 0/0 restituisce un errore anche prima di tentare di calcolarlo?

Dal momento x/0che non ha senso, punto, i computer devono sempre controllare la divisione per zero. C'è un problema qui: i programmatori vogliono calcolare (a+b)/csenza doversi preoccupare di verificare se quel calcolo ha persino senso. La risposta nascosta alla divisione per zero per CPU + tipo di numero + sistema operativo + linguaggio è quella di fare qualcosa di piuttosto drastico (ad esempio, bloccare il programma) o fare qualcosa di eccessivamente benigno (ad esempio, creare un valore che non fa senso come il virgola mobile IEEE NaN, un numero che è "Not a Number").

In un ambiente normale, un programmatore dovrebbe sapere se (a+b)/cha senso. In questo contesto, non c'è motivo di verificare la divisione per zero. Se si verifica una divisione per zero e se il linguaggio macchina + linguaggio di implementazione + tipo di dati + risposta del sistema operativo a questo è quello di causare l'arresto anomalo del programma, va bene. Se la risposta è creare un valore che potrebbe eventualmente inquinare ogni numero nel programma, va bene lo stesso.

Né "qualcosa di drastico" o "eccessivamente benigno" è la cosa giusta da fare nel mondo dell'informatica ad alta affidabilità. Quelle risposte predefinite potrebbero uccidere un paziente, far schiantare un aereo di linea o far esplodere una bomba nel posto sbagliato. In un ambiente ad alta affidabilità, un programmatore che scrive (a+b)/cverrà scelto a morte durante la revisione del codice, o nei tempi moderni, forse scelto automaticamente a morte da uno strumento che verifica la presenza di costrutti verboten. In questo ambiente, quel programmatore dovrebbe invece aver scritto qualcosa sulla falsariga di div(add(a,b),c)(e forse un po 'di controllo dello stato di errore). Sotto il cofano, le funzioni div(e anche le add) / macro proteggono dalla divisione per zero (o overflow nel caso di add). Ciò che tale protezione comporta è molto specifico per l'implementazione.

Ormai lo sappiamo x/0e 0/0non abbiamo risposte ben definite. Cosa succede se si tenta di calcolare 0/0comunque?

Su un sistema moderno, il calcolo viene passato alla MPU all'interno della CPU e viene contrassegnato come un'operazione illegale, di ritorno NaN.

Su un sistema molto più vecchio, come i computer domestici degli anni '80 che non avevano una divisione su chip, il calcolo veniva eseguito da qualunque software fosse in esecuzione. Vi sono alcune scelte possibili:

• Sottrai le copie sempre più piccole del divisore fino a quando il valore non raggiunge lo zero e tieni traccia delle copie sottratte
  • Se verifica lo zero prima della prima sottrazione, uscirà rapidamente e il risultato sarà 0
  • Se assume che debba essere in grado di sottrarre almeno una volta, il risultato sarà 1
• Calcola i logaritmi di entrambi i numeri, sottrali e aumenta e alla potenza del risultato. Un metodo molto inefficiente rispetto al precedente metodo di sottrazione, ma matematicamente valido
  • Potrebbe verificarsi un overflow nel tentativo di calcolare log(0)e il software userebbe la sua routine di gestione degli errori o si arresterebbe in modo anomalo
  • Il software potrebbe presumere che tutti i logaritmi possano essere calcolati in un numero fisso di passaggi e restituire un valore elevato, ma non corretto. Poiché entrambi i logaritmi sarebbero uguali, la differenza sarebbe 0e e ⁰ = 1, dando un risultato di1

In altre parole, ciò dipenderebbe dall'implementazione e sarebbe possibile scrivere un software che produca risultati corretti e prevedibili per ogni valore, ma valori apparentemente strani per 0/0quello sono comunque coerenti internamente.