If it is not in stadnard library, then i will use the approach taken by
json.Number in stdlib
that seems simpler, let the users decide how to use it.
thanks
Santhosh
On Wed, Feb 17, 2021 at 3:02 AM Brian Candler wrote:
> Not in the standard libraries. See (declined):
>
> https://github.com/gol
Not in the standard libraries. See (declined):
https://github.com/golang/go/issues/12127
https://github.com/golang/go/issues/12332
However there are links to third-party libraries in those tickets.
On Tuesday, 16 February 2021 at 21:04:30 UTC Santhosh T wrote:
> is there java's BigDecimal equiv
On Wed, 2021-02-17 at 02:33 +0530, Santhosh T wrote:
> is there java's BigDecimal equivalent in golang ?
There is, for example https://github.com/shopspring/decimal. But you
should ask yourself why you need this.
--
You received this message because you are subscribed to the Google Groups
"gol
is there java's BigDecimal equivalent in golang ?
thanks
Santhosh
On Wed, Feb 17, 2021 at 2:05 AM Brian Candler wrote:
> You compared Golang's BigFloat with Java's BigDecimal. They are not the
> same.
>
> On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:
>
>> in Java, this is not
You compared Golang's BigFloat with Java's BigDecimal. They are not the
same.
On Tuesday, 16 February 2021 at 20:30:28 UTC Santhosh T wrote:
> in Java, this is not case.
>
> BigDecimal v = new BigDecimal("123.4");
> System.out.printf("%.20f\n", v); // prints 123.4000
On Tue, Feb 16, 2021 at 9:30 PM Santhosh T wrote:
> in Java, this is not case.
That compares decimal vs floating point representations. Those have
very different properties, for different usage patterns.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts
in Java, this is not case.
BigDecimal v = new BigDecimal("123.4");
System.out.printf("%.20f\n", v); // prints 123.4000
System.out.printf("%.40f\n", v); // prints
123.4000
you can see that it is represented exactly. I thou
On Sunday, 14 February 2021 at 21:57:31 UTC kortschak wrote:
> 123.4 cannot be represented in binary with a finite number of bits.
>
>
See: https://0.30004.com/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from t
On Sun, Feb 14, 2021 at 9:20 PM Santhosh Kumar T
wrote:
> I created:
> one instance using big.NewFloat function
> another instance using big.Float.SetString method
>
>
Adding to this:
Generally, comparing FP values for equality can give results you don't
expect due to the way numerics fo
Thanks for bringing this up. It surprised me too until I realised what was
going on.
The issue here is about the default precision that you're getting for those
big.Float values.
When you use big.NewFloat, the precision you get is exactly the same as
that of a base64 float (53 bits).
When you use
You can set your precision arbitrarily high, but you will still find a
point at which there are non-zero decimal digits.
https://play.golang.org/p/JYcAvXQPfeO
123.4 cannot be represented in binary with a finite number of bits.
On Sun, 2021-02-14 at 13:33 -0800, Santhosh Kumar T wrote:
> now I un
now I understand it. why they are not same
but why f2 printed as 123.4139
f2 is constructed using SetString method, so it should be accurate and
printed as 123.4000.
- Santhosh
On Monday, February 15, 2021 at 2:53:45 AM UTC+5:30 kortschak wrote:
> On Sun, 2021-0
On Sun, Feb 14, 2021 at 1:19 PM Santhosh Kumar T
wrote:
> When I print both values, they print exactly same. so I am assuming no
> precision lost for this specific example 123.4.
> but still Cmp returns non-zero.
>
As Dan pointed out, that is an invalid assumption. The code that formats a
float
On Sun, 2021-02-14 at 13:19 -0800, Santhosh Kumar T wrote:
> When I print both values, they print exactly same. so I am assuming
> no precision lost for this specific example 123.4.
> but still Cmp returns non-zero.
This is not a good assumption to make, and is refuted by the result of
Cmp.
https
When I print both values, they print exactly same. so I am assuming no
precision lost for this specific example 123.4.
but still Cmp returns non-zero.
---
Santhosh
On Monday, February 15, 2021 at 2:03:24 AM UTC+5:30 Kurtis Rader wrote:
> The value 123.4 cannot be represented exactly as a float6
The value 123.4 cannot be represented exactly as a float64. See
https://golang.org/pkg/math/big/#NewFloat for the caveats involved in using
NewFloat() or SetFloat64(). Passing a string representation allows the
implementation to preserve the exact value without rounding.
On Sun, Feb 14, 2021 at 12
I created:
one instance using big.NewFloat function
another instance using big.Float.SetString method
when compared both these instances using big.Float.Cmp, it return non-zero
code: https://play.golang.org/p/NhQ-klcph2z
am I doing something wrong ?
can some one explain why Cmp returns n
17 matches
Mail list logo
