3 ms·

It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safet

by MrJohz 5y ago

It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safety of the language, and more to do with the IEEE 754 spec on floating point numbers. For example, `math.nan + 1` in Python should equal NaN as well. While NaN technically is a kind of null, it's one embedded in the spec for floating point numbers, and therefore present in every language that uses them, including far safer languages like Rust. It's also worth noting that neither language has the behaviour described in this article, which is that doing anything to a null (not NaN) value returns a new null value. In Python, there are a handful of allowed operations on `None` (such as converting it to a string), and everything else will return an error. Javascript is somewhat more lenient, in that it allows type coercion, so in a numeric context, `null` will first be converted to 0, and `undefined` will first be converted to NaN. Likewise, in the presence of other strings, these values will be coerced to string values. However, if you attempt to access attributes on these objects, call methods on them, or pass them to methods that don't accept null values, then they will throw errors. This is the big difference to a language like Objective C.

deltaonefour 5y ago
Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.
- MrJohz 5y ago
  Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).
  - deltaonefour 5y ago
    >Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. It returns NaNs in absurdly unused mathematical operations like: x=float('nan') x = float("inf") * 0 Javascript returns it on any math operation on an 'undefined' which is another bad value likely to occur in JS. It basically never happens in practice for python. Yes python will propogate a NaN but the operations that instantiate a NaN are so absurd and rare that effectively NaNs aren't used or ever encountered in python. I personally use floating point infinite to create initializer values that are always greater then everything else for algos involving min, but effectively I've basically never seen infinite used in code either. There is a hole here in that one day I may encounter the NaN because as shown above... usage of infinite is one of the ways to generate a NaN, but again this is so rare that effectively it never happens. I am not confused. I believe you're just getting a bit pedantic.

by MrJohz 5y ago

deltaonefour 5y ago

Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.

MrJohz 5y ago
Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).
- deltaonefour 5y ago
  >Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. It returns NaNs in absurdly unused mathematical operations like: x=float('nan') x = float("inf") * 0 Javascript returns it on any math operation on an 'undefined' which is another bad value likely to occur in JS. It basically never happens in practice for python. Yes python will propogate a NaN but the operations that instantiate a NaN are so absurd and rare that effectively NaNs aren't used or ever encountered in python. I personally use floating point infinite to create initializer values that are always greater then everything else for algos involving min, but effectively I've basically never seen infinite used in code either. There is a hole here in that one day I may encounter the NaN because as shown above... usage of infinite is one of the ways to generate a NaN, but again this is so rare that effectively it never happens. I am not confused. I believe you're just getting a bit pedantic.