Có, có các giá trị độ chính xác kép (*) IEEE 754 x
là x != 1.0/(1.0/x)
.
Dễ dàng tạo ví dụ về giá trị bình thường với thuộc tính này bằng tay: một ví dụ được viết 0x1.fffffffffffffp0
trong C99's hexadecimal notation for floating-point values là như vậy mà 1.0/(1.0/0x1.fffffffffffffp0) == 0x1.ffffffffffffep0
. Thật là tự nhiên khi mong đợi 0x1.fffffffffffffp0
là một ví dụ phản đối vì 1.0/0x1.fffffffffffffp0
rơi vào đầu một ô, nơi các số dấu phẩy động ít dày đặc hơn, do đó, một lỗi tương đối lớn hơn đã xảy ra ở phân chia bên trong nhất. Chính xác hơn, 1.0/0x1.fffffffffffffp0
rơi ngay trên điểm giữa giữa 0.5
và bộ kế thừa chính xác kép của nó, sao cho 1.0/0x1.fffffffffffffp0
được làm tròn lên thành người kế thừa là 0,5, với một lỗi tương đối lớn.
Ở định dạng số thập phân %.16e
, 0x1.fffffffffffffp0
là 1.9999999999999998e+00
và 0x1.ffffffffffffep0
là 1.9999999999999996e+00
.
(*) không có lý do cho hàm nghịch đảo có thuộc tính trong câu hỏi cho bất kỳ định dạng IEEE 754
Nguồn
2016-08-02 07:46:38
Có những trường hợp rõ ràng nơi mà nó không thể, chẳng hạn như vô hạn và vô hạn, và có thể số không chuẩn hóa quá. Nhưng đó là một câu hỏi hay cho phần còn lại. –
Có vẻ như điều này sẽ làm việc tốt cho không và vô cùng ... –
Bằng ví dụ truy cập đơn giản, người ta có thể chỉ ra rằng một tương thích điểm nổi tương thích IEEE-754 không thể được hoàn nguyên theo cách này. Ví dụ, sử dụng chế độ làm tròn đến gần nhất hoặc thậm chí, với 'binary32':' x = 0x1.fffffep-1: 1.0f/x = 0x1.000002p + 0 1.0f/(1.0f/x) = 0x1. fffffcp-1' và với 'binary64':' x = 0x1.fffffffffffffp-1: 1.0f/x = 0x1.0000000000001p + 0 1.0f/(1.0f/x) = 0x1.ffffffffffffep-1' – njuffa