4 ms·
The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.
by ufo 10y ago
The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.
- wyldfire 10y agoI don't think you're correct. If you, the designer, made those operands, you should expect them to be int() or float() because of how you created them. int() and float() have lots of other differences beyond just how they're treated by division.
- Thrymr 10y ago"you, the designer" may not have created the operands, just taken them as function arguments. Sure, you should have written tests for different types of input, but if you didn't, it may surprise you later.
- klodolph 10y agoIn my experience, at some point someone will write f(x, 2) instead of f(x, 2.0). This especially happens when you are trying to debug something at the REPL. The addition of the // operator has really solved the problem and given us the best of both worlds here.
- x0x0 10y agoThe SymPy author was explicitly talking about users. The sort of folks that use matlab, mathematica, and maple. I don't know of any of them that expect 2 / 3 to be an integer. And as ufo says, it creates subtle bugs because it works right on most data until you just happen to get a pair of ints. Then boom. eg in Matlab all numbers are doubles unless you take action to make them otherwise.
- nomel 10y agoHaving a function/operator return different results depending on the type seems a bit insane, from a non-C/Python perspective. > There should be one-- and preferably only one --obvious way to do it. If I divide 1 in half, I'm left with 0.5.
- dwc 10y agoThere's a better way. (/ 2 3) ; => 2/3 (/ 2.0 3) ; => 0.6666667