Javascript comparisons be crazy
-
Yes, yes, I know that we all already know about how fucked Javascript's type coercion is. But this is a recent discovery that really got to me.
0 >= null true 0 > null false 0 == null false (0 > null || 0 == null) false
So, 0 is greater than or equal to null, but it's also neither greater than or equal to null.
Filed under: I can't even.
-
Wait...what? In what context did you run across this nifty gem?
-
Chrome Dev console. Basically everything except == coerces null to be zero.
0 <= null
is also true.
-
-
Shit, sorry, that doesn't actually answer the question that you asked. Basically it was a generic sort algorithm. I'll update with more info when I'm not on my phone and if I remember.
-
There is different logic/algorithms for Relational Equality( >= , <=) and Equality(== , !=)
In relational equality "null" is evaluated as a number
x = null ToPrimitive(x, hint Number) // +0 (0 >= null) === (0 >= (+0)) true true
And the algorithm for equality operators return true for
null == something
only when
null == null
null == undefined
undefined ==nullref: ECMA-262
-
So, in a nutshell it was something like this (from memory, still on my phone, and slightly intoxicated, please keep all of that in mind)
(l,r) => { if(l == r) return 0; else if (l > r) return 1; else return -1; }
L and r should be the same types, but they could also be null. We ran into a very weird sorting bug that brought this to light.
-
I don't know what you were expecting
(0 > null || 0 == null)
to be after already establishing that both0 > null
and0 == null
were false.But
0 >= null
being true definitely makes one go WTF. Even more so, if the others are false.@Monarch is correct:
â—€ null > -1 â–¶ true â—€ null > 1 â–¶ false â—€ Number(null) == 0 â–¶ true â—€ +null â–¶ 0 â—€ Math.pow( null, 1 ) â–¶ 0 â—€ Math.cos( null ) â–¶ 1
This was a dumbass move by whoever thought this should be the bevahiour. It's not even consistent with these:
â—€ parseInt( null ) â–¶ NaN â—€ parseFloat(null) â–¶ NaN
At least
undefined
doesn't seem to have this problem.
-
Array(16).join("wat" - 1) + " Batman"
-
I don't know what you were expecting (0 > null || 0 == null) to be after already establishing that both 0 > null and 0 == null were false.
Javascript.
-
Null is a special case in every programming language that supports it. If you allow null values but don't account for comparison cases then....um....blame the language?
Is 3 greater than elves ?
Is infinity equal to or more than water?
Is poop less than slippery?The answer to all these questions is "Maybe, but no or perhaps. (I wasn't ready for this test.)".
-
Not something like
IncompatibleTypeException
?
-
-
That, or NULL_NOT_FOUND
-
SQL does it sensibly. Null combined with anything is null. Null compared with anything is false.
-
Agreed.
-
-
Except when the null and the something else are from different table rows.
> SELECT A FROM TEST; 1 NULL > SELECT SUM(A) FROM TEST; 1
I've had to explain that one to colleagues several times.
-
Depends on the amount of fiber in your diet.
but what if an elf has a slippery poop in infinite water?
Does the fiber intake matter?
-
This from the language that thinks
typeof NaN == "number"
is a good idea? I am shocked and appalled.
-
Except when the null and the something else are from different table rows.
SQL sum ignores null values.
If your table only has rows with null in them, sum(A) returns null, because there's nothing there.
You don't get 0 back.
-
SQL sum ignores null values.
If your table only has rows with null in them, sum(A) returns null, because there's nothing there.
You don't get 0 back.Which isn't quite what blakey said...
-
SQL sum ignores null values.
If your table only has rows with null in them, sum(A) returns null, because there's nothing there.Read the rules again, they are very simple:
Null combined with anything is null. Null compared with anything is false.
Now think about what the "sum()" operation does. Think hard.
EDIT: Oh wait, I think I see what you're trying to say using your rudimentary caveman-like communication skills.
You're trying to say that the "sum()" operation ignores the rules, therefore the rules aren't as simple as I said. And you expressed it using the worst possible example possible ever. Yeah, that's true. Fair enough.
-
You're trying to say that the "sum()" operation ignores the rules, therefore the rules aren't as simple as I said. And you expressed it using the worst possible example possible ever. Yeah, that's true. Fair enough.
No, I'm actually saying the rules are as simple as you said.
SUM in SQL simply doesn't look at nulls, so if you have a table with the values (1, null, 4), SUM only sees (1, 4); null is not there so it it neither compared with or combined with anything. It's the same with MIN and MAX.your rudimentary caveman-like communication skills.
Yes, I'll admit they are pretty bad.
-
No, I'm actually saying the rules are as simple as you said.
Oh. Sorry then.
SUM in SQL simply doesn't look at nulls, so if you have a table with the values (1, null, 4), SUM only sees (1, 4); null is not there so it it neither compared with or combined with anything. It's the same with MIN and MAX.
You could argue that "sum(1, null, 4)" behaving different than "1 + null + 4" is a confusing inconsistency. Which is what I thought you were doing. I could see it either way.
-
-
The null rules blakeyrat mentioned are the rules for expressions in SQL. SUM is an aggregate function rather than an expression and those have different rules.
-
That's really surprising.
that 12 people have clicked on the link
-
SQL does it sensibly. Null combined with anything is null. Null compared with anything is false.
Which is the same as the IEEE 754 NaN rules; however, in the broader worlds they live in, IEEE NaNs are far more useful/sensible than the atrocity that is SQL NULL.
*busts out a Codd*