Can somebody explain, why `(0F/0F).coerceIn(0F,1F)...
# announcements
p
Can somebody explain, why
(0F/0F).coerceIn(0F,1F)
NaN
?
z
NaN cannot be mapped to range, as it's "*N*ot a *N*umber"
regular math and comparisons don't work on it, so it can't really become a valid number, either 0 or 1 that you have
p
As it's not coerced in that case shouldn't it throw instead?
s
It seems pretty in line with the usual behavior that all operations involving
NaN
is
NaN
Not sure anything involving
NaN
is ever intuitive so I guess you could argue either way
p
NaN was never helpful and is a bug in every single case I faced it 😕
z
as for throwing, that's java behavior, where it throws when you divide something by zero
s
@Zan Skamljic No. Why dont you try it out.
z
yes, actually
s
That is not the case we are discussing
g
Because it’s int, float will return NaN
z
my bad, yeah, float seems to return NaN
g
The reason of this behaviour is IEEE 754 and it’s widely adopted by programming languages and hardware
âž• 2