Is there a need for a Decimal type?


(Dale Buckley) #1

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?


(Charles Kissinger) #2

Both the NSDecimalNumber class and the NSDecimal struct are already available in Swift. If there were a set of operators and initializers for NSDecimal, would that provide most of what you need? The operators would be simple to implement over the existing functions, I think. Maybe the corelibs people would take those as a patch?

—CK

···

On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution <swift-evolution@swift.org> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Craig Cruden) #3

Big Yes!

Most business applications require the use of Decimal numbers. NSDecimalNumber is sludgy to use in Swift and generally does not interoperate well - and with limited functionality.

It should be a base type, and the same computational infix operators should be able to be used.

···

On 2016-02-13, at 18:51:39, Dale Buckley via swift-evolution <swift-evolution@swift.org> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Mark Glossop) #4

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?

Relevant (and because I remember it since Steve was replying to my message at the time):

  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005782.html

···

On 13 Feb 2016, at 19:51, Dale Buckley via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 7, 2016, at 12:40 PM, Mark Glossop via swift-evolution <swift-evolution@swift.org> wrote:

Sidebar on decimal numerics since they're relevant to support for currency units - would be nice to know if the "new" IEEE 754 (2008) Decimal floating-point types are in the Swift roadmap?
My suspicion is that any support for them will only come from upstream in LLVM as a first-class type [quad precision/binary128 is supported as the fp128 type; but no decimal floating-point types at present] - so looks like any fixed-point decimal support in the interim would need to be provided by hacking int types, but if anyone wants to chime in... :slight_smile:

Decimal FP is somewhere in the hazy far-future hypothetical roadmap. It’s actually far more useful than (software) Binary128; implemented in software the performance delta between the two is fairly narrow on modern CPU architectures (except possibly for division), and having a decimal FP type available would be quite nice.

There’s a lot of lower-hanging fruit to chip away on first, however.
– Steve

So - it's in the "far-future hypothetical roadmap". I've taken that to mean somewhere past Swift 4, whenever that drops.

In the meantime you might check out PONS which was mentioned a few days ago: https://github.com/dankogai/swift-pons - haven't tried it myself yet, but it appears to be an option for BigNums and Rational types ("decimal" types being a subset of Rational functionality.)

FWIW a number of other prior posts that mention dedicated decimal types:

  https://www.google.com.au/search?q=decimal+AND+type+site:https://lists.swift.org/pipermail/swift-evolution/

HTH,
M.
--
Mark Glossop
E: lists@cueballcentral.com
TW: http://twitter.com/Cueball_AU


(Joe Groff) #5

Decimal libraries would be great. However, there are a few different kinds of decimal that are interesting—currency tends to have different domain-specific behavior from general floating-point decimal, for instance. One thing I'd like to see us eventually fix at the language level is the low-level protocol for decimal literals. The current behavior of `FloatLiteralConvertible` is to pass the floating-point value down as a binary floating-point Double, making it unsuitable for use by decimal libraries. A more accurate protocol might break a decimal literal down into mantissa/exponent, something like this:

protocol DecimalLiteralConvertible {
  associatedtype Value: IntegerLiteralConvertible
  associatedtype Exponent: IntegerLiteralConvertible
  init(decimalLiteral: Value, timesTenToThePowerOf: Exponent)
}

Then e.g. '0.1' would compile down to 'T(decimalLiteral: 1, timesTenToThePowerOf: -1)' rather than 'T(floatLiteral: 0x1.999999999999ap-4)'. This would make it possible for libraries to extend the language with good decimal support.

-Joe

···

On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution <swift-evolution@swift.org> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?


(Jonathan Tang) #6

General +1, but I'm wondering if a better development process would be to
release this as an open-source library, get some adoption, respond to
user-feedback, and then propose to integrate that library into the stdlib.
You can iterate much faster in a library than in the language standard, and
APIs usually end up being a lot cleaner when designed in response to user
feedback than when designed by committee. (Particularly when the library
in question is fairly domain-specific.)

···

On Sat, Feb 13, 2016 at 4:03 AM, Craig Cruden via swift-evolution < swift-evolution@swift.org> wrote:

Big Yes!

Most business applications require the use of Decimal numbers.
NSDecimalNumber is sludgy to use in Swift and generally does not
interoperate well - and with limited functionality.

It should be a base type, and the same computational infix operators
should be able to be used.

> On 2016-02-13, at 18:51:39, Dale Buckley via swift-evolution < > swift-evolution@swift.org> wrote:
>
> We all know the problems with floating point types, they are well
documented and well understood by developers everywhere. We know when to
use them and (hopefully) when not to use them and if you are working with
financial values on a Foundation based platform you know to not use a
floating point type and to use NSDecimalNumber instead.
>
> My question is this; should there be an equivalent NSDecimalNumber type
built into Swift that can be used for precision sensitive decimal values
where floating point types can’t be used?
>
> Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a
modern twist so I can see it looking like something else entirely, but the
point still stands.
>
> I feel like there is a need for this, it’s not a new problem and has
been solved many times over in other languages such as Objective-C
(NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be
lacking an equivalent solution in Swift. It shouldn’t be left for an
external library to solve, it’s one of those things that need to be built
into the language.
>
> What are peoples thoughts on this?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dale Buckley) #7

Cc:swift-evolution@swift.org
Subject:[swift-evolution] Is there a need for a Decimal type?
Date:13 February 2016 at 20:45:46 GMT

Both the NSDecimalNumber class and the NSDecimal struct are already available in Swift. If there were a set of operators and initializers for NSDecimal, would that provide most of what you need? The operators would be simple to implement over the existing functions, I think. Maybe the corelibs people would take those as a patch?

—CK

>
> We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.
>
> My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?
>
> Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.
>
> I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.
>
> What are peoples thoughts on this?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I have been using what Foundation provides up until now. You are indeed correct that add the appropriate operators is a simple task to make it easier to use.

What my original discussion was aimed at was non Foundation based platforms where we don’t have this luxury.

···

> On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution<swift-evolution@swift.org>wrote:


(Dale Buckley) #8

That’s a very interesting link and it’s nice to know that some kind of Decimal type already been considered, I had no idea.

I can see why it’s been pushed back to a Swift 4 feature though, I would imagine the concentration is all about making the core of the language work as well as possible on Apple platforms first, and then thinking about the missing parts later. It’s just unfortunate that linux based systems have to rely on 3rd party solutions for now when it seems inevitable that the type will get added in at some point. But I guess Swift is still such a young language and it'll takes a while to catch up in some more "boring" areas.

···

Cc:Dale Buckley<dalebuckley86@gmail.com>
Subject:[swift-evolution] Is there a need for a Decimal type?
Date:13 February 2016 at 20:30:27 GMT

> On 13 Feb 2016, at 19:51, Dale Buckley via swift-evolution<swift-evolution@swift.org>wrote:
>
> We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.
>
> My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?
>
> Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.
>
> I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.
>
> What are peoples thoughts on this?
Relevant (and because I remember it since Steve was replying to my message at the time):

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005782.html

> > On Jan 7, 2016, at 12:40 PM, Mark Glossop via swift-evolution<swift-evolution@swift.org>wrote:
> >
> > Sidebar on decimal numerics since they're relevant to support for currency units - would be nice to know if the "new" IEEE 754 (2008) Decimal floating-point types are in the Swift roadmap?
> > My suspicion is that any support for them will only come from upstream in LLVM as a first-class type [quad precision/binary128 is supported as the fp128 type; but no decimal floating-point types at present] - so looks like any fixed-point decimal support in the interim would need to be provided by hacking int types, but if anyone wants to chime in... :slight_smile:
>
> Decimal FP is somewhere in the hazy far-future hypothetical roadmap. It’s actually far more useful than (software) Binary128; implemented in software the performance delta between the two is fairly narrow on modern CPU architectures (except possibly for division), and having a decimal FP type available would be quite nice.
>
> There’s a lot of lower-hanging fruit to chip away on first, however.
> – Steve
So - it's in the "far-future hypothetical roadmap". I've taken that to mean somewhere past Swift 4, whenever that drops.

In the meantime you might check out PONS which was mentioned a few days ago: https://github.com/dankogai/swift-pons - haven't tried it myself yet, but it appears to be an option for BigNums and Rational types ("decimal" types being a subset of Rational functionality.)

FWIW a number of other prior posts that mention dedicated decimal types:

https://www.google.com.au/search?q=decimal+AND+type+site:https://lists.swift.org/pipermail/swift-evolution/

HTH,
M.
--
Mark Glossop
E: lists@cueballcentral.com
TW: http://twitter.com/Cueball_AU


(Craig Cruden) #9

You mean this (I cannot find NSDecimal)

let y = NSDecimalNumber(string: "5")

y.decimalNumberByAdding(NSDecimalNumber(string: "10”))

Base values like this should not be mutable…..

And I could not find an NSDecimal implementation accessible from Swift (is there one)? (as such I cannot check that api).

The only real difference between a Decimal and an Int is that Int / Float instructions exist in hardware, whereas Decimal has to be simulated - but is just a real type when programming in high level language.

So you should have all the infix operations available, and the values themselves should not be mutable.

···

On 2016-02-14, at 3:45:46, Charles Kissinger via swift-evolution <swift-evolution@swift.org> wrote:

Both the NSDecimalNumber class and the NSDecimal struct are already available in Swift. If there were a set of operators and initializers for NSDecimal, would that provide most of what you need? The operators would be simple to implement over the existing functions, I think. Maybe the corelibs people would take those as a patch?

—CK

On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution <swift-evolution@swift.org> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #10

+1. That process is well-suited to *many* of the things people would
like to see in the standard library.

···

on Sat Feb 13 2016, Jonathan Tang <swift-evolution@swift.org> wrote:

General +1, but I'm wondering if a better development process would be to
release this as an open-source library, get some adoption, respond to
user-feedback, and then propose to integrate that library into the stdlib.
You can iterate much faster in a library than in the language standard, and
APIs usually end up being a lot cleaner when designed in response to user
feedback than when designed by committee. (Particularly when the library
in question is fairly domain-specific.)

--
-Dave


(Charles Kissinger) #11

You mean this (I cannot find NSDecimal)

Hmmm. NSDecimal is accessible to me in Xcode after importing Foundation. It’s included in the open source Foundation library as well. I’m not sure what is going on there.

I can understand why you would not want to use NSDecimalNumber.

—CK

···

On Feb 13, 2016, at 12:57 PM, Craig Cruden <ccruden@novafore.com> wrote:

let y = NSDecimalNumber(string: "5")

y.decimalNumberByAdding(NSDecimalNumber(string: "10”))

Base values like this should not be mutable…..

And I could not find an NSDecimal implementation accessible from Swift (is there one)? (as such I cannot check that api).

The only real difference between a Decimal and an Int is that Int / Float instructions exist in hardware, whereas Decimal has to be simulated - but is just a real type when programming in high level language.

So you should have all the infix operations available, and the values themselves should not be mutable.

On 2016-02-14, at 3:45:46, Charles Kissinger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Both the NSDecimalNumber class and the NSDecimal struct are already available in Swift. If there were a set of operators and initializers for NSDecimal, would that provide most of what you need? The operators would be simple to implement over the existing functions, I think. Maybe the corelibs people would take those as a patch?

—CK

On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charles Kissinger) #12

...

I have been using what Foundation provides up until now. You are indeed correct that add the appropriate operators is a simple task to make it easier to use.

What my original discussion was aimed at was non Foundation based platforms where we don’t have this luxury.

My understanding is that NSDecimal is not yet implemented in cross-platform Foundation, but it will be. (That’s my reading of their status page.) It should eventually be available everywhere that Swift is.

No objection here to having a Decimal type in the standard library though. I think that would be great.

—CK

···

On Feb 13, 2016, at 2:46 PM, Dale Buckley <dalebuckley86@gmail.com> wrote:


(Craig Cruden) #13

ok, found it…. woooooo…..

ugly. Sure this is not just suppose to be internal to NSDecimalNumber

Have not tried using it…. just let it fill in the defaults to see what it is. Does not look like it is actually meant to be used outside of something that makes it friendly.

NSDecimal(_exponent: <#T##Int32#>, _length: <#T##UInt32#>, _isNegative: <#T##UInt32#>, _isCompact: <#T##UInt32#>, _reserved: <#T##UInt32#>, _mantissa: <#T##(UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16, UInt16)#>)

···

On 2016-02-14, at 4:08:51, Charles Kissinger <crk@akkyra.com> wrote:

On Feb 13, 2016, at 12:57 PM, Craig Cruden <ccruden@novafore.com <mailto:ccruden@novafore.com>> wrote:

You mean this (I cannot find NSDecimal)

Hmmm. NSDecimal is accessible to me in Xcode after importing Foundation. It’s included in the open source Foundation library as well. I’m not sure what is going on there.

I can understand why you would not want to use NSDecimalNumber.

—CK

let y = NSDecimalNumber(string: "5")

y.decimalNumberByAdding(NSDecimalNumber(string: "10”))

Base values like this should not be mutable…..

And I could not find an NSDecimal implementation accessible from Swift (is there one)? (as such I cannot check that api).

The only real difference between a Decimal and an Int is that Int / Float instructions exist in hardware, whereas Decimal has to be simulated - but is just a real type when programming in high level language.

So you should have all the infix operations available, and the values themselves should not be mutable.

On 2016-02-14, at 3:45:46, Charles Kissinger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Both the NSDecimalNumber class and the NSDecimal struct are already available in Swift. If there were a set of operators and initializers for NSDecimal, would that provide most of what you need? The operators would be simple to implement over the existing functions, I think. Maybe the corelibs people would take those as a patch?

—CK

On Feb 13, 2016, at 3:51 AM, Dale Buckley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

We all know the problems with floating point types, they are well documented and well understood by developers everywhere. We know when to use them and (hopefully) when not to use them and if you are working with financial values on a Foundation based platform you know to not use a floating point type and to use NSDecimalNumber instead.

My question is this; should there be an equivalent NSDecimalNumber type built into Swift that can be used for precision sensitive decimal values where floating point types can’t be used?

Maybe the answer isn’t an ‘equivalent’ as such, it would probably have a modern twist so I can see it looking like something else entirely, but the point still stands.

I feel like there is a need for this, it’s not a new problem and has been solved many times over in other languages such as Objective-C (NSDecimalNumber) and Java (BigDecimal) etc. Yet as it stands we seem to be lacking an equivalent solution in Swift. It shouldn’t be left for an external library to solve, it’s one of those things that need to be built into the language.

What are peoples thoughts on this?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rainer Brockerhoff) #14

Excellent comment, a Decimal type would be good to have at some point
down the road, if it's presented in the suggested way.

For whoever will try do write such a library, a few comments.

In a former life I had to write some financial packages (some of them in
Assembler, others in C) and there were no suitable libraries — this
because we had to consider hyperinflation — the local currency could at
times need over 15 significant digits just for values seen in the
average payroll.

The usual trick was to store values as big integers with implicit
decimal point 2 (or sometimes, 6) places to the left.

NSDecimal and NSDecimalNumber seem to use decimal floating point; that
gets around exact representation of 0.1 and similar values, but it could
suffer loss of significance just like binary floats would, so it might
not be a good idea to port them.

···

On 2/15/16 13:58, Dave Abrahams via swift-evolution wrote:

on Sat Feb 13 2016, Jonathan Tang <swift-evolution@swift.org> wrote:

General +1, but I'm wondering if a better development process would be to
release this as an open-source library, get some adoption, respond to
user-feedback, and then propose to integrate that library into the stdlib.
You can iterate much faster in a library than in the language standard, and
APIs usually end up being a lot cleaner when designed in response to user
feedback than when designed by committee. (Particularly when the library
in question is fairly domain-specific.)

+1. That process is well-suited to *many* of the things people would
like to see in the standard library.

--
Rainer Brockerhoff <rainer@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/