Ja, es gibt IEEE 754 doppelt genaue (*) Werte x
, die x != 1.0/(1.0/x)
sind.
Es ist einfach ein Beispiel für einen Normalwert mit dieser Eigenschaft von Hand zu bauen: die, die 0x1.fffffffffffffp0
in C99's hexadecimal notation for floating-point values geschrieben ist, so dass 1.0/(1.0/0x1.fffffffffffffp0) == 0x1.ffffffffffffep0
. Es war natürlich zu erwarten, dass 0x1.fffffffffffffp0
ein Gegenbeispiel ist, weil 1.0/0x1.fffffffffffffp0
auf den Anfang einer Binade fällt, wo Gleitkommazahlen weniger dicht sind, so dass ein größerer relativer Fehler in der innersten Division passieren musste. Genauer gesagt fällt 1.0/0x1.fffffffffffffp0
knapp über den Mittelpunkt zwischen 0.5
und seinem Double-Precision-Nachfolger, so dass 1.0/0x1.fffffffffffffp0
auf den Nachfolger von 0,5 aufgerundet wird, mit einem großen relativen Fehler.
In dezimal %.16e
Format, 0x1.fffffffffffffp0
ist 1.9999999999999998e+00
und 0x1.ffffffffffffep0
ist 1.9999999999999996e+00
.
(*) gibt es keinen Grund für die Umkehrfunktion die Eigenschaft in der Frage für eine des IEEE 754-Format haben
Es gibt offensichtliche Fälle, in denen es kann nicht, wie unendlich und unbestimmt, und möglicherweise denormalisierte Zahlen auch. Aber es ist eine gute Frage für den Rest. –
Es scheint, als würde dies für Null und Unendlich gut funktionieren ... –
Durch einfaches Gegenbeispiel kann man zeigen, dass ein IEEE-754-konformer Gleitkomma-Reziprok nicht auf diese Weise zurückgesetzt werden kann. Verwenden Sie zum Beispiel den Rundungsmodus to-nearest-or-even mit 'binary32':' x = 0x1.fffffep-1: 1.0f/x = 0x1.000002p + 0 1.0f/(1.0f/x) = 0x1. fffffcp-1' und mit 'binary64':' x = 0x1.fffffffffffffp-1: 1.0f/x = 0x1.0000000000001p + 0 1.0f/(1.0f/x) = 0x1.ffffffffffffep-1' – njuffa