bigdecimal

[will]

Does golang have an equivalent of bigdecimal (which is useful in finance applications)

[Volker Dobler]

Am Mittwoch, 14. August 2013 17:10:07 UTC+2 schrieb will:

Does golang have an equivalent of bigdecimal (which is useful in finance applications)

My background is not finance. Could someone enlighten me why so many

people ask for decimal types?  What is wrong with int64 as n€?

And http://golang.org/pkg/math/big/#Rat is a superset of a decimal type

so if n€ in int64 looks strange: Why not use big.Rat?

V. 

[Ives van der Flaas]

Standard int64 is only for integers (obviously). In finance (and other applications) one often wants to represent decimal numbers (so non-integers) with basically infinite precision. Say for example the amount of money on your bank account. Now, you could say "this datamember is expressed in cents, or 1/10 cents, or 1/1 000 000 dollars", or whatever small amount you think will provide you with enough precision, but that still limits the precision and also results in code that is less clear. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Ives van der Flaas
☎ 0499/31.54.37

[Ives van der Flaas]

(Possibly a wrapper around) big.Rat is indeed an option. I had no idea of its existence. 

[wkharold]

http://golang.org/pkg/math/big/

[will]

Does func (*Rat) Float64 cover it?  I doubt it

[will]

i seriously think Go needs bigdecimal inbiuilt into the kanguage (http://justincase.cx/2012/12/05/BigDecimal_examples_in_Go_golang/)

On Wednesday, 14 August 2013 17:48:32 UTC+2, wkharold wrote:

[Péter Szilágyi]

Hi,

  Just a quick hack, your example code using big.Rat: http://play.golang.org/p/Dk8V35mTLj

  Obviously you could add a fancier Round method, but the point is that big.Rat pretty much covers your needs (if not, do show such an example :) )

Cheers,

  Peter

--

[Miki Tebeka]

One option is http://godoc.org/github.com/jamesadney/gmp

[will]

Hey Peter,

I followed the link.

subtotal, _ := new(big.Rat).Mul(x, y).Float64() is worrying, the part about .Float64(), would this be used in a financial application(worried about precision loss). I am new to GO guys and I love GO.  Am not so sure this covers it. Help!

[Kevin Gillette]

http://godoc.org/?q=decimal

On Wednesday, August 14, 2013 9:31:19 AM UTC-6, Ives van der Flaas wrote:

Standard int64 is only for integers (obviously). In finance (and other applications) one often wants to represent decimal numbers (so non-integers) with basically infinite precision. Say for example the amount of money on your bank account. Now, you could say "this datamember is expressed in cents, or 1/10 cents, or 1/1 000 000 dollars", or whatever small amount you think will provide you with enough precision, but that still limits the precision and also results in code that is less clear.

When dealing with a single currency type at a fixed point in time, expressing values in terms of mils (e.g. cents) or fixed fractions thereof is preferable from an efficiency perspective. Note that there are a few currency types that use multiples/divisions of 5 and there may be other odd cases -- point being that "decimal" may not be a sound representation for every kind of financial computation.

[will]

How do i handle 0.1499999999999999944488848768742172978818416595458984375?

[Gerard]

On Friday, August 16, 2013 7:56:23 AM UTC+2, will wrote:

How do i handle 0.1499999999999999944488848768742172978818416595458984375?

You round it to the lowest digit. Let's say you have 2 digits 1.00 then your number of 1.14999999 is rounded to 1.15

And inside the struct the values are (for example): Value 115, Decimal 2

So when you import the number 1.14999999 you multiply it with 10^decimal and then round it.

For the rounding search golang-nuts

[RickyS]

Most or all business systems specify fixed decimal.  For example, quantities are first rounded and then summed, rather than the possibly more accurate system of summing and then rounding the result.  One purpose of this is to ensure that a customer with an adding machine gets the same result.  To the penny.  That may or may not be an obsolete purpose.

Also see the Intel standard for decimal arithmetic.

There are also variations from currency to currency.  Especially where the smallest coin is not the smallest amount.  Imagine if the US abolished pennies (pence).  The smallest coin payment would be a multiple of 5 cents, but accounts would still be calculated to the penny.

[RickyS]

Decimal arithmetic is a bigger topic than many of you know.  Early computers in the 1950's and 1960's were often built with decimal fixed-point hardware in order to support financial applications.  There are a number of international standards and laws that specify how calculations are to be done.

The best place to start is probably this Wikipedia article on decimal floating point.

But see this package on sourceforge, in Java.

And this page on computing with decimal arithmetic. 

The packages referenced are all about floating point decimal, which is a more advanced evolution of decimal from fixed-point.  But finance got along for decades with just fixed-point decimal.

Perhaps at some point there will be a decimal data type in Golang.  This topic is good fodder for the arguments on generics, extensibility, inheritance and so on.  That is, a good test for an extension mechanism of golang would be: How could we use it to implement decimal arithmetic and data types?

[Watson Ladd]

Write the damn thing yourself! It's not that hard.

On Wednesday, August 14, 2013 8:10:07 AM UTC-7, will wrote:

[fran...@krave-n.com]

It's helpful if basic datatypes are standardized across the language, and just because it's easy doesn't mean it is the right approach. 

Financial applications would benefit from having a standard implementation of fixed precision decimals. 

[Ben Hood]

On Fri, Oct 31, 2014 at 7:28 PM, <fran...@krave-n.com> wrote:
> It's helpful if basic datatypes are standardized across the language, and
> just because it's easy doesn't mean it is the right approach.
>
> Financial applications would benefit from having a standard implementation
> of fixed precision decimals.

FWIW dec/inf (speter.net/go/exp/math/dec/inf) integrates with
BigDecimal from Java.

[Franklin Wise]

great thanks

--

franklin wise :: ceo & founder 

krave-n.com :: eat what you krave, love what you eat

fran...@krave-n.com :: 424.235.7283

"stay hungry, stay foolish"  - steve jobs