Calcolo robusto della media di due numeri in virgola mobile?

Sia x, yessere due numeri in virgola mobile. Qual è il modo giusto per calcolare la loro media?

Il modo ingenuo (x+y)/2può provocare traboccamenti quando xe ysono troppo grandi. Penso 0.5 * x + 0.5 * yforse meglio, ma comporta due moltiplicazioni (che forse è inefficiente) e non sono sicuro che sia abbastanza buono. C'è un modo migliore?

Un'altra idea con cui ho giocato è (y/2)(1 + x/y)if x<=y. Ma ancora una volta, non sono sicuro di come analizzare questo e dimostrare che soddisfa i miei requisiti.

Inoltre, ho bisogno di una garanzia che la media calcolata sarà >= min(x,y)e <= max(x,y). Come sottolineato nella risposta di Don Hatch , forse un modo migliore di porre questa domanda è: qual è un'implementazione della media di due numeri che dà sempre il risultato più accurato possibile? Cioè, se xe ysono numeri in virgola mobile, come calcolare il numero in virgola mobile più vicino a (x+y)/2? In questo caso, la media calcolata è automaticamente >= min(x,y)e <= max(x,y). Vedi la risposta di Don Hatch per i dettagli.

Nota: la mia priorità è la solida precisione. L'efficienza è sacrificabile. Tuttavia, se ci sono molti algoritmi robusti e precisi, sceglierei il più efficiente.

Penso che l' accuratezza e la stabilità degli algoritmi numerici di Higham riguardino il modo in cui si possono analizzare questi tipi di problemi. Vedi il capitolo 2, in particolare l'esercizio 2.8.

In questa risposta vorrei sottolineare qualcosa che non è realmente affrontato nel libro di Higham (non sembra essere molto conosciuto, del resto). Se sei interessato a dimostrare le proprietà di semplici algoritmi numerici come questi, puoi usare la potenza dei moderni solutori SMT ( Teorie del Modulo di soddisfazione ), come z3 , usando un pacchetto come sbv in Haskell. Questo è un po 'più semplice rispetto all'uso di carta e matita.

Supponiamo che mi venga dato $0\leq x\leq y$ , e vorrei sapere se soddisfa x ≤ z ≤ y . Il seguente codice Haskell$z=(x+y)/2$$x\leq z\leq y$

import Data.SBV

test1 :: (SFloat -> SFloat -> SFloat) -> Symbolic SBool
test1 fun =
  do [x, y] <- sFloats ["x", "y"]
     constrain $ bnot (isInfiniteFP x) &&& bnot (isInfiniteFP y)
     constrain $ 0 .<= x &&& x .<= y
     let z = fun x y
     return $ x .<= z &&& z .<= y

test2 :: (SFloat -> SFloat -> SFloat) -> Symbolic SBool
test2 fun =
  do [x, y] <- sFloats ["x", "y"]
     constrain $ bnot (isInfiniteFP x) &&& bnot (isInfiniteFP y)
     constrain $ x .<= y
     let z = fun x y
     return $ x .<= z &&& z .<= y

mi permetterà di farlo automaticamente . Ecco test1 funla proposizione che per tutti i galleggianti finiti x , y con 0 ≤ x ≤ y .$x \leq \mathit{fun}(x,y) \leq y$$x,y$$0\leq x\leq y$

λ> prove $ test1 (\x y -> (x + y) / 2)
Falsifiable. Counter-example:
  x = 2.3089316e36 :: Float
  y = 3.379786e38 :: Float

Trabocca. Supponiamo che ora prenda la tua altra formula: $z=x/2+y/2$

λ> prove $ test1 (\x y -> x/2 + y/2)
Falsifiable. Counter-example:
  x = 2.3509886e-38 :: Float
  y = 2.3509886e-38 :: Float

Non funziona (a causa del underflow graduale: , che potrebbe non essere intuitivo a causa del fatto che tutta l'aritmetica è base-2).$(x/2)\times2 \neq x$

Ora prova :$z=x + (y-x)/2$

λ> prove $ test1 (\x y -> x + (y-x)/2)
Q.E.D.

Lavori! Il Q.E.D.è una prova che la test1proprietà vale per tutti i carri come sopra definito.

Che dire dello stesso, ma limitato a (invece di 0 ≤ x ≤ y )?$x\leq y$$0\leq x\leq y$

λ> prove $ test2 (\x y -> x + (y-x)/2)
Falsifiable. Counter-example:
  x = -3.1300826e34 :: Float
  y = 3.402721e38 :: Float

Ok, quindi se trabocca, che ne dici di $y-x$ ?$z = x + (y/2-x/2)$

λ> prove $ test2 (\x y -> x + (y/2 - x/2))
Q.E.D.

Quindi sembra che tra le formule che ho provato qui, sembra funzionare (anche con una prova). L'approccio del risolutore SMT mi sembra un modo molto più rapido di rispondere ai sospetti su semplici formule in virgola mobile rispetto all'analisi degli errori in virgola mobile con carta e matita.$x + (y/2 - x/2)$

Infine, l'obiettivo di precisione e stabilità è spesso in contrasto con l'obiettivo della prestazione. Per quanto riguarda le prestazioni, non vedo davvero come si possa fare meglio di , soprattutto perché il compilatore farà comunque il duro lavoro di tradurre questo in istruzioni macchina per te.$(x+y)/2$

PS Questo è tutto con l'aritmetica in virgola mobile IEEE754 a precisione singola. Ho controllato con aritmetica a doppia precisione (sostituirecon), e funziona anche.$x \leq x + (y/2-x/2) \leq y$SFloatSDouble

-ffast-math$(x+y)/2$

PPPS Mi sono lasciato trasportare un po 'guardando solo espressioni algebriche semplici senza condizionali. La formula di Don Hatch è strettamente migliore.

Innanzitutto, osserva che se hai un metodo che fornisce una risposta più accurata in tutti i casi, allora soddisferà le tue condizioni richieste. (Nota che dico una risposta più accurata piuttosto che la risposta più accurata, dal momento che potrebbero esserci due vincitori.) Prova: se, al contrario, hai una risposta il più accurata possibile che non soddisfa la condizione richiesta, che significa o answer<min(x,y)<=max(x,y)(nel qual caso min(x,y)è una risposta migliore, una contraddizione), oppure min(x,y)<=max(x,y)<answer(nel qual caso max(x,y)è una risposta migliore, una contraddizione).

Quindi penso che ciò significhi che la tua domanda si riduce a trovare una risposta il più accurata possibile. Supponendo che l'aritmetica IEEE754 sia valida, propongo quanto segue:

if max(abs(x),abs(y)) >= 1.:
    return x/2. + y/2.
else:
    return (x+y)/2.

La mia tesi secondo cui ciò fornisce una risposta più accurata è un'analisi del caso alquanto noiosa. Ecco qui:

• Astuccio max(abs(x),abs(y)) >= 1. :

  • La sottoclasse né x né y viene denormalizzata: in questo caso la risposta calcolata x/2.+y/2. manipola le stesse mantisse e quindi fornisce la stessa risposta esatta del calcolo (x+y)/2che produrrebbe se assumessimo esponenti estesi per evitare il trabocco. Questa risposta può dipendere dalla modalità di arrotondamento ma in ogni caso è garantita da IEEE754 la migliore risposta possibile (dal fatto che il calcolo x+yè la migliore approssimazione a matematica x + y, e la divisione per 2 è esatta in questo Astuccio).

  • Il sottocase x è denormalizzato (e così abs(y)>=1):

    answer = x/2. + y/2. = y/2. since abs(x/2.) is so tiny compared to abs(y/2.) = the exact mathematical value of y/2 = a best possible answer.

  • La sottoclasse y è denormalizzata (e così abs(x)>=1): analoga.

• Astuccio max(abs(x),abs(y)) < 1. :
  • Sottoscrivere il calcolo non x+yè né denormalizzato né denormalizzato e "pari": anche se il calcolo x+ypotrebbe non essere esatto, è garantito da IEEE754 come una migliore approssimazione possibile al matematico x + y. In questo caso la successiva divisione per 2 nell'espressione (x+y)/2.è esatta, quindi la risposta calcolata (x+y)/2.è la migliore approssimazione possibile al matematico (x + y) / 2.
  • Sottrai che il calcolo x+yè denormalizzato e "dispari": in questo caso esattamente uno di x, y deve anche essere denormalizzato-e- "dispari", il che significa che l'altro di x, y è denormalizzato con il segno opposto, e quindi il calcolo x+yè esattamente il matematico x + y, e quindi il calcolo (x+y)/2.è garantito da IEEE754 per essere la migliore approssimazione possibile al matematico (x + y) / 2.

Per i formati binari in virgola mobile IEEE-754, esemplificati da binary64 calcolo (doppia precisione), S. Boldo ha formalmente dimostrato che il semplice algoritmo mostrato di seguito fornisce la media correttamente arrotondata.

Sylvie Boldo, "Verifica formale di programmi che calcolano la media in virgola mobile". In Conferenza internazionale sui metodi di ingegneria formale , pagg. 17-32. Springer, Cham, 2015. ( bozza online )

$(x+y)/2$$x/2 + y/2$binary64$C \in [2^{-967}, 2^{970}]$$C$ in modo da fornire le migliori prestazioni per un caso d'uso particolare.

Questo produce il seguente ISO-C99codice esemplare :

double average (double x, double y) 
{
    const double C = 1; /* 0x1p-967 <= C <= 0x1p970 */
    return (C <= fabs (x)) ? (x / 2 + y / 2) : ((x + y) / 2);
}

In un recente lavoro di follow-up, S. Boldo e i coautori hanno mostrato come ottenere i migliori risultati possibili per i formati decimali IEEE-754 in virgola mobile utilizzando operazioni di aggiunta multipla (FMA) fuse e una nota precisione raddoppiare blocco (TwoSum):

Sylvie Boldo, Florian Faissole e Vincent Tourneur, "Un algoritmo formalmente provato per calcolare la media corretta dei numeri decimali in virgola mobile". Nel 25 ° Simposio IEEE sull'aritmetica informatica (ARITH 25) , giugno 2018, pp. 69-75. ( bozza online )

Anche se potrebbe non essere super efficiente dal punto di vista delle prestazioni, esiste un modo molto semplice per (1) assicurarsi che nessuno dei numeri sia maggiore di uno xo y(nessun overflow) e (2) mantenere il virgola mobile "accurato" come possibile (e (3) , come bonus aggiuntivo, anche se viene utilizzata la sottrazione, nessun valore verrà mai memorizzato come numero negativo.

float difference = max(x, y) - min(x, y);
return min(x, y) + (difference / 2.0);

In effetti, se vuoi davvero andare per la precisione, non hai nemmeno bisogno di eseguire la divisione sul posto; restituire semplicemente i valori di min(x, y)e differenceche è possibile utilizzare per semplificare logicamente o manipolare in seguito.

Converti in precisione più alta, aggiungi i valori lì e converti indietro.

Non dovrebbe esserci overflow nella precisione superiore e se entrambi si trovano nell'intervallo di virgola mobile valido, anche il numero calcolato dovrebbe essere all'interno.

E dovrebbe essere tra di loro, nel peggiore dei casi solo la metà del numero più grande se la preclusione non è sufficiente.

teoricamente, x/2 può essere calcolato sottraendo 1 dalla mantissa.

Tuttavia, implementare effettivamente operazioni bit per bit come questa non è necessariamente semplice, soprattutto se non si conosce il formato dei numeri in virgola mobile.

Se puoi farlo, l'intera operazione è ridotta a 3 addizioni / sottrazioni, il che dovrebbe essere un miglioramento significativo.

Stavo pensando sulla stessa linea di @Roland Heath ma non posso ancora commentare, ecco la mia opinione:

x/2 può essere calcolato sottraendo 1 da esponente (non mantissa, sottraendo 1 dalla mantissa è sottraendo 2^(value_of_exponent-length_of_mantissa)dal valore totale).

Senza limitazione del caso generale, supponiamo x < y. (If x > y, rietichettare le variabili. If x = y,(x+y) / 2 è banale.)

• Trasformare (x+y) / 2 inx/2 + y/2 , che può essere eseguito da due sottrazioni intere (da una dall'esponente)
  • Tuttavia, esiste un limite inferiore per l'esponente a seconda della rappresentazione. Se l'esponente è già minimo prima di sottrarre 1, questo metodo richiederà la gestione di casi speciali. xFarà un esponente minimox/2 più piccolo di quanto sia rappresentabile (supponendo che la mantissa sia rappresentata con un primo implicito 1).
  • Invece di sottrarre 1 dall'esponente di x, spostax la mantissa a destra di una (e aggiungi l'eventuale 1 iniziale implicito).
  • Sottrai 1 dall'esponente di y, se non è minimo. Se è minimo (y è maggiore di x, a causa della mantissa), sposta la mantissa a destra di uno (aggiungi l'eventuale 1 iniziale implicito).
  • Sposta la nuova mantissa xa destra secondo l'esponente di y.
  • Esegui l'aggiunta di numeri interi sulle mantisse, a meno che la mantissa di non xsia stata completamente spostata. Se entrambi gli esponenti erano minimi, quelli principali traboccerebbero, il che va bene, perché si suppone che quel trabocco diventi nuovamente un leader implicito.
• e un'aggiunta in virgola mobile.
  • Non riesco a pensare a nessun caso speciale qui; ad eccezione dell'arrotondamento, che si applica anche al cambio sopra descritto.