# [swift-evolution] Pre-proposal: Safer Decimal Calculations

Rainer Brockerhoff rainer at brockerhoff.net
Thu Mar 24 09:42:43 CDT 2016

```(replying on gmane as I see my previous reply lost threading. @#\$%^
Thunderbird.)

On 3/24/16 11:31, Stephen Canon via swift-evolution wrote:
>> On Mar 24, 2016, at 10:01 AM, Rainer Brockerhoff <rainer at brockerhoff.net> wrote:
>>
>> There's the mismatch between decimal representation of binary formats,
>> causing confusion for very common cases like 0.01. There's your work in
>> upgrading the FloatingPoint protocol. There's the question of
>> modernizing NSDecimalNumber or writing a new decimal type. The
>> scientific community needs IEEE 754, the mathematical community needs
>> exact-precision bignums, the financial community needs predictable but
>> small decimal precision, the educators need simple decimal numbers for
>> teaching and graphing.
>>
>> IMHO the existing Double, Float and CGFloat types don't cover all those
>> use cases.
>>
>> Maybe we need a DecimalLiteralConvertible not as generic as
>> FloatLiteralConvertible, so that we can have a built-in type - call it
>> Decimal or SimpleDecimal - that would be inferred in a statement like
>> `let x = 0.01`
>> such that, thereafter, calculations with x are sufficient for 99% of
>> real-world graphing and financial calculations, with exact comparisons
>> and so forth, but with none of the IEEE 754 complications. (Of course if
>> you need trigonometry and square root etc. just convert to Double.)
>
> I believe that providing the IEEE 754 “Decimal128” type (plus support
> for decimal literals) would satisfy 99% of the requirements listed
> here (while also conforming to FloatingPoint).  It provides 34
> significant digits (sufficient to represent the US nation debt in
> Zimbabwean dollars).

I now read up on Decimal128 and it looks excellent.

(Anecdote re: Zimbabwean dollars; during the hyperinflation period here
in Brazil we were unable to use any “foreign” home accounting apps, as
they, of course, didn't support millions and billions of currency

Can I conclude that you intend to introduce this type into Swift, then?
And would it be the default type for decimal literals, as I suggested?

If so, no need for me to update my (pre-)proposal at all.

> Arbitrary-precision integer arithmetic is likely better served by a dedicated big integer type.  Does that seem reasonable?

Indeed, I just mentioned that as a possible side-effect, but I don't
need it myself.

--
Rainer Brockerhoff  <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

```