4 ms·
Interpreting “in” as “is an element of”, all of these are type errors. It only makes sense to ask if an X is in an Array<X>. In a language that lets you ask non
by bo1024 4y ago
Interpreting “in” as “is an element of”, all of these are type errors. It only makes sense to ask if an X is in an Array<X>. In a language that lets you ask nonsense questions, expect nonsense answers.
- kzrdude 4y agoNumpy has the highly useful operation of `a < b` where a and b are arrays and the answer is an array of booleans - i.e broadcasted elementwise compare. They changed the language to change what question `<` asks.
- bo1024 4y agoSure, and languages like C++ let you do this kind of thing very broadly, but it has a lot of pitfalls. One of my biggest gripes with python is that function interfaces and "type signatures" are hard to discover even when documentation is good.
- kzrdude 4y agoFWIW I think it's very hard to discover this from C++ code as well. It has to be documented.
- kevin_thibedeau 4y agoThis gets ugly with !=. Instead of 'a != b' you usually want 'not (a == b).all()'.
- cuteboy19 4y agoIt really doesn't if you think about it. a==b cannot by itself be used as an if condition. You would always need to use (a==b).all(). So it would be very difficult to make the mistake you are suggesting https://stackoverflow.com/questions/10062954/valueerror-the-truth-value-of-an-array-with-more-than-one-element-is-ambiguous https://stackoverflow.com/questions/10062954/valueerror-the-...
- IshKebab 4y agoI think the general point is that it was a bad idea to implement the operators as elementwise because it breaks all of the properties they are supposed to hold. Really there should be separate elementwise operators like `.>` and so on but you can only do that in some languages.