search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.33k stars 17.7k forks source link

proposal: math: fixed decimal types #68272

Open sblackstone opened 5 months ago

sblackstone commented 5 months ago

Proposal Details

I propose reconsidering the inclusion of fixed decimal types as a standard language feature.

This has been extensively discussed in these two issues:

Motivation

Currently, fixed decimal types are supported by several third-party packages, including the popular shopspring/decimal. However, a recent PR suggests that the long-term maintenance of this library is uncertain. This situation forces the community to constantly adapt to the latest maintained fork, which is a long-term burden on the ecosystem.

Decimal libraries are also crucial in various core areas, such as database drivers, validation, and testing libraries. Standardization of a fixed decimal type would ensure that:

For these reasons I think it is a worth another look at one of the above proposals or a suitable alternative that supports standards and furthers interoperability.

gabyhelp commented 5 months ago

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

ianlancetaylor commented 5 months ago

We want to avoid the trap of continually revisiting old decisions. That can easily consume all of our time and make it difficult to move forward. Is there significant new information on this topic that would lead us to make a different decision this time?

sblackstone commented 5 months ago

The impetus for opening this was noticing that a package my employer depends on heavily at the moment (shopspring/decimal) seems to be semi-abandoned as it's now actively pointing at forks. The previous proposals rely on the existence of these tools in the community as part of the justification for exclusion from the language.

Primitive decimal math is something that deserves a higher level of support for interoperability, security and long term stability.

timothy-king commented 5 months ago

rsc's comment (from 2016) when #12127 was closed: https://github.com/golang/go/issues/12127#issuecomment-262075744 . FWIW https://pkg.go.dev/github.com/shopspring/decimal?tab=importedby lists 34,460 known importers.

bojanz commented 4 months ago

In my opinion, shopspring/decimal hasn't been the most optimal* decimal implementation in the ecosystem for many years now. Projects should be looking to migrate to https://github.com/cockroachdb/apd

* - in terms of performance and correctness

sblackstone commented 4 months ago

In my opinion, shopspring/decimal hasn't been the most optimal* decimal implementation in the ecosystem for many years now. Projects should be looking to migrate to https://github.com/cockroachdb/apd

    • in terms of performance and correctness

I think this highlights the problem of something so fundamental being relegated to library support - we are forever stuck with a fragmented ecosystem for solutions that traditionally rely on fixed decimal (e.g. finance).

jufemaiz commented 3 months ago

I'm here for this proposal. That Go doesn't have a native type for decimals is IMHO a deficiency of the language. Claiming that "yeah, but there's non-native packages" is an acceptance of a shortcoming of a type critical for any measurement or financial use case.

IMHO this https://github.com/golang/go/issues/19787 would be the optimal spot for the discussion (and has it earmarked for Go v2, whenever that may be delivered)

ianlancetaylor commented 3 months ago

19787 (which is no longer marked v2) is about decimal float types, this issue is about decimal fixed types.

jufemaiz commented 3 months ago

19787 (which is no longer marked v2) is about decimal float types, this issue is about decimal fixed types.

Good catch (v2)! And 🤦🏼 on my behalf.

Liebenfiels commented 3 weeks ago

I read some articles, blogs and nothing has changed: • no float is good for any decimal analysis even if float32 is used • The Cobol had fixed point arithmetic’s at base 10- that works and good precision. • Most in finance use integers or still run on Cobol for above reason • Python import decimal works well as long as a = Decimal(‘0.1’) as string and it is good module with easy syntax, some book teach a=Decimal(0.1) but that will cause problems, library allows to type as no string. • GO does not have decimal module out of box, lots of proposals, there are third party libraries but some are not good. That does not help single standard as multiple choices exist and bring confusion.

Decimal module with easy syntax would help GO adoption- to migrate some finance program from Cobol, and for average users that are familiar with Python and understand floating point problems. I am learning GO so write that as novice observing space.

Liebenfiels commented 3 weeks ago

I watched original release vide from over 14 years ago.

The point was to declutter, but if generics are missing there is opposite effect if there are multiple libraries doing same things. None of decimal implementations including in Python are good to me as visual mess.

If to implement there should be single import and all to be treated as fixed point arithmetic’s with decent precision up to 9 to cover crypto and no added syntax and people could do their float32 or 64 as variables. Just to type 0.2 + 0.4 and have correct results rather than in Python Decimal("0.2") + Decimal("0.4")

Out of box base 10 with 9 decimal spaces would be enough for generic use. Of course they made originally GO for Google servers use not for generic as Python is for.

Many generics are missing: simply Tkinter equivalent GUI, what 1990 QBASIC had INKEY$ (to read key), time, power, random was all out of box- single standard, not some imports. I still use QBASIC to prototype, VGA standard each color as integer, can draw on screen and use keys if needed and have plenty precision. QBASIC was compiling with two math options. GO like Python still has code with too many libraries doing the same thing.