Re: [go-nuts] Decimal type

[Jesse McNelis]

On Sun, Oct 28, 2012 at 3:52 AM, <rdem...@gmail.com> wrote:
> I know there is a third-party lib, godec, but, wouldn't it be better if
> it was part of the language?
> Thanks,
> Roger

You can read about the reasons why the language doesn't have a
decimal(fixed point) arithmetic type in the list archives.
https://groups.google.com/forum/?fromgroups#!topicsearchin/golang-nuts/group:golang-nuts$20AND$20subject:Decimal

In short, there is no standard hardware implementation of fixed point
arithmetic.


--
=====================
http://jessta.id.au

[Peter S]

On Sun, Oct 28, 2012 at 1:52 AM, <rdem...@gmail.com> wrote:

Hi,
I like golang, but to improve it, I think it needs a Decimal type.
For instance, without such type, when doing math won't there be
rounding errors?

How can this be handled without a Decimal type?
I know there was an earlier post on this, but still, how
can accurate math be done?

I know there is a third-party lib, godec, but, wouldn't it be better if
it was part of the language?

Thanks for looking at my library godec.

Could you give some examples of what you can't achieve with godec but you'd expect to be able to do if decimal support was part of the language?

Also note that big.Rat from the standard library's math/big package can be an alternative for many use cases. (I'm not quite sure if by "part of the language" you were referring to a predeclared type like complex128 or a type in the standard library like big.Int/Rat.)

Peter

Thanks,
Roger

--
 
 

[minux]

i think the primary reason of the absence of such a package in stdlib is

simply due to lack of time. i don't think lacking hardware implementation

would hinder the inclusion of such a package (do we have hardware

implementation of big.Int?)

[Peter S]

I created godec[1] as an external package because it seemed good enough (there are many other ancillary math libraries released as external packages) and it wasn't obvious from past threads whether the Go team considered a decimal type something that would / should (eventually) be part of the stdlib. But in case it just hasn't been implemented in stdlib due to lack of time, and if an implementation based on godec makes sense, I'd be more than happy to contribute. (Although I do understand that just reviewing also takes a fair amount of time and effort from the Go team.)

[1] http://code.google.com/p/godec/

Peter

 

--
 
 

[Michael Jones]

Peter I have a question about this. How many decimal digits are necessary in the types of computations one might imagine? (i.e., is the bigness of big valuable or would a fixed precision 128-bit decimal be sufficient?)

I remember the discussion from before and am familiar with IEEE proposals and Mike Colinshaw's library. Just asking here for your sense of the need.

--
 
 

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Peter S]

Thanks for taking the time to look at it. It is a very good question; just like with generics, different people might have different expectations from a decimal type.

Here are what I consider to be the pros for the multi-precision approach taken in godec:

1. Exact arithmetic: my impression has been that many people who want to use a decimal type do so because they are concerned about the exactness of the result (like the OP), and it is often a greater concern than efficiency. (Those for whom the performance of decimal calculations is really critical likely use a platform that has hardware support for it anyway.) To this end, godec never rounds numbers implicitly and never overflows, and this implies multi-precision. (Technically, scale is fixed size and can overflow, but I can't think of a situation where that possibility would be a practical concern. I did consider adding panics for scale overflow but decided that even that would be overly defensive.)

2. Interoperability: it could be used for exchanging precise decimal data among various components. E.g. MySQL supports 65 decimals (216 bit precision), PostgreSQL up to 147455 decimals (up to 489835 bit precision), and Oracle 38 decimals (128 bit precision). It would be desirable that drivers can accept/return precise values as a decimal, but none of these are covered by decimal128. Actually this thread got me to reconsider the pros and cons for having decimal support in an external package vs stdlib, and I've come to think that this is a strong argument for having a decimal type in the stdlib: using external packages in individual applications is usually not an issue, but adding external dependencies to libraries that are used in several projects (such as database drivers) can often be problematic / undesirable.

3. Code reuse: using the big.Int implementations for a large part of the arithmetic greatly reduces maintenance burden.

With the only con I am aware of being that it is potentially less efficient than using fixed-precision. Although even with fixed-precision, considering interoperability, I'd probably prefer/recommend using at least 256 bits, and then, assuming that small values are more frequently used, I'm not sure if operations on fixed-precision (200+ bit precision) values would be faster than multi-precision (but most often single word) values. (I guess the only way to know for sure is to implement and benchmark both...)

Based on these pros and cons, I consider it to be a reasonable compromise, but at the same time I understand that it may or may not be what others are looking for, or what the Go team would consider suitable for the stdlib.

Of course, it does not need to be one or another; there could be separate types for fixed and multi-precision, or maybe even a single type that can handle both representations internally, but I don't think it would be worth the added complexity.

Peter

[bryanturley]

On Saturday, October 27, 2012 11:52:46 AM UTC-5, rdem...@gmail.com wrote:

Hi,
I like golang, but to improve it, I think it needs a Decimal type.
For instance, without such type, when doing math won't there be
rounding errors?

How can this be handled without a Decimal type?
I know there was an earlier post on this, but still, how
can accurate math be done?

I know there is a third-party lib, godec, but, wouldn't it be better if
it was part of the language?
Thanks,
Roger

He doesn't seem to mention http://golang.org/pkg/math/big/#Rat  ?
Perhaps you didn't know about it Roger?

[Kevin Gillette]

On Saturday, October 27, 2012 8:57:27 PM UTC-6, Jesse McNelis wrote:

In short, there is no standard hardware implementation of fixed point 
arithmetic.

Not that I'll be talking about fixed-point arithmetic (which also wasn't necessarily implied by the OP), but I'd be rather interested in seeing builtin decimal32 and decimal64 types, following the updated IEEE-754 spec, despite there being no hardware implementations on the market, for a number of reasons:

1) It's hardly unprecedented for Go: as I understand it, floats on ARMv5 are emulated.

2) It has been stated several times that Go, unlike C++, has a feature set that is _not_ dictated by the nature of hardware as it is today. I'm taking this slightly out of context, yes.

3) Go will become much more palatable to businesses that deal with base-10 finances (which is most of the world), or for the many applications in which decimal rounding errors can not be tolerated.

4) Even if hardware is never put on the consumer market that implements IEEE-754 decimal types, a sized, decimal-specific implementation will be measurable faster than math/big, and considerably cleaner and more approachable for the use cases in which it is suited.

My simpler logic is that if there's ever the possibility that we'd introduce a builtin decimal type, and when doing so, if we'd have to emulate it on any platforms, then if anyone is willing, we might as well just do it now.