Answer 1

I've tested different compilers and CPU architectures now. It turns out that 0.0/0.0 = -nan is specific to x86-64 CPUs. On ARM CPUs 0.0/0.0 results in positive nan. Might be though that even AMD and Intel CPUs have different behavior.
The compiler doesn't make any difference, it's just the CPU that causes this weird behavior.
Yet it's interesting that clang optimises 0.0/0.0 to positive nan though the result without optimisations would be -nan.

Answer 2

https://stackoverflow.com/questions/21349847/positive-vs-negative-nans

Answer 3

I know all of them in JavaScript will print them same..
Except 0.0/0.0 : NaN not -NaN
//

1/0 infinity
0/0 nan
0/1 0
1/1 1
inf-inf nan
inf+inf inf
inf+nan nan
nan(+-*/)anything nan
nan==nan false

Answer 4

Sonic I don't think it's the compiler, it's rather the CPU. But I'll have a look on godbolt.org later.
ChillPill I can confirm that the signed bit is set to negative. 0.0 however has no negative sign. You can print the float as binary with this code of mine:
https://code.sololearn.com/ceat24D85Zxf/?ref=app

Answer 5

ChillPill just shared what I could find most relevant to the question.
Neither I understand the logic behind that.

Answer 6

For the second part of the question it seems to treat nan like a variable, which is very weird.

Answer 7

My guess is that some compilers always set the sign bit (to negative) when a result is nan, but of course it's a guess. It may be worthwhile testing this on several compilers.

Answer 8

On SL compiler, it's consistently -nan and not probabilistically positive or negative. Was just testing if it could be sometimes positive.

https://code.sololearn.com/cGoLP2m1OkGN/?ref=app

Answer 9

Aaron Eberhardt I see. Nice code BTW.

Answer 10

Now the question is what CPUs or Operating systems set the sign bit and which ones don't I guess.

Answer 11

ChillPill It seems like calculations with nan don't follow a certain logic except that they always return positive or negative nan. Probably there really isn't very much logic behind it because the sign of the nan actually doesn't matter. There's simply no reason why a CPU should process bits it doesn't care about (this also explains the weird behavior with 0.0/0.0).
The problem somehow is that nan doesn't depend on a sign yet floats have a fixed sign bit that undesirably influences nan, too. I think cout and printf should actually ignore the sign of nan: nan can not have a sign, it's not a number.

Answer 12

Important info:
banana

:D

Answer 13

My understanding of NaN is the only part of NaN with any significance is that it’s a NaN, there is no logic to how NaN is created, and it is a mistake to treat the leftmost bit as a sign bit or any other bit of it as having any significance. Whether this matches the specification of NaN or not, I don’t know.

Answer 14

yeah ChillPill . Nice discovery. i go with Aaron Eberhardt 's explanation. Sometimes different CPU architectures can whine the results. For example in computing as a whole, Arithmetic computation is usually converted to binary and the answer(result) is converted back to human readable format.

Answer 15

ChillPill take a look at this. nan is definitely not being treated like a variable there. The answer is positive nan in all these cases.

https://code.sololearn.com/cuVaXHfcmFd3/?ref=app

Answer 16

tushar sahni it's because 0.7 can't be accurately represented by a finite number of bits and because you get a number marginally greater than 0.7.

Answer 17

Sonic In python floats calculation are wobbly because they need to be converted to binary and the float may not have a binary so the closest is the result

Answer 18

Using exceptions

Answer 19

Hi
I think it's negative to distinguish number/0 and 0/0
But I'm not sure about this

Answer 20

Perhaps it's a hyphen and not a negative at all?
Also, regarding -nan+2*nan=nan, if all nan's are treated equal, then it makes sense to end as a positive...-nan+nan would cancel eachother out, so add another nan and you've got nan! Seems completely logical to me.