Ho cercato invano per diversi giorni di trovare l'accuratezza delle funzioni matematiche (in math.h) del compilatore GNU GCC. Lo standard C99 afferma che il requisito di accuratezza delle funzioni matematiche in math.h è definito dall'implementazione. Non ho trovato alcuna menzione a riguardo nei manuali del compilatore GNU GCC. Qualcuno ha una risposta a questo?Precisione richiesta dalle funzioni matematiche GNU GCC?
Le funzioni math.h fanno parte della libreria GNU C, non del compilatore GCC. La loro accuratezza è documentata here, come parte dello GNU C Library manual.
Grazie per la risposta; Immagino che il '-'s in the table (1st link) significhi sconosciuto/non testato, sono corretto? – user1200373
@ user1200373 - Sì, presumo che il '-' significhi sconosciuto o non testato, ma non sono positivo. –
Si noti che questo si applica solo se si utilizza 'gcc' con GNU C Library, che è lungi dall'unica opzione.Ad esempio, se si utilizza 'gcc' su FreeBSD, si utilizza invece la libreria C di FreeBSD; se si utilizza 'gcc' in MinGW, si utilizza la libreria Microsoft C e così via. – caf
L'unica cosa sicura da assumere è che i '-' caratteri nella tabella di precisione matematica glibc:
significa "non testato", data la mancanza di documentazione ufficiale che suggerisce il contrario.
È una tabella di * errori. * '-' significa quindi nessun errore; un valore indica un errore di tale grandezza. Non è ragionevole presumere che funzioni come 'ciel()', 'exp(),' 'fmod()', ecc. Non siano state testate. – EJP
Quindi '0' (zero) sarebbe sicuramente più appropriato del fuorviante '-', forse. –
Gli errori sono infatti elencati here, ma secondo me l'ipotesi che "-" significa "correttamente arrotondato" (cioè 1/2 ULP) è quasi certamente confutata dalla dichiarazione nella parte superiore della pagina
[T] la libreria GNU C non mira ai risultati correttamente arrotondati per le funzioni nella libreria matematica ... Invece, gli obiettivi per la precisione delle funzioni senza risultati completamente specificati sono i seguenti; alcune funzioni di hanno errori che indicano che non soddisfano questi obiettivi in tutti i casi. In futuro, la libreria GNU C può fornire qualche altra correttamente arrotondamento funzioni con i nomi quali crsin proposti per una proroga per ISO C.
Dopo aver studiato il codice sorgente di un po ', ho trovato quello che sembra essere the results of a ulp test (per x86-64). Sembra che, per la modalità di arrotondamento predefinita (arrotondata al più vicina, i pareggi siano pari), testano esplicitamente solo double quando lo ulp di (80 bit IEEE) è peggiore di float. L'ipotesi implicita sembra essere che doublenon può essere peggio di long double. Per le modalità di arrotondamento diretto, sembrano sempre testare sia float e double in modo esplicito.
C'è comunque qualche stranezza.
exp.cos e tan, testano solo reale/complesso long double.
Esiste un particolare gruppo di funzioni a cui sei interessato? Direi che la lista delle funzioni in Math.h è abbastanza lunga. – Patrick87
Ho iniziato questa ricerca cercando _pow() _ e _exp() _ – user1200373