Why fprintf('%​3.1f',roun​d(-eps)) prints -0.0?

I found some very strange behaviour of the round function in Matlab R2016b (at least for me). I would expect that the round function returns 0 for -eps, but surprisingly the command:

num2hex(round(-eps))

Returns:

8000000000000000

Instead of

num2hex(0) == 0000000000000000

This causes fprintf() to print -0.0. Is this a bug or I just miss something?

[James Tursa]

Side Note: This seems to be consistent among the related functions ceil and fix as well. E.g.,

>> num2hex(round(-eps))
ans =
8000000000000000
>> num2hex(ceil(-eps))
ans =
8000000000000000
>> num2hex(fix(-eps))
ans =
8000000000000000

Answer 1

[Stephen23]

You are missing the fact that MATLAB has two zeros: positive zero and negative zero, which have different HEX values. This is a result of the IEEE 754 floating point standard that MATLAB implements, which uses one bit to indicate the number sign: a corollary of this is that even a zero can be positive or negative.

It is not possible to use < to directly test if zero is negative (by definition negative zero is equal to positive zero, so this makes sense):

 >> (-0)<0
 ans =
     0

but here is one simple trick that will test for negative zero:

 >> (1/-0)<0
 ans =
     1

Which relies on this behavior:

 >> 1/-0
 ans =
   -Inf
 >> 1/round(-eps) % your question
 ans =
   -Inf

Neat huh!

You can find more interesting information on negative zeros here:

https://en.wikipedia.org/wiki/Signed_zero

Answer 2

[Adam]

https://uk.mathworks.com/matlabcentral/answers/91430-why-does-fprintf-put-minus-signs-in-front-of-zeros-in-my-file?s_tid=answers_rc1-1_p1_MLT