Una prefazione: è noto che IEEE754 definisce cinque modalità di arrotondamento (nei termini dell'edizione 2008, con le mie abbreviazioni):
- arrotondamento al più vicino, pareggio (RNE) - la modalità predefinita per l'aritmetica binaria;
- arrotondamento al più vicino (RNA) - richiesto solo per l'aritmetica decimale, raramente supportato per uno binario;
- arrotondamento verso lo zero (RZ);
- arrotondamento verso positivo (RPI);
- arrotondamento verso il negativo (RMI).
Nella maggior parte dei casi, viene utilizzato RNE; è richiesto per impostazione predefinita per i calcoli binari e molte persone ignorano altre modalità o non sono disponibili (ad esempio, le librerie standard Java e Python non forniscono la modifica della modalità di arrotondamento).
In RNE e RNA, esiste un requisito esplicito per generare Infinity nei casi in cui un risultato è sufficientemente maggiore del numero finito più grande presentato. Letteralmente, citando la bozza IEEE754 con TeXization, "un risultato infinitamente preciso con grandezza almeno b ^ emax * (b - 0.5 * b ^ (1-p)) circonda a ∞ senza alcun segno di cambiamento"; tecnicamente, questo è identico a un'altra descrizione dello stesso approccio: un singolo valore, che sarebbe successivamente rappresentabile in caso di intervallo di esponente infinito (2 ^ 128 per "singolo" mobile, 2 ^ 1024 per "doppio" uno), viene aggiunto al set supportato durante il calcolo esatto, è possibile come punto di destinazione per l'arrotondamento, e quindi convertito all'infinito quando impacchettato sul risultato dell'operatore finale. (UPD: variante da @ gnasher729: precisione della mantissa limitata ma esponente illimitato, e quindi adatta al limite esponenziale, è anche adatta e ancora più facile da descrivere.) Ciò corrisponde bene al ruolo di "infinito" nell'aritmetica in virgola mobile - per contrassegnare un overflow del range passato, nonostante formalmente il risultato sia più vicino a qualsiasi numero finito che al vero infinito.
Diversamente dai modi di arrotondamento "più vicini", quelli "diretti" dettano principalmente un altro approccio; per RZ e RMI, + ∞ non viene mai generato. Il numero finito massimo in "double" (DBL_MAX) è circa 1,8e308. Se si moltiplica 1e308 per 1e308, il risultato è + ∞ per RNE, RNA e RPI, ma DBL_MAX per RZ e RMI. Per moltiplicare 1e308 per -1e308, il risultato è -∞ per RNE, RNA e RMI, ma -DBL_MAX per RZ e RPI. Questo "arrotondamento" è principalmente un catastrofico , non mi vergognerò di questa enfasi, perdita di accuratezza - per ordine di ~ 308 magnitudini decimali, o 1024 binari. (Sì, vedo che l'overflow è segnalato in questo caso, almeno nei miei test, e secondo lo standard, ma non è chiaro dove sia successo esattamente il trabocco e il valore finito fasullo può rovinare i risultati seguenti.)
Quindi, alla fine, la domanda: perché le modalità di arrotondamento diretto non arrotondano all'infinito se un risultato dell'operatore è sufficientemente lontano dall'intervallo di valori rappresentato, come fanno i modi "più vicini"? Si tratta di un problema ereditario o di un approccio intenzionale? In quest'ultimo caso, quale era l'obiettivo?