robaho / fixed Goto Github PK

The Mul() uses float64 math. It’s not typically a problem with the rounding at the 8th place bue using integer math should be more accurate an possible faster.

Hello,
can fixed handle decimal points like this 0.0002849002849002849 with 100% precision?

So NewI(123,-1) results in 12.3

They appear to be suffering from float conversion problems.

Add the Marshall and Unmarshall methids

Rename NewSErr to Parse, NewS to MustParse to follow stdlib style (see package text/template).

I'm rewriting some code from python to go and using this excellent library.

As I understand this library implements rounding using ROUND_HALF_UP algorithm, but I've noticed that sometimes this library rounds numbers differently from python's decimal package, see example:

fmt.Printf("%s\n", fixed.MustParse("2234.565").Round(2).String()) // 2234.56

print(decimal.Decimal("2234.565").quantize(decimal.Decimal("0.01"), rounding=decimal.ROUND_HALF_UP)) # 2234.57

So, for input 2234.565 fixed's output is 2234.56, while python's output is 2234.57.

Is .56 result correct? I think rounding away from zero should give us .57.

Also could you please clarify that ROUND_HALF_UP from python should match this library's version? Or maybe I'm wrong and should be comparing this library to some other python rounding mode (https://docs.python.org/3/library/decimal.html#rounding-modes). I assume I should be comparing against ROUND_HALF_UP because fixed's source code says so:

// Round returns a rounded (half-up, away from zero) to n decimal places
func (f Fixed) Round(n int) Fixed {

The value of 0.0004096 would be treated as NaN.

JSON encoding of NaN numbers doesn't work:

func (f Fixed) MarshalJSON() ([]byte, error) {
buffer := make([]byte, 24)
return itoa(buffer, f.fp), nil
}

it would be awesome if we can use it with Protobuf.

Replace with direct Read and Write for serialization.