How to keep precision for big numbers in golang when converting from float to big.Int

I have an input that could be a very big or a very small float and need to convert it to big.Int, but for some reason, there is some precision loss.
I understand that this should happen for very small numbers, but why does it happen for a big number, and how to avoid it?

https://go.dev/play/p/AySnKAikSRx

All positive integers up to 9007199254740992 can be represented in a float64 without any loss of precision. Anything higher, you run the risk of precision loss, which is happening in your case.

To give a basic idea of why..

Say we're inventing an extremely compact scheme for representing floating point numbers using the following formula:

m.mm * 10^+-e

.. where:

• e = exponent, [1-9]
• m.mm = mantissa [0.01-9.99]

With this, we can figure out what range of values can be represented:

• lowest = 0.01 * 10^-9 = 0.00000000001
• highest = 9.99 * 10^9 = 9990000000

So that's a pretty decent range of numbers.

We can represent a fair few positive integers without any difficulty, e.g.

1   = 1.00 * 10^0
2   = 2.00 * 10^0
3   = 3.00 * 10^0
⋮
10  = 1.00 * 10^1
11  = 1.10 * 10^1
12  = 1.20 * 10^1
⋮
100 = 1.00 * 10^2
101 = 1.01 * 10^2
102 = 1.02 * 10^2
⋮
999 = 9.99 * 10^2

The problem starts when we exceed 9.99 * 10^2. It's not an issue to represent 1000:

1000 = 1.00 * 10^3

But how do represent 1001? The next possible value is

1.01 * 10^3 = 1010

Which is +9 loss of precision, so we have to settle on 1.00 * 10^3 with -1 loss of precision.

The above is in essence how this plays out with float64, except in base 2 and with a 52 bit mantissa in play. With all 52 bits set, and then adding one, the value is:

1.0 * 2^53 = 9007199254740992

So all positive integers up to this value can be represented without precision loss. Integers higher than this may incur precision loss - it very much depends on the value.

Now, the value referenced in your Go code:

var x float64 = 827273999999999954

There is no way to represent this exact value as a float64.

package main

import (
	"fmt"
)

func main() {
	var x float64 = 827273999999999954

	fmt.Printf("%f\n", x)
}

yields..

827274000000000000.000000

So essentially precision is lost by the time x is initialized. But when does that occur? If we run..

$ go build -o tmp
$ go tool objdump tmp

And search for TEXT main.main(SB), we can find the instruction:

main.go:10            0x108b654               48b840d5cba322f6a643    MOVQ $0x43a6f622a3cbd540, AX

So 0x43a6f622a3cbd540 is being set into AX - this is our float64 value.

package main

import (
	"fmt"
	"math"
)

func main() {
	fmt.Printf("float: %f\n", math.Float64frombits(0x43a6f622a3cbd540))
}

prints

float: 827274000000000000.000000

So the precision has essentially been lost at compile time (which makes sense). So on the line of code with big.NewFloat(x).Int(nil), the value being passed as x is 827274000000000000.000000

> how to avoid it?

With the code you've provided, there is no way.

If you're able to represent the value as an integer..

package main

import (
	"fmt"
	"math/big"
)

func main() {
	var x uint64 = 827273999999999954

	bf := (&big.Float{}).SetUint64(x)
	
	fmt.Println(bf)
}

yields

8.27273999999999954e+17

which is the value you're expecting. Or alternatively via a string:

package main

import (
	"fmt"
	"math/big"
)

func main() {
	var x string = "827273999999999954"

	bf, ok := (&big.Float{}).SetString(x)
	if !ok {
		panic("failed to set string")
	}

	fmt.Println(bf)
}