[swift-users] Provide native Decimal data type
Alex Blewitt
alblue at apple.com
Tue Sep 13 03:28:36 CDT 2016
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>
More information about the swift-users
mailing list