5 ms·
Contrary to what some people may think, this is non-obvious & surprising behavior which has nothing to do with JS being a "dynamic language". It requires knowin
by mattdeboard 14y ago
Contrary to what some people may think, this is non-obvious & surprising behavior which has nothing to do with JS being a "dynamic language". It requires knowing that the IEEE floating point standard arbitrarily defines 1/0 as positive infinity instead of being (the more widely accepted, obvious and unsurprising) undefined value. I believe JS is a powerful language but calling this reasonable behavior smacks of Stockholm Syndrome.
- lifthrasiir 14y agoIt is mainly related to the fact that parseInt in JS slightly converts a positive infinity to a string "Infinity". Base 19 does not add anything to the humor. And well, neither does the presence of a positive infinity itself. So yes, this is nothing to do with JS being a dynamic language (which main feature is not a variable/slot but a value having a type), but it's something to do with it being a weakly typed language (which main feature is an implicit and generally unpredictable type conversion). Of course many popular dynamic languages are still strongly typed in this sense.
- ibotty 14y agothat js implements the floating point standard is not js' fault. but that parse("1something unreasonable", 2) == 1 is just wrong. it should generate an exception.
- esbwhat 14y agothis wouldn't actually solve the problem for base 36, though.
- brohee 14y agoActually it would break on the space character.
- ibotty 14y agothat's why i included a space character :D.
- batista 14y agoIf the string only had base 36 digits (ie not a space as above), then it wouldn't be a problem, it would a perfectly fine conversion from base36 string to base10 number.
- lucian1900 14y agoI would say the (bigger) problem is in JavaScript randomly calling toString on things, especially when you're calling parseInt on a number already.
- VMG 14y agoGenerally type coercion seems like a bad idea in most languages
- chris_wot 14y agoWhich is why you can use === to bypass type coercion when dong an equality test.
- lucian1900 14y agoBut === is the other equals, not the equals. Also, that only helps in boolean contexts, not with any function calls.
- chris_wot 14y agoAlso, that only helps in boolean contexts, not with any function calls. Could you clarify?
- lucian1900 14y ago'1' === 1 is false, because === is strict. But there's no strict equivalent of + or -, so '1' + 1 is '11', but '1' - 1 is 0. The same holds for parseInt('Ambulance', 16) and parseInt('A', 16), which are both 10.
- chris_wot 14y agoIt's not arbitrary, in fact the IEEE give their reasons in a FAQ [1]. 1. http://grouper.ieee.org/groups/754/faq.html#exceptions http://grouper.ieee.org/groups/754/faq.html#exceptions