Có an toàn để kiểm tra các giá trị dấu chấm động cho bằng 0 không?

Tôi biết bạn không thể dựa vào bình đẳng giữa các giá trị kiểu kép hoặc thập phân một cách bình thường, nhưng tôi tự hỏi liệu 0 có phải là trường hợp đặc biệt hay không.

Mặc dù tôi có thể hiểu được sự thiếu chính xác giữa 0,00000000000001 và 0,00000000000002, nhưng bản thân 0 dường như khá khó để làm rối vì nó chỉ là con số không. Nếu bạn không chính xác vào không có gì, nó không còn là gì nữa.

Nhưng tôi không biết nhiều về chủ đề này nên không phải để tôi nói.

double x = 0.0;
return (x == 0.0) ? true : false;

Điều đó sẽ luôn luôn trở thành sự thật?

Có thể an toàn khi kỳ vọng rằng phép so sánh sẽ trả về truenếu và chỉ khi biến kép có giá trị chính xác 0.0(tất nhiên là trong đoạn mã gốc của bạn). Điều này phù hợp với ngữ nghĩa của ==toán tử. a == bcó nghĩa là " abằng với b".

Sẽ không an toàn (vì nó không chính xác ) khi kỳ vọng rằng kết quả của một phép tính nào đó sẽ bằng 0 trong số học kép (hay nói chung hơn là dấu phẩy động) bất cứ khi nào kết quả của cùng một phép tính trong Toán học thuần túy bằng 0. Điều này là do khi các phép tính đi vào nền tảng, lỗi chính xác dấu phẩy động xuất hiện - một khái niệm không tồn tại trong số học Số thực trong Toán học.

Nếu bạn cần thực hiện nhiều phép so sánh "bình đẳng", bạn có thể viết một hàm trợ giúp nhỏ hoặc phương thức mở rộng trong .NET 3.5 để so sánh:

public static bool AlmostEquals(this double double1, double double2, double precision)
{
    return (Math.Abs(double1 - double2) <= precision);
}

Điều này có thể được sử dụng theo cách sau:

double d1 = 10.0 * .1;
bool equals = d1.AlmostEquals(0.0, 0.0000001);

Đối với mẫu đơn giản của bạn, thử nghiệm đó là được. Nhưng những gì về điều này:

bool b = ( 10.0 * .1 - 1.0 == 0.0 );

Hãy nhớ rằng .1 là một số thập phân lặp lại trong hệ nhị phân và không thể được biểu diễn chính xác. Sau đó so sánh với mã này:

double d1 = 10.0 * .1; // make sure the compiler hasn't optimized the .1 issue away
bool b = ( d1 - 1.0 == 0.0 );

Tôi sẽ để bạn chạy thử nghiệm để xem kết quả thực tế: nhiều khả năng bạn sẽ nhớ nó theo cách đó.

Từ mục nhập MSDN cho Double.Equals :

Độ chính xác trong so sánh

Phương pháp Equals nên được sử dụng một cách thận trọng, vì hai giá trị rõ ràng là tương đương có thể không bằng nhau do độ chính xác của hai giá trị khác nhau. Ví dụ sau báo cáo rằng giá trị Double .3333 và Double được trả về bằng cách chia 1 cho 3 là không bằng nhau.

...

Thay vì so sánh để bình đẳng, một kỹ thuật được đề xuất liên quan đến việc xác định biên độ chênh lệch có thể chấp nhận được giữa hai giá trị (chẳng hạn như 0,01% của một trong các giá trị). Nếu giá trị tuyệt đối của chênh lệch giữa hai giá trị nhỏ hơn hoặc bằng biên độ đó, thì sự khác biệt có thể là do sự khác biệt về độ chính xác và do đó, các giá trị có thể bằng nhau. Ví dụ sau sử dụng kỹ thuật này để so sánh .33333 và 1/3, hai giá trị Double mà ví dụ mã trước đó phát hiện là không bằng nhau.

Ngoài ra, hãy xem Double.Epsilon .

Vấn đề xảy ra khi bạn so sánh các kiểu triển khai giá trị dấu chấm động khác nhau, ví dụ như so sánh float với double. Nhưng với cùng một loại, nó không phải là một vấn đề.

float f = 0.1F;
bool b1 = (f == 0.1); //returns false
bool b2 = (f == 0.1F); //returns true

Vấn đề là, lập trình viên đôi khi quên rằng kiểu ép kiểu ngầm (double to float) đang diễn ra để so sánh và kết quả là nó dẫn đến lỗi.

Nếu số được gán trực tiếp cho float hoặc double thì có thể an toàn để kiểm tra đối chiếu với số 0 hoặc bất kỳ số nguyên nào có thể được biểu diễn bằng 53 bit đối với số kép hoặc 24 bit đối với số thực.

Hay nói một cách khác, bạn luôn có thể gán và giá trị số nguyên cho một đôi và sau đó so sánh đôi trở lại với cùng một số nguyên và được đảm bảo rằng nó sẽ bằng nhau.

Bạn cũng có thể bắt đầu bằng cách gán một số nguyên và các phép so sánh đơn giản vẫn tiếp tục hoạt động bằng cách gắn bó với việc cộng, trừ hoặc nhân với các số nguyên (giả sử kết quả nhỏ hơn 24 bit đối với số thực là 53 bit đối với số kép). Vì vậy, bạn có thể coi float và double là số nguyên trong các điều kiện được kiểm soát nhất định.

Không, nó không ổn. Cái gọi là giá trị không chuẩn hóa (dưới chuẩn), khi được so sánh bằng 0,0, sẽ được so sánh là sai (khác 0), nhưng khi được sử dụng trong một phương trình sẽ được chuẩn hóa (trở thành 0,0). Vì vậy, sử dụng điều này như một cơ chế để tránh chia cho 0 là không an toàn. Thay vào đó, hãy thêm 1,0 và so sánh với 1,0. Điều này sẽ đảm bảo rằng tất cả các subnormal được coi là 0.

Hãy thử điều này, và bạn sẽ thấy rằng == không đáng tin cậy cho double / float.
double d = 0.1 + 0.2; bool b = d == 0.3;

Đây là câu trả lời từ Quora.

Trên thực tế, tôi nghĩ tốt hơn là sử dụng các mã sau để so sánh giá trị kép với 0,0:

double x = 0.0;
return (Math.Abs(x) < double.Epsilon) ? true : false;

Tương tự cho float:

float x = 0.0f;
return (Math.Abs(x) < float.Epsilon) ? true : false;