Tại sao độ chính xác mô đun điểm nổi quan trọng?

Hầu hết các phương ngữ Smalltalk hiện đang thực hiện một mô đun nổi không chính xác ngây thơ (fmod / phần còn lại).
Tôi chỉ thay đổi điều này để cải thiện Squeak / Pharo và cuối cùng là tuân thủ các tiêu chuẩn khác của Smalltalk (IEEE 754, ISO / IEC 10967), như tôi đã làm cho các hoạt động điểm nổi hiện đại khác.

Tuy nhiên, để áp dụng những thay đổi đó, tôi dự đoán rằng việc tuân thủ tiêu chuẩn sẽ không đủ sức thuyết phục các đồng nghiệp của tôi, vì vậy giải thích trong trường hợp nào thì sự chính xác này sẽ thực sự giúp tôi rất nhiều. Tôi không thể tìm thấy một ví dụ tốt cho đến nay.

Có ai ở đây biết tại sao / khi / ở đâu (IOW trong thuật toán nào) độ chính xác của mô đun như vậy sẽ quan trọng không?

arithmetic floating-point

— aka
nguồn

Tôi nghĩ rằng bạn có thể nhận được câu trả lời tốt hơn về Khoa học tính toán vì các vấn đề như vậy quan trọng hơn trong miền (phụ) của họ. Trong mọi trường hợp, câu hỏi là ontopic ở đây và bạn nên cung cấp cho người trả lời của chúng tôi một vài ngày trước khi đăng lại.

— Raphael

Tôi đã thấy mã dựa vào độ chính xác của fmod / modf khiến tôi rùng mình, nhưng khả năng một ngôn ngữ có thể dám thực hiện một mô đun điểm trôi nổi không chính xác có vẻ còn đáng sợ hơn. Mã ví dụ: (1) Lấy phần còn lại. (2) Dừng lại nếu nó bằng không. (3) Nhân nó với 2 và đi đến (1). Người ta có thể thực hiện một số công việc hữu ích trong quá trình này, nhưng điểm quan trọng là việc chấm dứt quá trình này phụ thuộc vào độ chính xác của phần còn lại và độ chính xác của phép nhân với 2. Không chắc tôi có nên đưa ra câu trả lời đầy đủ hơn ở đây không, vì Khoa học tính toán có vẻ phù hợp hơn cho câu hỏi này

— Thomas Klimpel

Một phỏng đoán: bình thường hóa đầu vào của hàm lượng giác.

— Paul A. Clayton

@ThomasKlimpel Tôi quan tâm nếu bạn tìm thấy tài liệu tham khảo. Lưu ý rằng phần còn lại ngây thơ được định nghĩa là (x - ((y / x) bị cắt bớt * x)) với vòng IEEE đến ops gần nhất, chúng ta có thể chứng minh rằng chính xácRem (x, y) == 0 => naiveRem (x, y) == 0. Vấn đề là ngược lại - phân chia chính xác sai tích cực - như naiveRem (4.0,0.1) == 0.0 không may phù hợp với những kỳ vọng ngây thơ trong nhiều trường hợp!

— aka.

@ PaulA.Clayton có, đối với sin theo độ có thể ... Mặc dù, tôi đoán là rem ngây thơ hoạt động tốt như nhau chính xác đến khoảng. 1e16 độ vì 360 chỉ có phạm vi 6 bit được đặt và vì phép chia 360 dường như không bao giờ làm tròn cho các tiền thân của 360 ... thực sự giúp đỡ trong trường hợp như vậy?

— aka.

Lưu ý rằng việc thực hiện điểm nổi không chính xác ảnh hưởng đến thời tiết.

Đã có những thử nghiệm chạy dự đoán thời tiết với cùng một đầu vào trên phần cứng khác nhau và dự đoán được chuyển hướng. Nếu bạn đang chạy thuật toán lặp thì một sự khác biệt làm tròn nhỏ ở đây hoặc có thể dẫn đến hiệu ứng cánh bướm thay đổi ánh nắng mặt trời thành mưa.

Các quy tắc làm tròn trong các tiêu chuẩn (IEEE 754, ISO / IEC 10967) đã được suy nghĩ cẩn thận để các thuật toán số hoạt động có thể dự đoán được với độ chính xác cao nhất và tái tạo kết quả tương tự mỗi lần. Bằng cách không tuân theo các thuật toán số chuẩn được thiết kế cho các quy tắc làm tròn đó sẽ phá vỡ và các thuật toán lặp như dự đoán thời tiết thậm chí có thể cho kết quả ngẫu nhiên.

(và không nói điều gì về dự đoán thời tiết? :)

— Goswin von Brederlow
nguồn

Mặt khác, nếu hiệu ứng cánh bướm thay đổi nắng thành mưa, thì dù sao kết quả của bạn cũng không hữu ích.

— gnasher729

Ngày xửa ngày xưa, tôi đã lưu dữ liệu float trong ASCII với không đủ chữ số. Một khách hàng muốn chỉ cho tôi một vấn đề, nhưng sau khi khôi phục dữ liệu từ tệp ASCII, vấn đề đã biến mất. Tôi đã nói rằng một vài ulp off không thành vấn đề, nếu vấn đề của anh ta bị điều hòa, dù sao tôi cũng không thể làm gì được. Anh ấy nói rằng đó là việc của anh ấy, của tôi là cung cấp phần mềm cho phép tái tạo các vấn đề của anh ấy. Anh ấy đã đúng.

— aka.

Đó là lý do tại sao bạn nên xuất số dấu phẩy động để lưu dưới dạng hexadecimals bằng% a.

— Goswin von Brederlow