Sử dụng kiểu dữ liệu số phải

Question

Sau khi tham gia nhiều hơn vào đào tạo kỹ sư mới cũng như đọc Jon Skeet's DevDays presentation Tôi đã bắt đầu nhận ra nhiều kỹ sư không rõ ràng khi nào nên sử dụng kiểu dữ liệu số nào khi. Tôi đánh giá cao vai trò của một bằng khoa học máy tính chính thức trong việc giúp đỡ điều này, nhưng tôi thấy rất nhiều kỹ sư mới cho thấy sự không chắc chắn vì họ chưa bao giờ làm việc với các tập dữ liệu lớn hoặc phần mềm tài chính hoặc các vấn đề về lập trình hoặc thống kê hoặc các vấn đề về kho dữ liệu phức tạp .

Trải nghiệm của tôi là mọi người thực sự băn khoăn khi chúng được giải thích trong ngữ cảnh. Tôi đang tìm kiếm các ví dụ tốt về các vấn đề lập trình thực, trong đó dữ liệu nhất định được biểu diễn tốt nhất bằng cách sử dụng kiểu dữ liệu. Cố gắng tránh xa các ví dụ sách giáo khoa nếu có thể. Tôi gắn thẻ này với Java, nhưng cảm thấy tự do để đưa ra các ví dụ trong các ngôn ngữ khác và gắn lại thẻ:

Integer, Long, Double, Float, BigInteger, vv ...

Answer 1

Tôi thực sự không nghĩ bạn cần ví dụ hoặc bất kỳ điều gì phức tạp. Điều này rất đơn giản:

• Đây có phải là số nguyên không?
  • Có thể là> 2^63 không? BigInteger
  • Có thể là> 2^31 không? dài
  • Nếu không int
• Đây có phải là số thập phân không?
  • Giá trị xấp xỉ có được không?
    • đôi
  • Liệu nó cần phải được chính xác? (Ví dụ: một lượng tiền tệ!)
    • BigDecimal

(Khi tôi nói ">", ý tôi là "lớn về giá trị tuyệt đối", tất nhiên.) Tôi đã không bao giờ sử dụng một byte hoặc char để đại diện cho một số, và tôi đã không bao giờ được sử dụng một khoảng thời gian ngắn. Đó là trong 12 năm lập trình Java. Phao? Meh. Nếu bạn có một mảng lớn và bạn đang gặp vấn đề về bộ nhớ, tôi đoán vậy.

Lưu ý rằng BigDecimal có phần sai tên; các giá trị của bạn làm không phải là phải lớn để cần.

Answer 2

BigDecimal là tốt nhất khi nói đến việc duy trì tính toán dấu chấm động chính xác và có thể chỉ định độ chính xác mong muốn. Tôi tin rằng nổi (và ở mức độ nào đó tăng gấp đôi) cung cấp lợi ích hiệu suất trên BigDecimal, nhưng với chi phí chính xác và khả năng sử dụng.

Answer 3

thường số nếu chúng ta đang nói máy independenat (32/64bit) kích thước kiểu dữ liệu là như dưới đây,

số nguyên: 4 byte dài

: 8 byte

thập phân/float: 4bytes

kép: 8bytes

và kích thước giảm xuống còn một nửa cho các giá trị ký (ví dụ: cho 4bytes, unsigned = 4billions ký = 2billions)

bigInt (phụ thuộc vào việc triển khai ngôn ngữ) đôi khi tối đa 10byte.

để lưu trữ dữ liệu số lượng lớn (chẳng hạn như công cụ tìm kiếm) tôi rất muốn giới thiệu byte và ngắn để tiết kiệm không gian.

byte: 1 byte, (0-256 unsigned, -128 - 128 đã ký)

ngắn: 2 byte (65k unsigned)

---

giả sử bạn muốn lưu kỷ lục về TUỔI, kể từ khi không ai sống trên 150, vì vậy bạn đã sử dụng kiểu dữ liệu BYTE (đọc ở trên cho kích thước) nhưng nếu bạn sử dụng INTEGER bạn đã lãng phí thêm 3byte và nghiêm túc nói với tôi wth sống hơn 4 tỷ năm.

Answer 4

Một điểm quan trọng bạn có thể muốn nêu rõ là hầu như luôn luôn là lỗi để so sánh các số dấu phẩy động cho sự bình đẳng. Ví dụ: mã sau rất có khả năng không thành công:

double euros = convertToEuros(item.getCostInDollars()); 
if (euros == 10.0) { 
    // this line will most likely never be reached 
} 

Đây là một trong nhiều lý do tại sao bạn muốn sử dụng số rời rạc để biểu thị đơn vị tiền tệ.

Khi bạn hoàn toàn phải so sánh các số dấu phẩy động, bạn chỉ có thể làm như vậy; một cái gì đó trong phạm vi:

double euros = convertToEuros(item.getCostInDollars()); 
if (Math.abs(euros - 10.0) < EPSILON) { 
    // this might work 
} 

Đối với ví dụ thực tế, quy tắc thông thường của tôi nhỏ là một cái gì đó như thế này:

• kép: suy nghĩ lâu dài và khó khăn trước khi sử dụng nó; đau có đáng không?
• float: không sử dụng nó
• byte: thường được sử dụng như byte [] để đại diện cho một số dữ liệu nhị phân thô
• int: đây là người bạn thân nhất của bạn; sử dụng nó để đại diện cho hầu hết các công cụ
• dài: sử dụng thẻ này cho dấu thời gian và ID cơ sở dữ liệu
• BigDecimal and BigInteger: nếu bạn biết về điều này, rất có thể bạn biết mình đang làm gì, vì vậy bạn không cần lời khuyên của tôi

Tôi nhận ra rằng đây không phải là quy tắc khoa học khủng khiếp, nhưng nếu đối tượng mục tiêu của bạn không phải là nhà khoa học máy tính, thì tốt nhất là nên tuân theo những điều cơ bản.

Answer 5

VInt trong Lucene là ma quỷ. Lợi ích nhỏ về kích thước là lớn hơn rất nhiều bởi hiệu suất phạt trong việc đọc chúng từng byte một.

Điều tốt để nói đến là không gian so với thời gian giao dịch tắt. Tiết kiệm 200MB là tuyệt vời trong năm 1996, nhưng trong năm 2010, thrashing IO bộ đệm đọc một byte tại một thời điểm là khủng khiếp.