I was experimenting lately with golang's type system and encountered an interesting (or not) behaviour related to floats:
package main
import (
"fmt"
)
func main() {
doesntWork()
works()
}
func doesntWork() {
x := 1234
y := x / 100000.0
s := fmt.Sprintf("%.8f", y)
fmt.Printf("%s
", s)
}
func works() {
x := 1234
y := float64(x) / 100000.0
s := fmt.Sprintf("%.8f", y)
fmt.Printf("%s
", s)
}
I think that in the case presented in the example above, in procedure doesntWork()
, golang does not automatically "assume" float32/64
when dividing an int
by an implicit float
? Is that correct? Could anyone point me towards some docs or specs where I could learn more about how golang behaves in situations like the one above?
Here 10000.0
is not float64/32 it is a numeric constant. Go will assume the type of x
in this case for the expression and truncate
the constant 100000.0 to integer
func doesntWork() {
x := 1234
y := x / 100000.0
s := fmt.Sprintf("%.8f", y)
fmt.Printf("%s
", s)
}
If you update it to
func doesntWork() {
x := 1234
y := x / float64(100000.0)
s := fmt.Sprintf("%.8f", y)
fmt.Printf("%s
", s)
}
it will error out saying
invalid operation: x / float64(100000) (mismatched types int and float64)
Similarly if you change the constant to 100000.111 where truncating
to integer will no longer give the same value it will error out
func doesntWork() {
x := 1234
y := x / 100000.1
s := fmt.Sprintf("%.8f", y)
fmt.Printf("%s
", s)
}
It will error out saying
constant 100000 truncated to integer