Hacker News Reader

Comment by mattdeboard | Hacker News Reader

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.

View on HN

It 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.

I would say the (bigger) problem is in JavaScript randomly calling toString on things, especially when you're calling parseInt on a number already.

Generally type coercion seems like a bad idea in most languages

Which is why you can use === to bypass type coercion when dong an equality test.

But === is the other equals, not the equals.

Also, that only helps in boolean contexts, not with any function calls.

Also, that only helps in boolean contexts, not with any function calls.

Could you clarify?

'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.

It's not arbitrary, in fact the IEEE give their reasons in a FAQ [1].

1. http://grouper.ieee.org/groups/754/faq.html#exceptions

that 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.

this wouldn't actually solve the problem for base 36, though.

Actually it would break on the space character.

that's why i included a space character :D.

If 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.

Reply on news.ycombinator.com