To date exact floating point constants have not had a negative zero, and I don't see how we can change that now without breaking the Go 1 compatibility guarantee. The behaviour of programs like test/fixedbugs/bug434.go should not change.

More philosophically, the concept of a negative zero is meaningless in the world of exact floating point constants. There is no negative zero in mathematics. There is only zero. You can talk about zero as the limit of a function that produces negative numbers, and you can refer to that as negative zero, but there is no notion of that value as distinct from positive zero.

For better or for worse, Go's exact constants do not follow the rules of computer arithmetic. You can't write const c = int32(0x80000000). There's no necessary reason for them to support negative zero.

There are two ways to interpret Robert's second question. One is what should happen when handling an exact floating point constant that is too small to represent. The spec says fairly clearly that it should be converted to the nearest representable constant, which would be zero (neither negative zero nor positive zero, just plain zero).

The other interpretation is what should happen when converting an exact floating point constant to float32/float64 when the value is too small to represent and is negative. I don't think the spec says anything about that. As it happens, the gc and gccgo compilers behave differently, which also suggests that the spec doesn't cover the case.

This program

package main

import (
    "fmt"
    "math"
)

var v float32 = -1e-46

func main() {
    fmt.Println(v)
    fmt.Println(math.Float32bits(v))
}

prints 0 0 with gc and -0 2147483648 with gccgo.

My current inclination is to say that gc is correct and gccgo is wrong: we should convert a negative floating point number that is too small to represent to IEEE positive zero. But I think we could decide the other way here.

spec: Do exact floating-point constants differentiate between -0.0 and 0.0? #12576

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions