On Tue, Jun 17, 2014 at 1:26 PM, SiegeLord wrote: > On 06/16/2014 07:03 PM, Sebastian Gesemann wrote: >> >> Good example! I think even with scalar multiplication/division for >> bignum it's hard to do the calculation in-place of one operand. > > Each bignum can carry with it some extra space for this purpose. > >> Suppose I want to evaluate a polynomial over "BigRationals" using >> Horner's method: >> >> a + x * (b + x * (c + x * d)) >> >> What I DON'T want to type is >> >> a + x.clone() * (b + x.clone() * (c + x.clone() * d)) > > But apparently you want to type > a.inplace_add(x.clone().inplace_mul(b.inplace_add(x.clone().inplace_mul(c.inplace_add(x.clone().inplace_mul(d))))))
No, it's more like a + x * (b + x * (c + x * d))) At least when a,b,c,d are parameters I continue to use and want not moved from. And even if I want to use a,b,c,d only once, I don't need to clone x all the time. No idea what made you write this. > Because that's the alternative you are suggesting to people who want to > benefit from move semantics. The difference is that the short operator-based expression *works* right now whereas forcing a "moving self type" on to people makes this expression not compile for types that are not Copy. So, given the two options, I actually prefer the way things are right now. Of course, I'm not really 100% happy with it. But it's simple. And there is only so much you can do without overloading. I think, to convince people (either way) a deeper analysis is needed. What implementation techniques are possible? (e.g. extra buffers) What's the distribution of the different use cases? (How often does one need a single value more than once?). If we can believe the guys who invented the Mill CPU architechture, about 90% of the values computed are only consumed once (I think this was mentioned in the "Belt" talk). This, for example, does not make the "moving self parameter" look that bad. > Why would you deliberately set up a situation > where less efficient code is much cleaner to write? Because it's simple and allows the short expression to compile in *every* use case (even for non-Copy types). > This hasn't been the > choice made by Rust in the past (consider the overflowing arithmetic getting > sugar, but the non-overflowing one not). Rust also tries to stay simple and does not try to support every feature C++ has (e.g. overloading on different kinds of references). Cheers! On Tue, Jun 17, 2014 at 1:26 PM, SiegeLord <slab...@aim.com> wrote: > On 06/16/2014 07:03 PM, Sebastian Gesemann wrote: >> >> Good example! I think even with scalar multiplication/division for >> bignum it's hard to do the calculation in-place of one operand. > > > Each bignum can carry with it some extra space for this purpose. > > >> >> Suppose I want to evaluate a polynomial over "BigRationals" using >> Horner's method: >> >> a + x * (b + x * (c + x * d)) >> >> What I DON'T want to type is >> >> a + x.clone() * (b + x.clone() * (c + x.clone() * d)) > > > But apparently you want to type > > a.inplace_add(x.clone().inplace_mul(b.inplace_add(x.clone().inplace_mul(c.inplace_add(x.clone().inplace_mul(d)))))) > > Because that's the alternative you are suggesting to people who want to > benefit from move semantics. Why would you deliberately set up a situation > where less efficient code is much cleaner to write? This hasn't been the > choice made by Rust in the past (consider the overflowing arithmetic getting > sugar, but the non-overflowing one not). > > -SL > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
