3

Why are the following unequal in Go? Is this a bug, or is it by design? If it's by design, why does this occur and is this type of behavior documented anywhere?

https://play.golang.org/p/itEV9zwV2a 

package main

import (
    "fmt"
)

func main() {
    x := 10.1

    fmt.Println("x == 10.1:        ", x == 10.1)
    fmt.Println("x*3.0 == 10.1*3.0:", x*3.0 == 10.1*3.0)
    fmt.Println("x*3.0:            ", x*3.0)
    fmt.Println("10.1*3.0:         ", 10.1*3.0)
}

Produces:

x == 10.1:         true
x*3.0 == 10.1*3.0: false
x*3.0:             30.299999999999997
10.1*3.0:          30.3

Note that the same floating point math is being performed, just with different syntax. So why is the result different? I would expect 10.1*3.0 to equal 30.29999... as in the x*3.0 example.

Erik Swan
  • 575
  • 4
  • 11
  • Possible duplicate of [Is floating point math broken?](https://stackoverflow.com/questions/588004/is-floating-point-math-broken) – Ken White Nov 09 '17 at 23:27
  • Ken, thanks. I don't think this is the same issue, since that question is about the well-known floating point math precision issues in many languages. Here, the same floating point math is being performed, but only with different syntax. Yet the result is different. To clarify, I would expect `10.1*3.0` to equal `30.299999...` as in the `x*3.0` example. – Erik Swan Nov 09 '17 at 23:30
  • 2
    The statement that "the same floating point math is being performed" is where you go wrong. – hobbs Nov 09 '17 at 23:38

2 Answers2

5

Constants and number literals in Go are untyped and have unlimited precision. The moment it has to be stored as a specific type, the bounds of that type apply. So when you declare x := 10.1, that literal is converted into a float and loses some precision. But when you specifically do 10.1*3.0 these have their full precision.

See the "Floats" header in this article. https://blog.golang.org/constants

Numeric constants live in an arbitrary-precision numeric space; they are just regular numbers. But when they are assigned to a variable the value must be able to fit in the destination. We can declare a constant with a very large value:

const Huge = 1e1000

—that's just a number, after all—but we can't assign it or even print it. This statement won't even compile:

fmt.Println(Huge)

The error is, "constant 1.00000e+1000 overflows float64", which is true. But Huge might be useful: we can use it in expressions with other constants and use the value of those expressions if the result can be represented in the range of a float64.

How it actually does this, especially in the given Huge case, I do not know.

RayfenWindspear
  • 6,116
  • 1
  • 30
  • 42
  • Interesting. This would make me expect that Go would throw a warning when a specific constant or literal cannot be expressed precisely in a `float64` (like 10.1 or .1), the same as if a huge number overflows an int or float type. I.e. 10.1 cannot truly "fit" in a `float64`, or a float of any length. Perhaps there was a design decision not to do this because the warnings would be so common. – Erik Swan Nov 09 '17 at 23:48
  • 1
    The compiler stores them as `big.Float`s (or `big.Int`s or `big.Rat`s), unsurprisingly. Remember, the Go compiler is written in Go :) – hobbs Nov 09 '17 at 23:52
  • BTW: the closest [binary32](https://en.wikipedia.org/wiki/Single-precision_floating-point_format) to 10.1 is 10.100000381... – chux - Reinstate Monica Nov 17 '17 at 02:34
3

The Go Programming Language Specification

Constants

Numeric constants represent exact values of arbitrary precision and do not overflow. Consequently, there are no constants denoting the IEEE-754 negative zero, infinity, and not-a-number values.

Implementation restriction: Although numeric constants have arbitrary precision in the language, a compiler may implement them using an internal representation with limited precision. That said, every implementation must:

  • Represent integer constants with at least 256 bits.

  • Represent floating-point constants, including the parts of a complex constant, with a mantissa of at least 256 bits and a signed binary exponent of at least 16 bits.

  • Give an error if unable to represent an integer constant precisely.

  • Give an error if unable to represent a floating-point or complex constant due to overflow.

  • Round to the nearest representable constant if unable to represent a floating-point or complex constant due to limits on precision.

Numeric types

A numeric type represents sets of integer or floating-point values. The predeclared architecture-independent floating-point numeric types are:

float32     the set of all IEEE-754 32-bit floating-point numbers
float64     the set of all IEEE-754 64-bit floating-point numbers

Constants use package math/big at compile time for arbitrary-precision arithmetic. Variables use IEEE-754, which is often provided by the hardware, for floating-point arithmetic.

peterSO
  • 158,998
  • 31
  • 281
  • 276
  • There's the definitive answer! I was just about to speculate on such compile time arithmetic in an edit to my answer I just discarded :) – RayfenWindspear Nov 09 '17 at 23:52
  • Thanks. This also specifically explains that the compiler should not throw a warning or error if the it is unable to represent a floating-point constant *due to limits on precision* (but will throw an error in the case of overflow). – Erik Swan Nov 09 '17 at 23:57