4 ms·

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 valu

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 4y 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 4y 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.

MrJohz 4y 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 4y 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.