{"id":34893,"date":"2022-02-02T16:16:49","date_gmt":"2022-02-02T21:16:49","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34893"},"modified":"2024-05-20T11:26:55","modified_gmt":"2024-05-20T15:26:55","slug":"decimal-vs-double","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/02\/02\/decimal-vs-double\/","title":{"rendered":"Decimal vs. Double"},"content":{"rendered":"

Jesse Squires<\/a>:<\/p>\n

More importantly, Decimal<\/code> does not<\/strong> conform to either BinaryFloatingPoint<\/code><\/a> or FloatingPoint<\/code><\/a>, but begins its protocol conformance at SignedNumeric<\/code><\/a>, which has the single requirement<\/a> to implement func negate()<\/code>. This reveals why Decimal<\/code> cannot be a drop-in replacement for any of Swift’s floating-point types — most functionality is defined in the lower floating-point protocols. Similar to how mixing numeric types like Int<\/code> and Double<\/code> in a single expression is a compiler error in Swift, Decimal<\/code> does not play nicely with the other numerics. Additionally, some common functionality is missing. For example, Decimal<\/code> does not conform to Strideable<\/code> like the other numerics, which means you cannot create ranges of Decimal<\/code> values. Depending on your problem domain, Decimal<\/code> can be difficult to adopt.<\/p><\/blockquote>\n\n

Rob Napier<\/a>:<\/p>\n

I don’t generally recommend Decimal<\/code> for money. I recommend Int<\/code>, and store everything in the base unit, most commonly “cents.” It’s more efficient and often easier to use.<\/p><\/blockquote>\n\n

Rob Ryan<\/a>:<\/p>\n

\n

Two benefits of Decimal<\/code>: (1) You can do precise decimal calculations … e.g. add Double<\/code> of 0.1 ten times ≠ 1.0 (!); (2) You want to enjoy more significant digits … e.g. print Double<\/code> representation of 12345678901234567890 and it’s not actually 12345678901234567890.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n