2010-08-02 40 views

Trả lời

16

Giá trị khoa học có xu hướng là giá trị "tự nhiên" (chiều dài, khối lượng, thời gian, v.v.) ở nơi có mức độ thiếu tự nhiên bắt đầu - nhưng bạn có thể muốn số rất, rất lớn hoặc rất nhỏ. Đối với những giá trị này, double thường là một ý tưởng hay. Nó nhanh (với phần cứng hỗ trợ hầu như ở khắp mọi nơi), tăng lên và xuống đến các giá trị lớn/nhỏ, và thường hoạt động tốt nếu bạn không quan tâm đến giá trị chính xác decimal.

decimal là loại tốt cho số "nhân tạo" có giá trị chính xác, hầu như luôn được biểu diễn tự nhiên dưới dạng thập phân - ví dụ kinh điển cho loại tiền này. Tuy nhiên, nó đắt gấp đôi double về lưu trữ (8 byte cho mỗi giá trị thay vì 4), có phạm vi nhỏ hơn (do phạm vi số mũ giới hạn hơn) và chậm hơn đáng kể do thiếu hỗ trợ phần cứng.

Cá nhân tôi chỉ sử dụng float nếu lưu trữ là vấn đề - thật đáng kinh ngạc khi các điểm không chính xác có thể tích lũy khi bạn chỉ có khoảng 7 chữ số thập phân đáng kể.

Cuối cùng, như nhận xét từ "gấu sẽ ăn bạn" gợi ý, nó phụ thuộc vào những giá trị bạn đang nói - và tất nhiên bạn định làm gì với chúng. Nếu không có thêm thông tin, tôi nghi ngờ rằng double là điểm khởi đầu tốt - nhưng bạn thực sự nên đưa ra quyết định dựa trên tình huống cá nhân.

+1

Tôi thích sự khác biệt "tự nhiên" so với "nhân tạo". –

5

Double có vẻ là loại dữ liệu đáng tin cậy nhất cho các hoạt động như vậy. Ngay cả WPF sử dụng nó rộng rãi.

8

Vâng, tất nhiên thuật ngữ "tính toán khoa học" hơi mơ hồ, nhưng nói chung, đó là double.

float phần lớn là khả năng tương thích với các thư viện mong đợi các số dấu phẩy động 32 bit. Hiệu suất của các hoạt động floatdouble (như bổ sung) giống hệt nhau, vì vậy mã mới phải luôn sử dụng double vì nó có độ chính xác cao hơn.

Tuy nhiên, trình x86 JITter sẽ không bao giờ có chức năng nội dòng lấy hoặc trả lại float, vì vậy, sử dụng phương thức float trong thực tế có thể chậm hơn. Một lần nữa, đây là khả năng tương thích: nếu nó được inline, công cụ thực thi sẽ bỏ qua bước chuyển đổi làm giảm độ chính xác của nó, và do đó JITter có thể vô tình thay đổi kết quả của một số phép tính nếu nó được đặt trong các hàm như vậy.

Cuối cùng, cũng có decimal. Sử dụng điều này bất cứ khi nào điều quan trọng là phải có số chữ số thập phân nhất định. Trường hợp sử dụng khuôn mẫu là hoạt động tiền tệ, nhưng tất nhiên nó hỗ trợ hơn 2 chữ số thập phân - đó thực sự là một đoạn dữ liệu 80 bit.

Nếu thậm chí độ chính xác của 642 bit double là không đủ, hãy cân nhắc sử dụng thư viện bên ngoài để có số chính xác tùy ý, nhưng tất nhiên bạn sẽ chỉ cần điều đó nếu trường hợp sử dụng khoa học cụ thể của bạn gọi riêng.

+2

Điểm tốt về hiệu suất. –

+0

Nguồn trên xác nhận quyền sở hữu nội tuyến? Có một lỗi đã được sửa trong phiên bản 3.5 SP1 không cho phép JIT có các hàm nội tuyến lấy các tham số kiểu giá trị, nhưng tôi không thể nghĩ ra bất kỳ vấn đề nào khác. – JulianR

+0

Không thể tìm thấy nguồn nữa, nhưng tôi đã đề cập đến vấn đề. Ngăn xếp đánh giá CLR chỉ bao giờ sử dụng các giá trị 64 bit cho các số dấu phẩy động. Mỗi khi phao 32 bit được truyền vào một phương thức, hoặc một phương thức trả về một phao 32 bit, giá trị từ ngăn xếp đánh giá được chuyển đổi đặc biệt sang phao 32 bit để bảo toàn độ chính xác của nó. – Timwi

2

Hãy lưu ý rằng số thập phân đắt hơn rất nhiều để sử dụng so với số float/đôi (ngoài những gì Jon Skeet và Timwi đã viết).

0

Tôi khuyên bạn nên tăng gấp đôi trừ khi bạn cần giá trị chính xác; thập phân là để tính toán tài chính cần độ chính xác này.Tính toán khoa học chịu đựng các lỗi nhỏ bởi vì bạn không thể đo chính xác 1 mét anyways. Float chỉ giúp nếu lưu trữ là một vấn đề (ví dụ: ma trận rất lớn).

Các vấn đề liên quan