Tại sao việc thay đổi thứ tự tổng trả về một kết quả khác nhau?

Tại sao việc thay đổi thứ tự tổng trả về một kết quả khác nhau?

23.53 + 5.88 + 17.64 = = 47.05

23.53 + 17.64 + 5.88 = = 47.050000000000004

Cả Java và JavaScript trả về cùng một kết quả.

Tôi hiểu rằng, do cách các số dấu phẩy động được biểu diễn dưới dạng nhị phân, một số số hữu tỷ ( như 1/3 - 0.333333 ... ) không thể được biểu diễn chính xác.

Tại sao chỉ đơn giản là thay đổi thứ tự của các yếu tố ảnh hưởng đến kết quả?

Có thể câu hỏi này là ngu ngốc, nhưng tại sao chỉ đơn giản là thay đổi thứ tự của các yếu tố ảnh hưởng đến kết quả?

Nó sẽ thay đổi các điểm tại đó các giá trị được làm tròn, dựa trên cường độ của chúng. Ví dụ về loại điều chúng ta đang thấy, hãy giả vờ rằng thay vì dấu phẩy động nhị phân, chúng ta đã sử dụng loại dấu phẩy động thập phân có 4 chữ số có nghĩa, trong đó mỗi phép cộng được thực hiện với độ chính xác "vô hạn" và sau đó làm tròn thành số đại diện gần nhất. Đây là hai khoản tiền:

1/3 + 2/3 + 2/3 = (0.3333 + 0.6667) + 0.6667
                = 1.000 + 0.6667 (no rounding needed!)
                = 1.667 (where 1.6667 is rounded to 1.667)

2/3 + 2/3 + 1/3 = (0.6667 + 0.6667) + 0.3333
                = 1.333 + 0.3333 (where 1.3334 is rounded to 1.333)
                = 1.666 (where 1.6663 is rounded to 1.666)

Chúng tôi thậm chí không cần số nguyên cho vấn đề này:

10000 + 1 - 10000 = (10000 + 1) - 10000
                  = 10000 - 10000 (where 10001 is rounded to 10000)
                  = 0

10000 - 10000 + 1 = (10000 - 10000) + 1
                  = 0 + 1
                  = 1

Điều này chứng tỏ có thể rõ ràng hơn rằng phần quan trọng là chúng ta có một số lượng hạn chế các chữ số có nghĩa - không phải là một số thập phân giới hạn . Nếu chúng ta luôn có thể giữ cùng một số vị trí thập phân, thì với phép cộng và trừ ít nhất, chúng ta sẽ ổn (miễn là các giá trị không bị tràn). Vấn đề là khi bạn nhận được số lớn hơn, thông tin nhỏ hơn sẽ bị mất - 10001 được làm tròn thành 10000 trong trường hợp này. (Đây là một ví dụ về vấn đề mà Eric Lippert lưu ý trong câu trả lời của anh ấy .)

Điều quan trọng cần lưu ý là các giá trị ở dòng đầu tiên của phía bên phải giống nhau trong mọi trường hợp - vì vậy mặc dù điều quan trọng là phải hiểu rằng các số thập phân của bạn (23,53, 5,88, 17,64) sẽ không được biểu thị chính xác như doublecác giá trị, đó là chỉ có một vấn đề vì những vấn đề được hiển thị ở trên.

Đây là những gì đang diễn ra trong nhị phân. Như chúng ta biết, một số giá trị dấu phẩy động không thể được biểu diễn chính xác dưới dạng nhị phân, ngay cả khi chúng có thể được biểu diễn chính xác bằng số thập phân. 3 con số này chỉ là ví dụ về thực tế đó.

Với chương trình này, tôi đưa ra các biểu diễn thập lục phân của mỗi số và kết quả của mỗi phép cộng.

public class Main{
   public static void main(String args[]) {
      double x = 23.53;   // Inexact representation
      double y = 5.88;    // Inexact representation
      double z = 17.64;   // Inexact representation
      double s = 47.05;   // What math tells us the sum should be; still inexact

      printValueAndInHex(x);
      printValueAndInHex(y);
      printValueAndInHex(z);
      printValueAndInHex(s);

      System.out.println("--------");

      double t1 = x + y;
      printValueAndInHex(t1);
      t1 = t1 + z;
      printValueAndInHex(t1);

      System.out.println("--------");

      double t2 = x + z;
      printValueAndInHex(t2);
      t2 = t2 + y;
      printValueAndInHex(t2);
   }

   private static void printValueAndInHex(double d)
   {
      System.out.println(Long.toHexString(Double.doubleToLongBits(d)) + ": " + d);
   }
}

Các printValueAndInHexphương pháp chỉ là một helper hex-in.

Đầu ra như sau:

403787ae147ae148: 23.53
4017851eb851eb85: 5.88
4031a3d70a3d70a4: 17.64
4047866666666666: 47.05
--------
403d68f5c28f5c29: 29.41
4047866666666666: 47.05
--------
404495c28f5c28f6: 41.17
4047866666666667: 47.050000000000004

4 số đầu tiên là x, y, z, và s's đại diện thập lục phân. Trong biểu diễn dấu phẩy động của IEEE, các bit 2-12 biểu thị số mũ nhị phân , nghĩa là tỷ lệ của số. (Các bit đầu tiên là bit dấu, và các bit còn lại cho mantissa .) Số mũ đại diện thực sự là số nhị phân trừ đi 1023.

Số mũ của 4 số đầu tiên được trích xuất:

    sign|exponent
403 => 0|100 0000 0011| => 1027 - 1023 = 4
401 => 0|100 0000 0001| => 1025 - 1023 = 2
403 => 0|100 0000 0011| => 1027 - 1023 = 4
404 => 0|100 0000 0100| => 1028 - 1023 = 5

Bộ bổ sung đầu tiên

Số thứ hai ( y) có độ lớn nhỏ hơn. Khi thêm hai số này để có được x + y, 2 bit cuối của số thứ hai ( 01) được dịch chuyển ra khỏi phạm vi và không tính vào phép tính.

Bổ sung thứ hai thêm x + yvà zthêm hai số có cùng tỷ lệ.

Bộ bổ sung thứ hai

Ở đây, x + zxảy ra đầu tiên. Chúng có cùng tỷ lệ, nhưng chúng mang lại một con số cao hơn về tỷ lệ:

404 => 0|100 0000 0100| => 1028 - 1023 = 5

Bổ sung thứ hai thêm x + zvà y, và bây giờ 3 bit được loại bỏ yđể thêm các số ( 101). Ở đây, phải có một vòng lên trên, vì kết quả là số dấu phẩy động tiếp theo tăng lên: 4047866666666666cho tập hợp bổ sung đầu tiên so với4047866666666667 tập hợp bổ sung thứ hai. Lỗi đó là đủ đáng kể để hiển thị trong bản in của tổng số.

Tóm lại, hãy cẩn thận khi thực hiện các phép toán trên các số của IEEE. Một số đại diện là không chính xác, và chúng thậm chí còn trở nên không chính xác hơn khi quy mô khác nhau. Thêm và trừ các số có tỷ lệ tương tự nếu bạn có thể.

Câu trả lời của Jon tất nhiên là đúng. Trong trường hợp của bạn, lỗi không lớn hơn lỗi bạn sẽ tích lũy khi thực hiện bất kỳ thao tác dấu phẩy động đơn giản nào. Bạn đã có một kịch bản trong đó trong một trường hợp bạn không có lỗi và trong trường hợp khác bạn gặp một lỗi nhỏ; Đó thực sự không phải là một kịch bản thú vị. Một câu hỏi hay là: có kịch bản nào trong đó việc thay đổi thứ tự tính toán chuyển từ một lỗi nhỏ thành một lỗi rất lớn (tương đối) không? Câu trả lời rõ ràng là có.

Xem xét ví dụ:

x1 = (a - b) + (c - d) + (e - f) + (g - h);

đấu với

x2 = (a + c + e + g) - (b + d + f + h);

đấu với

x3 = a - b + c - d + e - f + g - h;

Rõ ràng trong số học chính xác, chúng sẽ giống nhau. Thật thú vị khi cố gắng tìm các giá trị cho a, b, c, d, e, f, g, h sao cho các giá trị của x1 và x2 và x3 khác nhau bởi một số lượng lớn. Xem nếu bạn có thể làm như vậy!

Điều này thực sự bao gồm nhiều thứ hơn là chỉ Java và Javascript và có thể sẽ ảnh hưởng đến bất kỳ ngôn ngữ lập trình nào bằng cách sử dụng số float hoặc double.

Trong bộ nhớ, các điểm nổi sử dụng một định dạng đặc biệt dọc theo các dòng của IEEE 754 (bộ chuyển đổi cung cấp giải thích tốt hơn nhiều so với tôi có thể).

Dù sao, đây là bộ chuyển đổi float.

http://www.h-schmidt.net/FloatConverter/

Điều về thứ tự của các hoạt động là "độ mịn" của hoạt động.

Dòng đầu tiên của bạn mang lại 29,41 từ hai giá trị đầu tiên, cung cấp cho chúng tôi 2 ^ 4 dưới dạng số mũ.

Dòng thứ hai của bạn mang lại 41,17, cung cấp cho chúng tôi 2 ^ 5 là số mũ.

Chúng ta đang mất một con số đáng kể bằng cách tăng số mũ, có khả năng thay đổi kết quả.

Hãy thử đánh dấu vào bit cuối cùng ở phía bên phải và tắt cho 41,17 và bạn có thể thấy rằng một cái gì đó "không đáng kể" là 1/2 ^ 23 của số mũ sẽ đủ để gây ra sự khác biệt điểm nổi này.

Chỉnh sửa: Đối với những người nhớ các số liệu quan trọng, điều này sẽ thuộc danh mục đó. 10 ^ 4 + 4999 với con số đáng kể là 1 sẽ là 10 ^ 4. Trong trường hợp này, con số đáng kể nhỏ hơn nhiều, nhưng chúng ta có thể thấy kết quả với .00000000004 được đính kèm.

Các số dấu phẩy động được biểu diễn bằng định dạng IEEE 754, cung cấp một kích thước bit cụ thể cho lớp phủ (ý nghĩa). Thật không may, điều này cung cấp cho bạn một số 'khối xây dựng phân đoạn' cụ thể để chơi và các giá trị phân số nhất định không thể được trình bày chính xác.

Điều đang xảy ra trong trường hợp của bạn là trong trường hợp thứ hai, phần bổ sung có thể gặp phải một số vấn đề chính xác vì thứ tự các phần bổ sung được ước tính. Tôi đã không tính toán các giá trị, nhưng có thể ví dụ rằng 23,53 + 17,64 không thể được biểu diễn chính xác, trong khi 23,53 + 5,88 thì có thể.

Thật không may, nó là một vấn đề được biết đến mà bạn phải giải quyết.

Tôi tin rằng nó phải làm theo thứ tự của sự trốn tránh. Mặc dù tổng là tự nhiên giống nhau trong một thế giới toán học, trong thế giới nhị phân thay vì A + B + C = D, nó là

A + B = E
E + C = D(1)

Vì vậy, có bước thứ cấp mà số dấu phẩy động có thể tắt.

Khi bạn thay đổi thứ tự,

A + C = F
F + B = D(2)