Function return values in GMP? (James Wheaton)

[Hans Aberg]

On 3 Mar 2006, at 04:53, Décio Luiz Gazzoni Filho wrote:

>
> On Mar 2, 2006, at 3:35 PM, Hans Aberg wrote:
>
>> On 2 Mar 2006, at 17:08, Décio Luiz Gazzoni Filho wrote:
>>
>>> On Mar 2, 2006, at 10:21 AM, Hans Aberg wrote:
>>>
>>>> On 2 Mar 2006, at 00:33, Décio Luiz Gazzoni Filho wrote:
>>>>>
>>>>> Actually that is a well known problem with operator overloading  
>>>>> in C+
>>>>> + and which has been solved (though not 100% satisfactorily) using
>>>>> the technique of `expression templates', which by the way is
>>>>> implemented in the C++ wrapper for GMP.
>>>>
>>>> This does not solve the problem, because templates just provides  
>>>> a static (compile time only) programming
>>>
>>> Expression templates solve the problem for 99.9% of users.
>>
>> Please back this up with facts. :-)
>>
>
> What do you expect, a survey? All I can tell is that I've been  
> looking at the issue of arithmetic for some time already and you're  
> the first I see mentioning derived classes. I take that to mean the  
> rest of users are satisfied with the current situation.

Your comments are arrogant and ignorant.

> And as I can't see a real-world use for your idea either, I'd be  
> pleased if you could point out a piece of code from a real  
> application that benefits from your idea. I have gobs of code using  
> the GMP C++ wrapper to show in return.

Implementation of functional languages and other dynamic languages.  
You really do not know much programming, do you?

>>> Now certainly there are the hardcore abstract OO types who want  
>>> to do everything dynamically. Still, I don't see why it'd be  
>>> impossible to use expression templates and dynamic typing  
>>> simultaneously.
>>
>> It's only that it's wholly unnecessary. Once one starts with  
>> dynamoc programing there is littyle use and little point with  
>> templates.
>>
>
> Great, so tell me how your non-template-based code will convert the  
> code
>
> base_t *x, *y, *z;
> *x = *y + *z;
>
> to
>
> mpz_add(x,y,z);
>
> without generating any temporaries and without incurring runtime  
> overhead. It'd be a great revelation to me that it could be done  
> without templates. Certainly you can mimic the template-based  
> solution using an hierarchy of classes, but that has no clear  
> benefit yet has the drawback of runtime overhead.

The point is that in dynamic setting, one works with function  
pointers which cannot be converted using static compilation. So here,  
you have absolutely no idea of what you are speaking about.

>
>>> Meaning you could write code like this:
>>>
>>> ----------
>>> base_t* x = new derived_t;
>>> base_t* y = new derived_t;
>>>
>>> *x = *x + *y;
>>> ----------
>>>
>>> and get the correct behavior without temporary generation.
>>
>> And how do you get it into polymorphic class hierarchy? And when  
>> done, how does the virtual function class interface look like?
>>
>
> Certainly I won't bother to work out the low level details, because  
> the problem isn't interesting to me.

So if your uninterest makes you not really know anything about the  
issues involved, why bothering commenting about it all?

> However, consider code like this (lifted from gmpxx.h):
>
> struct __gmp_unary_plus
> {
>   static void eval(mpz_ptr z, mpz_srcptr w) { mpz_set(z, w); }
>   static void eval(mpq_ptr q, mpq_srcptr r) { mpq_set(q, r); }
>   static void eval(mpf_ptr f, mpf_srcptr g) { mpf_set(f, g); }
> #ifdef __MPFR_H
>   static void eval(mpfr_ptr f, mpfr_srcptr g, mp_rnd_t mode)
>   { mpfr_set(f, g, mode); }
> #endif
> };
>
> Suppose the mpz_t type were a C++ object, so that you would write  
> code like this:
>
> mpz_t *z, *w;
> z->set(w);
>
> instead of
>
> mpz_set(z, w);
>
> Writing code like this
>
> struct __gmp_unary_plus
> {
>   static void eval(mpz_t* z, const mpz_t* w) { z->set(w);  }
>   ...
> };
>
> and so on would allow you to plug in any derived type of mpz_t in  
> place of mpz_t and it would work out. Of course you still need  
> expression templates to avoid temporary generation, hence a purely  
> non-template-based solution isn't possible. Unless of course you  
> can answer my challenge above, but I'm not holding my breath.

It's not about static derived types, but dynamic such. This is sort a  
major feature of the C++ language, introduced well before templates,  
which the latter does not replace. So your stuff is completely  
irrelevant. You need to learn about dynamic programming in order to  
understand these issues, and be able to produce relevant comments.

>
>>> Of course, it'd require some modifications from, say, the C++ GMP  
>>> wrapper in order to generalize it, but it's possible. Now writing  
>>> code where the expressions themselves are generated at runtime,  
>>> say a calculator parsing user input, might indeed not work -- I  
>>> haven't thought enough about it to be sure.
>>
>> So it seems. :-) Why don't you try it? :-)
>
> Because I have no need for it,

So then why bother commenting about it, when you have absolute no  
idea of the issues involved?

> and in fact I'm waiting to see whether *you* have a need for it,  
> such that your technique made more sense than the way it's already  
> done in the C++ wrapper.

Dynamic programming is used to be able to do things that cannot be  
done with a primitive static template system. One example are more  
general recursive data types. Used in the implementation of  
programming languages and such, of which you apparently do not know  
anything about, and for some reason have termed uninteresting. What  
are you using in your programming, if not programming languages? It  
seems to be an important issue. :-)

Apart from that, a static class interface has the advantage of being  
easier to program, so it can be used speed up programming, then  
optimizing relevant parts at need. The standard programming approach.

Taken these issues apart, I do not see the immediate need for a C++  
class interface to become a part of the GMP package, as there are  
more than one way to do it. The current primitive C++ template  
package has the advantage to being able to be fully optimized away  
from by the compiler, so its use will not disturb GMP efficiency.

   Hans Aberg