I was hoping to learn something here, but this was a very disappointing blog post. Everything is ordinary except that Golang doesn’t seem to allow negative zero literals. That’s the whole post.

Something I wish was touched upon, and a more useful use of negative zero in my experience, is that it can indicate that a value got very small from the negative side.

For example, if you perform a calculation such as 1e-200*-1e-200, you should be getting negative zero in any “reasonable” programming language, which includes any programming language that obeys IEEE 754. This is a contrived example, but it is relevant when you have a numerical procedure that happens to converge to zero from the negative side. In that case, the sign of zero carries information that exceeded the amount of precision that can be stored in a float.

I appreciate these sorts of sanity checks that programming language implementations behave as we desire. To quote a Go contributor on this issue, we should work to implement “no-surprises support for IEEE floating point” when we have IEEE 754 support at all.

I was hoping to learn something here, but this was a very disappointing blog post. Everything is ordinary except that Golang doesn’t seem to allow negative zero literals. That’s the whole post.

Something I wish was touched upon, and a more useful use of negative zero in my experience, is that it can indicate that a value got very small from the negative side.

For example, if you perform a calculation such as

`1e-200*-1e-200`

, you should be getting negative zero in any “reasonable” programming language, which includes any programming language that obeys IEEE 754. This is a contrived example, but it is relevant when you have a numerical procedure that happens to converge to zero from the negative side. In that case, the sign of zero carries information that exceeded the amount of precision that can be stored in a float.Yes, and fun things with atan2 that’s actually important with +/- 0.0 and +/- infinity. Here is a unit test for gambit scheme: https://github.com/gambit/gambit/blob/master/tests/unit-tests/02-flonum/flatan.scm

I appreciate these sorts of sanity checks that programming language implementations behave as we desire. To quote a Go contributor on this issue, we should work to implement “no-surprises support for IEEE floating point” when we have IEEE 754 support at all.

Another use for -0.0 is as the additive identity for IEEE 754 floats. This is because

`-0.0 + 0.0 !== -0.0`

.