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