math/tools/rational.hpp gcc 3.2 problem

gcc 3.2 doesn't compile this code (works with gcc 3.3 and up): #include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; } Reduced: template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val) { return val * a[0] * static_cast<T>(N); } int main() { double a[3]; double val; double result = evaluate_polynomial(a, val); return static_cast<int>(result); } dbg2.cpp: In function `int main()': dbg2.cpp:12: no matching function for call to ` evaluate_polynomial(double[3], double&)' Does anyone have an idea for working around the problem? Ralf

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Ralf W. Grosse-Kunstleve Sent: Thursday, October 08, 2009 5:55 PM To: boost@lists.boost.org Subject: [boost] math/tools/rational.hpp gcc 3.2 problem
gcc 3.2 doesn't compile this code (works with gcc 3.3 and up):
#include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; }
Reduced:
template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val) { return val * a[0] * static_cast<T>(N); }
int main() { double a[3]; double val; double result = evaluate_polynomial(a, val); return static_cast<int>(result); }
dbg2.cpp: In function `int main()': dbg2.cpp:12: no matching function for call to ` evaluate_polynomial(double[3], double&)'
Does anyone have an idea for working around the problem?
It looks as though compliance testing was done with Linux GNU C++ 3.4 (performance was done with Cygwin G++ 3.4 - and John Maddock notes that 4. optimises much better). So sorry but I don't have any suggestions - apart from using gcc 3.3 or up ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

Hi Paul,
So sorry but I don't have any suggestions - apart from using gcc 3.3 or up ;-)
Thanks very much for looking. In the meantime, I simply disabled the students_t distribution code if compiling with gcc 3.2. After checking with the original author it turns out to be a non-critical feature, at least for now. (Long-term we'll drop gcc 3.2 support.) Ralf

On Fri, Oct 9, 2009 at 5:55 AM, Ralf W. Grosse-Kunstleve <rwgk@yahoo.com>wrote:
gcc 3.2 doesn't compile this code (works with gcc 3.3 and up):
#include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; }
Reduced:
template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val)
I will be wrong linguistically, but I hate the definition of 'a' here. What is it to be? I assume it is a reference to an array, I guess. But then why not just take a reference to the first element and a count, or use a range (pointer + size)? Sorry, I don't know anything about boost/math/distributions. But this kind of non-problem being a problem is in fact, a problem. If 'a' is just an array, say it like it is. Why make a fuss? Christian

Sorry, missed the point about taking a const array by reference. On Thu, Oct 15, 2009 at 1:15 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
On Fri, Oct 9, 2009 at 5:55 AM, Ralf W. Grosse-Kunstleve <rwgk@yahoo.com>wrote:
gcc 3.2 doesn't compile this code (works with gcc 3.3 and up):
#include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; }
Reduced:
template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val)
I will be wrong linguistically, but I hate the definition of 'a' here. What is it to be? I assume it is a reference to an array, I guess. But then why not just take a reference to the first element and a count, or use a range (pointer + size)?
Sorry, I don't know anything about boost/math/distributions. But this kind of non-problem being a problem is in fact, a problem.
If 'a' is just an array, say it like it is. Why make a fuss?
Christian

gcc 3.2 doesn't compile this code (works with gcc 3.3 and up):
#include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; }
Reduced:
template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val)
I will be wrong linguistically, but I hate the definition of 'a' here. What is it to be? I assume it is a reference to an array, I guess. But then why not just take a reference to the first element and a count, or use a range (pointer + size)?
Sorry, I don't know anything about boost/math/distributions. But this kind of non-problem being a problem is in fact, a problem.
If 'a' is just an array, say it like it is. Why make a fuss?
Because it makes a difference, both for maintenance and performance: * For maintenance, we're much less likely to introduce subtle bugs if the function "knows" how big the array is, rather than us having to specify the size at the call site, as well as at the definition of the array. * For performance: for small arrays of known size we can omit the for-loop and just evaluate the polynomial using near-optimal code. Since polynomial/rational function evaluation is often the pinch-point for functions implemented using rational-approximations it makes sense to optimize this as far as possible even if it only gains us 20-30%. We could of course code the polynomial evaluation separately each time it's needed - and without a separate function - that's what most other similar libraries do, but as well as being untidy, it precludes library wide improvements to this core function, unless of course you change every usage :-( As for the original problem: I'm afraid I don't have an obvious workaround that springs to mind, I will try and install an early gcc version to test with, but last time I tried you can't even *build* gcc-3.x on recent Linux builds :-( John.
participants (4)
-
Christian Schladetsch
-
John Maddock
-
Paul A. Bristow
-
Ralf W. Grosse-Kunstleve