Message: 11 Date: Sun, 26 Mar 2006 13:37:11 -0500 From: Neal Becker <ndbecker2@gmail.com> Subject: Re: [boost] more thoughts on c2_functions To: boost@lists.boost.org Message-ID: <e06n0n$hr1$1@sea.gmane.org> 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.) Thanks. Marcus Mendenhall
Marcus Mendenhall wrote:
Message: 11 Date: Sun, 26 Mar 2006 13:37:11 -0500 From: Neal Becker <ndbecker2@gmail.com> Subject: Re: [boost] more thoughts on c2_functions To: boost@lists.boost.org Message-ID: <e06n0n$hr1$1@sea.gmane.org> 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?
participants (2)
-
Marcus Mendenhall -
Neal Becker