[swift-users] Provide native Decimal data type

[Stephen Canon]

> On Sep 12, 2016, at 1:26 PM, Jens Alfke via swift-users <swift-users at swift.org> wrote:
> 
>> On Sep 12, 2016, at 10:10 AM, Teej . via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>> 
>> 	…in spite of the CPU’s quirks in handling floating point numbers in a maddening inaccurate manner.
> 
> Well, in the CPU’s defense, it’s only inaccurate because the puny humans insist on dividing their currency into fractions of 1/10, which has no exact representation in binary. (Apparently this is an ancient tradition commemorating the number of bony outgrowths on certain extremities of their grotesque meat-bodies.) I could — I mean, the computers could — point out that if we divided our currency units into 7 pieces, our precious decimal numbers would quickly become inaccurate too. :)

Expanding a bit on what Jens wrote here: decimal (unlike friendship) is not magic.  All computer models of real-number arithmetic are necessarily inexact, because (almost all) real numbers are not computable.  There are a bunch of reasonable choices that one can make, however (this is not an exhaustive list, just a sampling of the design space):

Binary floating point
Pro: represents modest integers exactly, extremely fast hardware implementations, fixed memory size, and rounding errors are extremely uniform—they don’t vary much with the number being represented.
Con: almost no decimal fractions have exact representations.

Decimal floating point
Pro: represents modest integers and decimal fractions exactly, slower than binary but still faster than almost anything else, fixed memory size.
Con: at least an order of magnitude slower than binary floating-point, and rounding error is significantly less scale-invariant.

Fixed-size rationals
Pro: represents all modestly-sized integers and fractions exactly, fixed memory size, four basic operations are exact until you hit the limits of representation.
Con: denominators quickly grow too quickly to be used for non-trivial computations (this is usually a deal-breaker).

Arbitrary-precision rationals
Pro: closed under four basic operations, represents most numbers most people will use exactly.
Con: representations get extremely large extremely quickly, large memory footprint if you have more than a few numbers.

Computable real numbers
Pro: any number you can describe, you can work with.
Con: your numbers are now computer programs, and you arithmetic system is Turing-complete.  Testing for equality is equivalent to solving the halting problem.

> Teej . via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
> 

> It still does not answer my question on why we can’t just provide a decimal data type.

The only problem here is the “just”.  We can and will provide a decimal data type.  Like many other language changes, that we can and will do, it requires engineering time, and there are finite engineering resources available to work on it.

Keep in mind that decimal will not magically solve all accuracy problems, however.  1/3 is just as inaccurate in decimal as it is in binary floating-point (actually, it’s less accurate in decimal than in a comparable binary format due to the aforementioned non-uniformity of decimal rounding error).

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160912/92d110b6/attachment.html>