C có đôi khác với .NET không?

Question

So sánh một số mã C và F # Tôi đang cố gắng thay thế bằng, tôi quan sát thấy có một số khác biệt trong kết quả cuối cùng.

Làm việc sao lưu mã, tôi phát hiện ra rằng ngay cả ở đó cũng có sự khác biệt - mặc dù có những khác biệt nhỏ.

Mã bắt đầu bằng cách đọc dữ liệu từ tệp. và con số đầu tiên xuất hiện khác nhau. Ví dụ: trong F # (dễ viết hơn):

let a = 71.9497985840 
printfn "%.20f" a 

Tôi nhận được kết quả mong đợi (cho tôi) 71.94979858400000000000.

Nhưng trong C:

a = 71.9497985840; 
fprintf (stderr, "%.20f\n", a); 

in ra 71.94979858400000700000.

7 từ đó đến từ đâu?

Sự khác biệt chỉ nhỏ, nhưng nó làm phiền tôi vì tôi không biết tại sao. (Nó cũng làm phiền tôi bởi vì nó làm cho nó khó khăn hơn để theo dõi nơi hai phiên bản mã của tôi đang phân kỳ)

Answer 1

Đó là một sự khác biệt trong in ấn. Chuyển đổi giá trị đó để một IEEE754 double mang

Prelude Text.FShow.RealFloat> FD 71.9497985840 
71.94979858400000694018672220408916473388671875 

nhưng đại diện 71.949798584 là đủ để phân biệt các số từ các nước láng giềng. C, khi được yêu cầu in với độ chính xác 20 chữ số sau dấu thập phân chuyển giá trị được làm tròn chính xác thành số chữ số mong muốn, rõ ràng F # sử dụng biểu diễn xác định duy nhất ngắn nhất và đặt nó bằng số 0 mong muốn, giống như Haskell .

Answer 2

Nó chỉ làm tròn khác nhau. Các con số giống nhau (theo CPython, ít nhất):

>>> '%.44f' % 71.94979858400000000000 
'71.94979858400000694018672220408916473388671875' 
>>> '%.44f' % 71.94979858400000700000 
'71.94979858400000694018672220408916473388671875' 

Answer 3

Câu trả lời khác giải thích đầy đủ nguồn gốc của vấn đề (độ chính xác kép và làm tròn).

Nếu số của bạn thường có độ lớn vừa phải và độ chính xác thập phân là rất quan trọng (moreso so với tốc độ tính toán) thì có thể xem xét sử dụng định dạng .NET decimal. Điều này mang lại cho bạn 28-29 vị trí thập phân chính xác chính xác mà không có các lỗi làm tròn nhị phân phân số như lỗi kép. Hạn chế là phạm vi nhỏ hơn (không có số mũ lớn!).

http://msdn.microsoft.com/en-us/library/364x0z75%28v=vs.100%29.aspx

Answer 4

Đây là NET System.Double.ToString() phương pháp đó là sự khác biệt, phương pháp có thể chuyển đổi một đôi thành một chuỗi. Bạn có thể xem mã có liên quan bằng cách tải xuống nguồn CLR như được cung cấp trong SSCLI20. Việc chuyển đổi được thực hiện bởi hàm clr/src/vm/comnumber.cpp, COMNumber :: FormatDouble(). Trong đó trông like this, nhận xét trong mã là mô tả nhất về những gì đang diễn ra:

//In order to give numbers that are both friendly to display and round-trippable, 
//we parse the number using 15 digits and then determine if it round trips to the same 
//value. If it does, we convert that NUMBER to a string, otherwise we reparse using 17 digits 
//and display that. 

Thư viện thời gian chạy C không có tính năng đó.

Answer 5

Thông tin thêm cho bất kỳ ai ngại về điều này.

Sử dụng bit mã được tìm thấy here, tôi đã xác nhận (tôi tin) xác nhận rằng biểu diễn nhị phân cơ bản (ít nhất là cho số cụ thể này) giống nhau.

Dưới đây là các mẫu mã - lưu ý 'nhân zero bằng 0' để loại bỏ số 0 âm - tức là xấu khi được chuyển đổi thành dài.

//(C# this time) 
var d = 71.9497985840; //or other incoming double value 
if(d == 0) d = d * d; //for negative zero 
var longval = System.BitConverter.DoubleToInt64Bits(d); // = 4634763433907061836 

Trong C:

double d; 
long long a; 
d = 71.9497985840;  //or other incoming double value 
if(d == 0) d = d * d; //for negative zero 
a = *(long long*)&d; //= 4634763433907061836 

cập nhật - Tôi đi theo qua, và phát hiện ra rằng sự khác biệt đã được giới thiệu trong ma trận đảo ngược, bởi vì mỗi hệ thống gọi ra một thư viện khác nhau, thực hiện đảo ngược trong một cách khác ...