[rust-dev] std::num::pow() is inadequate / language concepts

Jason Fager jfager at gmail.com
Fri Jul 25 07:05:34 PDT 2014


For the specific issue of exponentiation, you might be interested in
https://github.com/rust-lang/rfcs/pull/172



On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer <remarcg at gmx.net> wrote:

>  Hi Marijn,
>
>
>
> > Firstly, blanket statements like "This makes generic programming
>
> > impossible" and "it does not allow proper software design" are
>
> > unneccesary hyperbole, and do not help the discussion in any way.
>
>
>
> You're not right, my statement wasn't blanket, it was my result
>
> after I tried to overwork the big integer library, and I have mentioned
> this:
>
> I gave up at all. (I'm doing software design and implementation since
>
> more than 30 years, and I never accept compromises, this is the way
>
> how to develop magnificient software).
>
>
>
> > Traits provide a more well-defined, easier to reason about alternative
>
> > to overloading. They do require the author of an algorithm to decide
>
> > ahead of time whether this algorithm needs to be specializeable, which
>
> > I guess C++-style overloading does not.
>
>
>
> Yes, the traits are great, I'm impressed, as I said before, and in fact
> Rust
>
> is really great, despite a few facts, otherwise I wouldn't subscribe to
>
> this mailing list. And my goal is to be constructive, don't worry if I'm
>
> a bit euphoric, such things happens. Nethertheless, it gave up to overwork
>
> the big integer libary because I cannot specialize std::num::pow(). There
> is
>
> no way to proceed with a proper design.
>
>
>
> > Whether that is a good or a
>
> > bad thing is debatable, but it is not true that Rust lacks a feature
>
> > for specialization.
>
>
>
> There is a lack in the current language concept, std::num::pow()
>
> is inadequate due to this language concept, and std::num::pow() is
>
> only one example for this fact.
>
>
>
> I will repeat the problem with signatures. Currently pow() is declared
>
> as following:
>
>
>
> pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T;
>
>
>
> That't 100% ok. The user will call this function in this way:
>
>
>
> pow(a) // a is i32
>
>
>
> Perfect. Now I need a specialized function for BigInt:
>
>
>
> [#overload]
>
> pub fn pow(base: &BigInt, mut exp: uint) -> T;
>
>
>
> There's a problem (beside the missing overloading feature): the
>
> specialized version requires a reference. Same problem if I'm
>
> calling this function:
>
>
>
> pow(&a) // a is BigInt
>
>
>
> The user has to know how to call a function, depending on the type.
>
> But a proper function specialization would be:
>
>
>
> [#overload]
>
> pub fn pow(base: BigInt, mut exp: uint) -> T;
>
>
>
> And so the function call is as expected, like with other numeric types:
>
>
>
> pow(a) // a is BigInt
>
>
>
> But there is now a problem in this function definition, BigInt is given as
>
> a copy, and this is a software design issue (superfluous memory
> allocation).
>
> And this currently happens if the user is calling std::num::pow() with a
>
> numeric type like BigInt (apart from other performance penalties in pow()).
>
>
>
> That's what I've mentioned that the compiler should decide whether an
>
> argument is given by reference or by value. In this way the latter approach
>
> works. And in the case that a function willl modify an argument (in-out
>
> value), for example:
>
>
>
> fn mul_vec(acc : &mut [BigDigit], base: &mut [BigDigit], mut exp:uint)
>
>
>
> the call of this function would be:
>
>
>
> mul_vec(&a, &b, exp)
>
>
>
> This concept will not change, because here it has to be clear that an
> argument
>
> will be changed (furthermore the compiler should give a warning if a
> function
>
> is not changing a mutable argument). I think that this approach is even
>
> superior to the 'const' concept of C++, and it fit's with the great overall
>
> concept of Rust (especially with the owner/borrower concept).
>
>
>
> I try to show the problems if function specialization (overloading) is not
>
> supported. A stable software design is problematic. Adding a new module,
>
> which will use existing function declarations, is impossible in some cases.
>
> Currently I cannot implement a specialized version of pow() for BigInt,
> adding
>
> a new function for a different numeric type is only a hack, and moving this
>
> function into a trait is not solving the general problem, because pow() is
>
> only one example. (Beside: it's not my decision to move pow() into a
> trait.)
>
>
>
> Cheers,
>
> Gregor
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140725/e8f8f8c4/attachment.html>


More information about the Rust-dev mailing list