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

[Rainer Brockerhoff]

(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
properly. Many had no adjustable column widths, even.)

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/