[swift-users] Provide native Decimal data type

[Alex Blewitt]

Regarding Decimal - it's not yet implemented on Linux, but it's a work in progress.

Alex

> On 12 Sep 2016, at 18:49, Stephen Canon via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On Sep 12, 2016, at 1:26 PM, Jens Alfke via swift-users <swift-users at swift.org <mailto: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
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160913/16cf2ac0/attachment.html>