Isn't `true` the expected result? Apart from that, who would write code like this?
Antagonistic JavaScript code golfers typically are not JavaScript users, I've found.
edit: It's like writing an intentional buffer overflow in C. You don't see it as often because it requires actually knowing how to program.
The thing is, the result above is not even specific to JavaScript (in PHP for example it also returns `true`), and it makes a lot of sense if you know what the bitwise operators do.
Re:Deep JavaScript: Theory and Techniques
by mrspeaker on Wednesday June 17, 2020 @01:20PM
(#23553999)
Now I'm curious what result the OP was expecting... that's how bitwise NOT should work on (IEEE 754) floating-point numbers regardless of the language, isn't it?
(4.2).toString(2);
> "100.00110011001100110011001100110011001100110011001101"
(~4.2).toString(2);
> "-101"
(~~4.2).toString(2);
> "100"
Perhaps the initial NOT is supposed to maintain the bits after the point? I have to go look at the spec.[Ok, looks like that not defined in the spec, and is a language-specific behavior: I have some homework now!]
I think in C++ for example you can't even pass a floating number to the bitwise not operator.
Re:Deep JavaScript: Theory and Techniques
by seph-reed on Wednesday June 17, 2020 @01:41PM
(#23554280)
I wasn't intending to be antagonistic.
It's just interesting that it works.
What part is interesting or surprising? As per the spec, isn't this what the operators should do?
Re:Deep JavaScript: Theory and Techniques
by seph-reed on Wednesday June 17, 2020 @04:46PM
(#23556520)
I found it interesting and surprising and thought others might as well.
It appears my emotional response was not in line with everyone else's.
Re:Deep JavaScript: Theory and Techniques
by ByteJockey on Wednesday June 17, 2020 @10:26PM
(#23559176)
Could you maybe elaborate on what you expected?
`(~~4.2 === 4) && (~~-3.5 === -3)`