> On Sep 12, 2016, at 1:26 PM, Jens Alfke via swift-users
> <swift-users@swift.org> wrote:
>
>> On Sep 12, 2016, at 10:10 AM, Teej . via swift-users <swift-users@swift.org
>> <mailto:swift-users@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@swift.org <mailto:swift-users@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
