Quali affermazioni si possono eventualmente fare sull'accuratezza/precisione dei calcoli in virgola mobile?

Question

Sto lavorando su un'applicazione che esegue molti calcoli in virgola mobile.Usiamo VC++ su Intel x86 con valori in virgola mobile a doppia precisione.Affermiamo che i nostri calcoli sono accurati N cifre decimali (in questo momento 7, ma sto cercando di rivendicarne 15).

Facciamo molti sforzi per convalidare i nostri risultati rispetto ad altre fonti quando i nostri risultati cambiano leggermente (a causa del refactoring del codice, della pulizia, ecc.).So che molti fattori influiscono sulla precisione complessiva, come lo stato di controllo della FPU, il compilatore/ottimizzatore, il modello a virgola mobile e l'ordine generale delle operazioni stesse (ovvero l'algoritmo stesso), ma data l'incertezza intrinseca nei calcoli FP (ad esempio, 0,1 non può essere rappresentato), non sembra valido rivendicare alcun grado specifico di precisione per tutti i calcoli.

La mia domanda è questa:è valido fare affermazioni sull'accuratezza dei calcoli FP in generale senza fare alcun tipo di analisi (come l'analisi degli intervalli)?Se sì, quali affermazioni si possono avanzare e perché?

MODIFICARE:

Quindi, dato che i dati di input sono accurati, ad esempio, N cifre decimali, si può garantire il risultato di eventuali calcoli arbitrari, dato che viene utilizzata la doppia precisione?Ad esempio, se i dati di input hanno 8 cifre decimali significative, l'output avrà almeno 5 cifre decimali significative...?

Utilizziamo librerie matematiche e non siamo a conoscenza di alcuna garanzia che possano o meno fornire.Gli algoritmi che utilizziamo non vengono necessariamente analizzati in alcun modo per verificarne la precisione.Ma anche dato un algoritmo specifico, l’implementazione influenzerà i risultati (ad esempio, basta cambiare l’ordine di due operazioni di addizione).Esiste qualche garanzia intrinseca quando si utilizza, ad esempio, la doppia precisione?

UN'ALTRA MODIFICA:

Convalidiamo empiricamente i nostri risultati rispetto ad altre fonti.Quindi siamo solo fortunati quando raggiungiamo, diciamo, una precisione di 10 cifre?

Answer 1

A meno che il codice utilizza solo le funzioni di base di cui IEEE 754 (+, -, *, / e radice quadrata), non si sa nemmeno quanto la perdita di precisione ogni chiamata a funzioni di libreria fuori del vostro controllo (funzioni trigonometriche, exp / log, ...) introdurre. Funzioni di fuori della base 5 non sono garantiti per essere, e di solito non sono, preciso in 1ULP.

Si può fare verifiche empiriche, ma questo è ciò che essi rimangono ... empirica. Non dimenticare la parte circa che vi sia alcuna garanzia nel contratto di licenza del software!

Se il software è stato safety-critical, e non ha chiamato funzioni matematiche di libreria attuate, si potrebbe considerare http://www-list.cea.fr/labos/gb/LSL/fluctuat/index.html . Ma solo software critico è valsa la pena e ha la possibilità di adattarsi ai vincoli di analisi di questo strumento.

Mi sembra, dopo la modifica, per lo più preoccupati per il compilatore fare le cose nella schiena. Si tratta di una paura naturale avere (perché, come per le funzioni matematiche, non è in controllo). Ma è piuttosto improbabile che sia il problema. Il tuo compilatore può calcolare con una precisione superiore a quello che hai chiesto (extendeds 80-bit quando ha chiesto per il doppio a 64 bit o doppie a 64 bit quando ha chiesto per carri a 32 bit). Ciò è consentito dallo standard C99. In tutto-a-vicina, puo introdurre errori doppio arrotondamento. Ma è solo 1ULP si stanno perdendo, e così di rado che non c'è da preoccuparsi. Ciò può causare sconcertante comportamenti, come in:

float x=1.0;
float y=7.0;
float z=x/y;
if (z == x/y) 
...
else
... /* the else branch is taken */

, ma che stavi cercando guai quando si è utilizzato == tra i numeri in virgola mobile.

Quando si dispone di codice che fa cancellazioni di proposito, come nell'algoritmo sommatoria di Kahan:

d = (a+b)-a-b;

e il compilatore ottimizza che in d=0;, hai un problema. E sì, questa ottimizzazione "come se l'operazione fosse galleggia associativo" è stato visto in compilatori generali. E ' non consentito dalla C99. Ma la situazione è migliorata, penso. autori del compilatore sono diventati più consapevoli dei pericoli di floating-point e cercare non più per ottimizzare in modo aggressivo. Inoltre, se si stesse facendo questo nel codice che non sarebbe questa domanda.

Answer 2

Come per tutte queste domande, devo rispondere semplicemente con la Ciò che ogni Computer Scientist dovrebbe sapere virgola mobile aritmetica . E 'assolutamente indispensabile per il tipo di lavoro che si sta parlando.

Answer 3

Risposta breve:. No

Motivo: Hai dimostrato (sì dimostrato ) che non si sta perdendo una certa precisione come si va avanti? Sei sicuro? Capite la precisione intrinseca di eventuali funzioni di libreria che si sta utilizzando per le funzioni trascendentali? Avete calcolato i limiti di errori additivi? Se si utilizza un algoritmo iterativo, sai quanto bene converge quando si esce? Questa roba è difficile.

Answer 4

Dato che i tuoi fornitori di macchine, compilatori, librerie runtime e sistemi operativi non fanno alcuna affermazione del genere sulla virgola mobile precisione, dovresti considerarlo un avvertimento che il tuo gruppo dovrebbe essere cauto nel fare affermazioni che potrebbero essere sottoposte a un severo esame se i clienti ti portassero in tribunale.

Senza effettuare una verifica formale dell’intero sistema, eviterei tali affermazioni.Lavoro su software scientifico che ha implicazioni indirette sulla sicurezza umana, quindi abbiamo considerato queste cose in passato e non facciamo questo tipo di affermazioni.

Potresti fare affermazioni inutili a riguardo precisione di calcoli in virgola mobile doppi (di lunghezza), ma sarebbe sostanzialmente inutile.

Rif: Le insidie ​​​​della verifica dei calcoli in virgola mobile da ACM Transactions on Programming Languages ​​and Systems 30, 3 (2008) 12

Answer 5

No, non è possibile effettuare qualsiasi reclamo. Se si voleva fare così, si avrebbe bisogno di fare quanto segue:

• assumere un esperto in calcolo numerico per analizzare gli algoritmi.
• In entrambi ottenere il vostro biblioteca e compilatore fornitori ad aprire le loro fonti di detto esperto per l'analisi, o farli firmare sulla semantica duri e limiti di errore.

doppia precisione in virgola mobile tipicamente trasporta circa 15 cifre di precisione decimale, ma ci sono troppi modi per alcuni o tutti di tale precisione da perdere, che sono troppo sottili per un non esperto per diagnosticare, di ricorrere, come quello che si vorrebbe di rivendicare.

Ci sono modi relativamente semplici per continuare a correre limiti di errore che permetterà di fare la precisione sostiene qualsiasi specifica di calcolo, ma fare affermazioni circa l'esattezza di tutti i calcoli eseguiti con il software è un ordine molto più alto .

Answer 6

Un numero di precisione doppia su una CPU Intel ha un po 'meglio di 15 cifre significative (decimale).

L'errore potrntial per un semplice calcolo è nel ballparl di n / 1.0e15, dove n è l'ordine di grandezza del numero (s) si sta lavorando. Ho il sospetto che Intel ha specifiche per l'accuratezza di calcoli FP basati sulla CPU.

L'errore potenziale di funzioni di libreria (come cos e log) di solito è documentato. In caso contrario, si può guardare il codice sorgente (ad esempio thr fonte GNU) e calcolarla.

Si potrebbe calcolare le barre di errore per i vostri calcoli proprio come si farebbe per i calcoli manuali.

Una volta fatto questo, si può essere in grado di ridurre l'errore ordinamento giudizioso dei calcoli.

Answer 7

Dal momento che ti sembra di essere preoccupati per la precisione dei calcoli arbitrari, qui è un approccio che si può provare: eseguire il codice con differenti modalità di arrotondamento per i calcoli in virgola mobile. Se i risultati sono abbastanza vicini l'uno all'altro, si sono probabilmente bene. Se i risultati non sono vicini, è necessario iniziare a preoccuparsi.

La differenza massima nei risultati vi darà un limite inferiore sulla precisione dei calcoli.