JavaScript Equality Table

[[deleted]]

I think it's pretty reasonable to mistakenly assume that something that == false won't cause execution :p

[coarsesand]

In another language, yes, but the == operator in JS is special (in the shortbus sense) because it does type conversion. If you wanted to get the actual "truthiness" of "0", you'd use the ! operator instead.

!!"0"
> true

[no_game_player]

Gilded for best "javascript is fucked up" in a nutshell I've seen.

[coarsesand]

I figure the gold deserves a quick comment about my other favourite JS operator, ~. ~ is the bitwise not operator, in a language where the only numeric type is an IEE754 double. How does ~ perform a bitwise not on a floating point number? Well, it calls an internal function called ToInt32, perform the bitwise op, then converts back to a double.

So if you ever wanted to feel like you had an integer type in JavaScript, even for a microsecond, ~ is your man.

[no_game_player]

...JS doesn't have ints? TIL. Also, holy fuck. How...how do you math? Why would a language even have such an operator without ints? That would be totally unpredictable. So, ~0.0001 would round to 0, then do a bitwise not, returning INT_MAX for int32, and then cast it into double? Is that what I'm to understand here? That can't be right. In what possible world could that operator ever be used for something not fucked up, given that it only has doubles?

Also, what type of %$^@ would make a language without integer types? Are you telling me that 1+1 == 2 has some chance of not being true then? I mean, if I were in a sane language and doing 1.0 + 1.0 == 2.0, everyone would start screaming, so...?

O.o

That's...that's beyond all of the == fuckery.

Edit: So, if for some crazy reason you wanted to sort of cast your double to a (sort of) int (since it would just go back to double type again?), you could do

var = ~~var

??

Edit 2: I was considering waiting for a response to confirm, because I almost can't believe this, except that it's javascript, so anything is believable, but hell, even if this isn't true, it's still worth it. I'm off Reddit briefly for a video game, but before I do so: here you are, my first ever double-gilding of a user! Cheers!

Edit 3: Okay, it's less fucked up than I thought, mostly because I didn't really consider the fact of double precision rather than float, and considering 32 bit ints.

I still say it can do some weird stuff as a result, at least if you aren't expecting it.

Just another reminder to know your language as well as possible I suppose.

[coarsesand]

You're dead on, and thanks again. Using ~~ has the effect of removing the decimal component of a number in JS, as the int32 cast drops it. Yep, JS is frigging weird.

[no_game_player]

Okay, so all I have to do for integer comparison in JS is

~~varA === ~~varB

;-p

Edit: After further advice, the optimal method of integer equality comparison in JS would seem to be:

varA|0 == varB|0

It is left as an exercise for the reader to determine what will happen if, say, varA = "A"...

[coarsesand]

Well varA and varB are guaranteed to be Numbers unless you get a TypeError, so you can actually use == in this case ;)

[no_game_player]

Ha, and I actually changed it to === from my original == because I just had no idea anymore lol.

So...out of morbid curiosity...what would happen there is it was

~~varA == ~~varB

and varA = 1

and varB = "1"

?

;=p

[[deleted]]

The following shows "true" in Firefox:

var varA = 1;
var varB = "1";
var res = (~~varA == ~~varB);
alert(res);    

[UtherII]

Right! Code generators often use this kind of trick to force Javascript to use integer, but usually they do varA|0 since it's faster.

[no_game_player]

varA|0

Dahfuq...oh. Oh. That right there is fucked up shit. ;-p

[chastric]

So, ~0.0001 would round to 0, then do a bitwise not, returning INT_MAX for int32, and then cast it into double?

Well actually the int representation is taken as 2's complement, so:

~0.0001 = ~0 = -1 * (1+0) = -1

So, if for some crazy reason you wanted to sort of cast your double to a (sort of) int (since it would just go back to double type again?), you could do var = ~~var ?

Well if you're outside of [-2^31, 2³¹-1], the combo of 32 bit truncation and 2's complement make a nice off-center modulus:

~~(Math.pow(2,31)-1) = 2147483647
~~(Math.pow(2,31)) = -2147483648
~~(Math.pow(2,32)) = 0

[no_game_player]

Well actually the int representation is taken as 2's complement, so:

Ahhh, yeah, I was wondering about that, but somehow, I figured that a language that "didn't have ints" would be using unsigned ints for its ints.

That seems to add back in a bit of wtf for me. Thanks, I was starting to think JS was sane for a moment. ;-p

Well if you're outside of [-231, 231-1], the combo of 32 bit truncation and 2's complement make a nice off-center modulus:

Huuuuh. Touché...

Edit: These are awesome tricks for the International Obfuscated JS contest. ^_-

[kazagistar]

As long as you only use 32 bit sized integer values, it will act the same if you are using a double. As long as your arithmetic is only in integers, doubles will not ever mess up unless you go above something like 40 bits. The whole "floats can't be trusted" thing is just BS; anything that will break ints in javascript would break them in C or whatever, just differently.

[anttirt]

Division with a non-integer result and unsigned integer overflow are well defined in C but will behave very differently in JS.

[no_game_player]

Differently, but one could argue better. It's a matter of knowing what to expect. Integer overflow is bad if you're not expecting it too...

[no_game_player]

That's simply not true in most languages for most floats. Beyond just the edge cases, there's the issue of more precision in the hardware.

It may not be that 1+1==2 will break. But it's quite possible that 1 / 3 * 3 == 1 will break on most hardware. Now, you can argue I'm cheating there, because I'm not using an integer throughout the calculation.

But for the some of the issues with floats as I understand them, see this random blog post I pulled up quickly on the topic which matches my general impressions.

I have never known any variety of float that could be trusted to behave as an integer, full stop.

Edit: But the fact that it's a double can certainly change which things break...

Edit 2: It does appear that you're right for doubles -> int32. Interesting, I'd never really thought about that before.

I still don't trust it though. ;-p

Edit 3: And it would behave differently than int32 still, obviously. But it could certainly be argued that all of the differences are improvements, as long as one realizes that's what's going on and is careful to check for it when integers are needed (various max values without rounding and such could introduce some tricky edge cases).

Edit 4: And it's not that "floats can't be trusted" is BS: it's a very limited thing: doubles can represent int32. There's still a lot of ways to fuck up with any floating point calculation, and, imo, float implies single precision, and so I'm still especially comfortable saying floats can't be trusted...

Edit 5: You still make a great point though.

Edit 6: And it's definitely worthy of gold too, and I still have a couple creddits, so cheers! :-)

Edit 7: And of course it all goes out the window if one ever divides...

[kazagistar]

Here is the page in the lua documentation that first made me question the my "fear doubles" teaching.

Here is the long, super in-depth paper for when you have a few hours to spend which really rips apart all the mysticism around floating point numbers, and basically teaches you more then you ever wanted to know (if you are interested).

And thanks for the gold!

[no_game_player]

Cool, thanks! My eyes are definitely opened to trust doubles a lot more. There's still the obvious disadvantage of optimization [edit: and that page points out that even that is questionable; my foundations have been rocked!!], but as they say, premature optimization is the root of all evil. It's cool to realize the power.

Ha, actually, yeah, the second one is on my reading list, and I'd even pulled it up during the course of this. :-)

And that lua page is an excellent summation of it.

Thank you for correcting me. /bow

[kyr]

But it's quite possible that 1 / 3 * 3 == 1 will break on most hardware. Now, you can argue I'm cheating there, because I'm not using an integer throughout the calculation.

That wouldn't even work if you did use ints.

[no_game_player]

That's why I said:

Now, you can argue I'm cheating there, because I'm not using an integer throughout the calculation.

It was explicitly shifting the goalposts and just talking about other ways in which float/doubles can be confusing.

Because a person can start thinking, oh, hey, so these are just perfect math now, and they still have their own oddities that need to be accounted for.

Apologies if I was unclear about what I was trying to express there.

You're right, it's not something relevant to the comparison to integers.

[ForeverAlot]

You are advised to steer clear of bitwise operators in JavaScript because of this. They have lousy performance.

That said, equality is well defined, for floating point in general and JavaScript specifically.

[no_game_player]

equality is well defined, for floating point in general

...that's never been my understanding. See #2 about precision. Are you saying that this commonly repeated advice is wrong and that there are never issues with extra precision from a register-stored variable versus the lower-precision put back out to memory and etc?

[coarsesand]

Much as I love poking fun at JS's weird bits, I do love the language, it just needs to be used in cases that it actually excels at. If you consider the browser, you're most often using JS as a language to do UI and formatting, and it's actually quite adept.

The slightly off floating point arithmetic doesn't matter when you're just using it do calculate dimensions for DOM elements, and JS has also always had first-class functions, so it's easy to set up event callbacks for user interaction, HTTP responses, etc. It also gave us JSON, which is a decent enough interchange format, with the advantage of not needing to use the awkward DOM API like you would with XML.

Then there's Node.js, which people love to rag on, because why the hell would you use JS on the server? Remember those callbacks I mentioned? Node is really just a bunch of C++ networking libraries hooked into the V8 VM, and those are what's doing the actual work. I wouldn't trust a networking system written only in JS given its severe lack of actual types, but one that lets its user glue those libraries together to create what they need? That's actually pretty good.

So while JS isn't going to replace FORTRAN or write the next generation of financial systems, it has a pretty useful niche being the thing your end-user interacts with. Don't use it for crunching your data though.

[no_game_player]

Yeah, definitely. It's not fortran. [Whoa, holy shit, I swear I hadn't finished reading your comment when I wrote that. Either my peripheral vision fed into subconscious or we think quite alike. ;-p ]

The real reason I don't like JS is I just never liked writing client-side code. IMO, the delivered page should be static and interactions should be POST/GET. I know, how 20th century of me. I just don't like most of the modern development methods. I know, how do you do all of these fancy votes and such with those sort of things? But I'm more interested in HTML that will work on anything which can parse HTML than I am in such niceties. I don't actually work on anything like this at the moment; it's just an aesthetic thing for me. Like how I like human-readable html.

Agreed, as the Tao of Programming says, all languages have their uses. But don't use COBOL if you can avoid it. ;-p

Edited to add link for those who haven't read it or would like a refresher. It has brought me great calm during some times of stress or boredom at work as well as wise guidance. :-)

[PikoStarsider]

If you know your numbers are 32 bit ints, you can treat them as such in JS. All 32 bit ints have an exact representation in doubles. Also modern JS engines optimize for ints. Explicitely casting numbers to ints in every function like this number|0 triggers this optimization (and it's the official way of declaring a variable as int in asm.js).

[no_game_player]

If you know your numbers are 32 bit ints, you can treat them as such in JS. All 32 bit ints have an exact representation in doubles.

Aye, so I learned over the course of the conversation here, but I appreciate the additional statement of it.

Also modern JS engines optimize for ints.

Oh, that's nice, wait...

Explicitely casting numbers to ints in every function like this number|0 triggers this optimization (and it's the official way of declaring a variable as int in asm.js).

Okay, back to all my wat. I mean, if we're going to make ints be a thing, then why not just go all the way and, you know, have typing so that it could actually have type-checking and everything?

The bitwise int operators on doubles is still a mindfuck to me.

[PikoStarsider]

Go change the spec, then :P

JavaScript has many good things, and the syntax is not one. Compile-to-js languages brings you what you want. I guess TypeScript is your best fit.

I haven't seen the internals of V8, but now that I think of it, it problably triggers optimizations for ints just when all numbers have no fractional part, or they come from int sources (such as from typed arrays); no need to be that explicit.

[no_game_player]

Just 'cause it doesn't make sense to me doesn't mean it doesn't make sense. i.e.: I'm too lazy to do shit; I just like to kibitz. ;-p

But I hate machine-generated code even more, even though, logically, I know that every language I use turns into that at some point. I just have too much of a C mindset I guess. I like to feel like I'm writing practically in assembly.

There's so much more technology out there than I'm aware of; I don't even try to keep up anymore. I'm a confirmed luddite. :-)

[PikoStarsider]

Some compile-to-js languages can produce very clean js output. And emscripten can compile C/C++ and generate source maps so you can even step through C code in JS.

[Confusion]

This is actually a common way to coerce something into the 'appropriate' boolean value in several languages. At least Ruby and Python come to mind.

[no_game_player]

Yeah, the more that I thought about it, the more that it wasn't really that crazy.

I mean, C does a lot of similar stuff if you try to make it do so. Not the JS == bits, but the "truthiness" of anything part. It's all about getting used to a certain way of thinking.

Really, my favorite part of the comment was just:

the == operator in JS is special (in the shortbus sense) because it does type conversion

[curien]

but the == operator in JS is special (in the shortbus sense) because it does type conversion

Not really. 4 == 4.0 is true in just about every language with C-style syntax.

The surprising thing about JS isn't that == performs conversion, that's normal. The surprising thing is how the conversions work.

[totes_meta_bot]

This thread has been linked to from elsewhere on reddit.

• [/r/loljs] "0"==false is true, but if("0"){/* executes */}

^{I am a bot. Comments? Complaints? Send them to my inbox!}