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

Gregor Cramer remarcg at gmx.net
Fri Jul 25 12:36:22 PDT 2014


> > 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).
> 
> Hum, I would almost strongly disagree  I would even go as far as
> saying that you won't develop any kind ...

How can you disagree about what I'm doing?

> Well, I guess you did nothing but C++ in the last 30 years then?
> Because I can't recall many languages that would allow this sort of
> thing. How would C# and Java's Math::Pow() would work out in this
> case? How would it work out in C? How would it work out in Python,
> JavaScript, etc... the list is ... quite long.

I don't care about the capabilities of other languages, I don't use a
language if it is not appropriate.

> The question is always about compromise. Shall rust include a language
> feature to make some things easier for the sake of introducing tons of
> problems as well?

No. Everyone is talking about tons of problems, but which ones?
The most problematic language, with tons of problems, is C++.
But even in C++ not overloading is the problem - and I have about
20 years experience with C++ - it is for example, to name just one,
the implicit casting, because this makes overloading a bit problematic.

> Java is about the least expressive language we have at the time
> (appears a bit like the greatest common denominator of all imperative
> languages) and I would say only few people are out there who would say
> that you can't do proper software design with it.

This depends on how your are doing software design. Impossible
for me to use Java.

> It might not be a
> concise and pleasing as "GOOD C++ design is", but then again "GOOD C++
> design" is very hard to archieve and thus begs the questions if it is
> even worth it to make a language that complicated so that magnificient
> (academic) design is possible at the cost of making the average
> (industrial) design horrible.

I cannot see that overloading is horrible or complicated. It's another
point that C++ is horrible and complicated. We have 2014, as I started
with C++ it was the superior language, but software design has evolved,
nowadays object oriented design is obscure, and that's in fact
my own experience. But C++ already supported one ingenious feature:
generic programming (but very low level).

> > pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T;
> 
> I agree this definition appears to be very strange to me. In more than
> one way. First it implies that the existing implementation works by
> somehow multiplying types with the expontential trick " a * a = b, b *
> b = c, c * c = a^6" etc...
> This is an unacceptable restriction for me, as this kind of evaluation
> might not be the best in many cases and we are talking about a
> standard library function after all. It should always allow the BEST
> implementation, not just some implementation.
>
> Here we clearly need a better concept. And this concept needs to be
> designed & defined. And you could start by doing this, instead of just
> giving up ;).

This means that I have to design at a lower level, before I start to implement
the big number library. Probably I'll try it, I don't know yet. I don't know
yet whether I will really use Rust. (BTW: "I gave up at all" does not mean
forever, please be aware that I'm not a native English speaker.)
In fact I'm looking for an alternative to C++, and Rust is still the most
promising one, but Rust is not yet elaborated (I know that Rust is still
pre-alpha).

> And overlaoding is not a great concept in general, IMO.
> What Rust could do is copy template specialization. So that I can say:
>
> pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T; //
> uses the exponential trick
>
> pub fn pow<i64>(mut base: i64, mut exp: uint) -> i64; // uses some
> cool processor features if available
>
> pub fn pow<BigInt>(mut base: &BigInt, mut exp: uint) -> BigInt; //
> uses some mighty algorithm that is not naive 

Yes, that would possibly be one solution for overloading, Unfortunately
the problem with the signature remains. It's absolutely clear for me
that an overloading feature should not cause problems, this means
that a design is required which suits perfectly with the principle design
of Rust.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140725/95e472a4/attachment.html>


More information about the Rust-dev mailing list