Re: [boost] c2_functions templates

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2006-03-26 18:49:12

Marcus Mendenhall wrote:

>> Message: 11
>> Date: Sun, 26 Mar 2006 13:37:11 -0500
>> From: Neal Becker <ndbecker2_at_[hidden]>
>> Subject: Re: [boost] more thoughts on c2_functions
>> To: boost_at_[hidden]
>> Message-ID: <e06n0n$hr1$1_at_[hidden]>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Marcus Mendenhall wrote:
>>
>>> I have started trying to templatize c2_functions, but I have a
>>> question for the Boost group.  Realistically, this class is fairly
>>> meaningless for anything other than double and long double types.  I
>>> also have a long, enduring distaste for c++ templates and, as a
>>> result, little deep competence with them.  The process of making it
>>> into working template classes which are also fairly easy to use will
>>> be very slow for me.  For the 99% of users who will always use this
>>> with double, also, the need to declare every items with <double>
>>> after it, or even with <> for things which can be defaulted, is ugly
>>> and will likely reduce the user base.
>>>
>>> Would it be objectionable to the Boost concept to release a basic
>>> version of the which is strictly for doubles, with the knowledge
>>> that, for the few people who want it for long doubles, this can be
>>> done with a global search & substitute, and then to plan later for a
>>> successor to this which is fully templatized?
>>>
>>> I see this as a package which, in its current, template-free form,
>>> can be essentially spun off except for improving the documentation.
>>> The algorithms in it are simple and robust, and the code should be
>>> highly portable, so I doubt it will every need much maintenance.  I
>>> think there is a fairly decent reason to make it available soon,
>>> since there appears to be a significant need for it, and to learn if
>>> real users need it structured differently.
>>>
>>
>> You've come to the right place.  Here are the template experts.
>> Instead of
>> "release" without template support, why not collaborate with
>> someone to
>> help with the process?
>>
>> ** It's not just the data types that you would want to be generic.
>> It's the
>> containter types as well.  There are hard-coded instances of
>> std::vector,
>> for example.  From what I've seen in this code, fixing this aspect
>> is easy.
>>
>>
> Is that the sound of a volunteer I just heard :-)  I would love to
> have someone collaborate on the template generation.
> 
> I noticed the comment about containers earlier.  In almost every case
> where I use std::vector, the data _really should be_ in an object
> with most of the detailed semantic behavior of a vector, since they
> are meaningful when defined as an ordered set with an integer index.
> Is there a compelling reason why more general containers are wanted?
> This, of course, nests the templatization even deeper, and thus makes
> the most common usage even harder.  I know another commenter on this
> thread suggested defining the general template version of the class,
> and then generating shadow classes of every class in it with the
> templates already spelled out.  I thought about this before, and it
> seems to me to be a nightmare, since one has to maintain a list of
> all the specific instances of the general classes.  Although I would
> be willing to do it this way (if someone helps with the template
> generation in the first place), it isn't beautiful to me.  Or am I
> missing a way to generate templates of everything at once (again, I
> am not a templates guru or even much more than a terrible template
> novice.  The numerics are my specialty.)
> 

If the container is used internally to your algorithm, then use whatever you
like.  The issue is when you impose your choice on your users. 

 double partial_integrals(
                             std::vector<double> xgrid, std::vector<double>
*partials = 0,
                             double abs_tol=1e-12, double rel_tol=1e-12, 
                             int derivs=2, bool adapt=true, bool
extrapolate=true);
 
Is there any good reason xgrid should be any particular type?  If all you
want to do is read the values, you can use a more general interface.  My
preference is to use boost::range.

template<typename out_cont_t, typename grid_cont_t>
T partial_integrals (out_cont_t& out, grid_cont_t const& xgrid,...)

Now the user can use whatever container types they like.  Maybe they want to
use boost::numeric::ublas::vector.  Maybe they want to use plain old C
array.

If you want help with replacing hard-coded containers, yes, I will try to
help.  I don't have the expertise of others on this list, but this issue is
pretty easy (I think).

If we want to replace the data types "double" in functions with a template
parameter, yes, that's also easy.

If we want to consider more general genericity, that might be harder.  For
example, we can consider a function with independent argument types and
return value types.  Then we will need to consider the computation (compile
time) of what types result in various situations.  This coding is more
difficult, (but possible).

I have some experience with this, but maybe some others could help.  OTOH, I
don't think we need to consider such generalities in this case.  The
functions we are considering here are only single argument, and are there
is no obvious reason for the return type to differ from the argument type,
is that correct?