|
Comments inline. I'm glad to see integer division getting this level
of attention. Erik On 4/25/2013 11:12 AM, Matthieu Monrocq
wrote:
I like this a lot. Making "div" and "mod" operators instead of methods makes them proper, first-class citizens. It also makes them easy to use in math expressions, which is a big plus. It also makes them opt-in for developers expecting C-like behavior. This looks pretty good to me: let a = vec[idx mod len]; //safe if len > 0 let n = (k + 5) div 10; // precedence rules require parentheses, just like "/" I really don't like the [div/mod]_[floor/ceil] methods proposed on IRC. It makes the ones I care about - [div/mod]_floor - a second class citizen. Adding "mod" and "div" as operators doesn't feel that bad to me - these are important and useful, and should exist in a way that C developers can find them. Making them operators makes them highly discoverable. There are at least 6 different meanings of integer "divide". The IEEE-754 spec has 5 rounding modes, each of which maps directly to an integer div/mod rule:
Plus there's floating point division, which is fundamentally different from integer division. Floating point division sets q = D/d so that D = q*d ("modulo" part of the division equation is zero). It's very different -- but all the integer modes still make sense for floats, since floats can represent integers. I don't think it's a good idea to expose six (or seven) division operators (though maybe they should all be in a library somewhere). Truncate and floor are - by far - the most common integer modes, and cover the normal programming use cases. I don't think it is possible to come up with one short word that means both "rounded floating-point division" and "truncating integer division". Maybe just call it "div_sign_op" and have it call "quot" for integers and "float_div" for floats? Agreed. "%" and "/" should satisfy the division rule [D = d*(D/d) + (D%d)], which requires "%" to map to rem if "/" truncates. Being "close-to-the-metal" seems to be very important. In the case of division, it's not as clear-cut as "what does Intel's 'idiv' implement". "idiv" is only used for division when the denominator is not a compile-time constant. When "idiv" is used, T-division (C-style) is closer to the metal. (Note: no hardware divide on ARM, so no difference there.) But when the denominator is known at compile-time, it's transformed into a multiply (or a bitwise-and for power-of-two denominator). In both the "multiply" and "bitwise-and" algorithms, F-division is closer to the metal (fewer instructions needed, on average). In any case where the denominator is a constant, F-division is the same speed or faster (and that's a big percent of divides in a lot of code - especially performance-conscious code). [1]: https://biblio.ugent.be/input/download?func=downloadFile&recordOId=314490&fileOId=452146 or http://dx.doi.org/10.1145/128861.128862 |
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
