I have a class called Universe. The class includes a member function to calculate distance and requires numerically integrating an ugly looking function. I was trying to use GSL to perform the integration but I get the following error when I attempt to compile the library -
$ g++ -c -O3 -std=c++11 Universe.cpp -o Universe.o
$ error: cannot convert ‘Universe::Hz’ from type ‘double (Universe::)(double, void*)’ to type ‘double (*)(double, void*)’
Here's the class Universe without the constructors (for brevity):
Universe.h
#ifndef UNIVERSE_H
#define UNIVERSE_H
#include <cmath>
#include <gsl/gsl_integration.h>
using namespace std;
class Universe {
private:
static constexpr double c = 299792458.0, Mpc2Km = 3.08567758e+19, Yrs2Sec = 3.15569e7;
double H0 = 67.77, OmegaM = (0.022161+0.11889)/(H0*H0), OmegaL = 0.6914, OmegaG = 8.24e-5, OmegaK = 0.0009;
double Ez(double z);
double Hz(double z, void* params);
public:
double distH, timeH;
Universe() = default;
Universe(double h0);
Universe(double omegaM, double omegaL);
Universe(double h0, double omegaM, double omegaL);
Universe(double omegaM, double omegaL, double omegaG, double omegaK);
Universe(double h0, double omegaM, double omegaL, double omegaG, double omegaK);
//double radius();
//double age();
double distC(double z);
};
#endif
Universe.cpp
#include <cmath>
#include <gsl/gsl_integration.h>
#include "Universe.h"
using namespace std;
double Universe::Hz(double z, void* params) {
double result = 1.0/pow(OmegaL + pow(1.0+z,3.0)*OmegaM + pow(1.0+z,4.0)*OmegaG + pow(1.0+z,2.0)*OmegaK, 0.5);
return result;
}
double Universe::distC(double z) {
double lower_limit = 0.0, abs_error = 1.0e-8, rel_error = 1.0e-8, alpha = 0.0, result, error;
gsl_integration_workspace *work_ptr = gsl_integration_workspace_alloc(1000);
gsl_function Hz_function;
void* params_ptr = α
Hz_function.function = Universe::Hz;
Hz_function.params = params_ptr;
gsl_integration_qags(&Hz_function, lower_limit, z, abs_error, rel_error, 1000, work_ptr, &result, &error);
return distH*result;
}
I don't quite know how to troubleshoot this problem and I'm using GSL for the first time based on the documentation at:
http://www.gnu.org/software/gsl/manual/html_node/Numerical-integration-examples.html
and the following guide:
http://www.physics.ohio-state.edu/~ntg/780/gsl_examples/qags_test.cpp
Thank you for looking and any answers!
Try the following: Make your Hz function static, like so:
static double Hz(double z, void* params)
I verified that this works with your code.
I'm not an expert, but I believe (hand-wavy explanation follows) the basic problem is that, since the gsl_function structure needs a pointer to a function (i.e. double *), the compiler's not happy with using a class method from an "object" which hasn't even been instantiated. Making the function static in the class, however, means the compiler knows where the function can be found even before an instance of the class exists, and can deal with using a pointer to that function. (Maybe someone can give a better explanation than that, but hopefully I'm not too far off track here.)
Hope this helps.
what happens when you change the methode name of HZ?
Related
this is a personal project I've been working on and I can't figure out what's going on here (just learning C++). I found answers to very similar problems, but I can't seem to execute the solution. Here is my code with some of the unimportant bits trimmed out:
#include <iostream>
#include <cmath>
#include <complex>
#include <boost/array.hpp>
#include <boost/numeric/odeint.hpp>
#include <gsl/gsl_roots.h>
class Riemann
{
public:
// constructor
Riemann(double leftP, double rightP, double leftrho, double rightrho, \
double leftvx, double rightvx, double leftvy, double rightvy, double gam);
double PL,PR,rhoL,rhoR,vxL,vxR,vyL,vyR,gamma;
// function prototypes
double shockvelocity(double Pg, int sign);
double rarefactionvelocity(double Pg, int sign);
void RfODE(const boost::array<double,6> &vrhovt, \
boost::array<double,6> &dvrhovtdp, double t);
// ~Riemann();
};
Riemann::Riemann(double leftP, double rightP, double leftrho, double rightrho, \
double leftvx, double rightvx, double leftvy, double rightvy, double gam){
// constructs Riemann public variables
}
double Riemann::shockvelocity(double Pg,int sign){
// calculate a shock velocity, not important here...
}
void Riemann::RfODE(const boost::array<double,6> &vrhovt, \
boost::array<double,6> &dvrhovtdp, double t){
// calculates the ODE I want to solve
}
double Riemann::rarefactionvelocity(double Pg, int sign){
double dpsize=0.00001;
double P,rho,vx,vy,vtest;
//
boost::array<double,6> vrhovt = {vx,rho,vy,double(sign),P,gamma}; // initial conditions
boost::numeric::odeint::integrate(std::bind(&Riemann::RfODE,std::ref(*this),std::placeholders::_1,
std::placeholders::_2, std::placeholders::_3),vrhovt,P,Pg,dpsize);
std::cout<<"vRarefaction="<<vrhovt[0]<<std::endl;
return vrhovt[0];
}
double FRiemann(double Pg, void* Riemannvalues){
Riemann* Rvals = (Riemann*)Riemannvalues;
// calls on Riemann::rarefactionvelocity at some point
}
int main(){
double PL= 1000.0;
double PR= 0.01;
double rhoL= 1.0;
double rhoR= 1.0;
double vxL= 0.0;
double vxR= 0.0;
double vyL= 0.0;
double vyR= 0.0;
double gam = 5.0/3.0;
// calls FRiemann to get a root
}
What's happening is the code is going through, calling Riemann::rarefactionvelocity just fine, but for some reason RfODE is never executed (ex. print statements in this function never execute) and the value for vrhovt[0] returned is of course the value it began with, vx. No compiler errors, either (using gcc 4.8.1 and -std=c++11 and -O2 tags) This is very strange because I've tested the rarefaction-specific functions on their own (outside of the Riemann class) and they work -- the problem seems to be that they're in this class. Given how Riemann solvers work, though, I had my reasons for making a class out of these functions and really would like to find a way to make this work without doing a massive rewrite and changing the class structure.
Any help is much appreciated! Thank you! : )
It might be possible that P is not initialized correctly. At least I don't see it in your code. P needs to be smaller than PG otherwise your are already behind your the end of the integration.
Also, don't use bind, use a lambda instead. I think bind is somehow obsolete in C++11/C++14. It might be possible that bind doesn't get the references correct.
double Riemann::rarefactionvelocity(double Pg, int sign)
{
// ...
// not tested
using namspace boost::numeric::odeint;
integrate( [this](auto const& x, auto &dxdt ,auto t ) {
this->RfODE(x, dt, t); } ,vrhovt,P,Pg,dpsize);
}
Say I have a C++ function that looks like this:
double myfunction(double a, double b) {
// do something
}
Which I then call like this:
double a = 1.0;
double b = 2.0;
double good_r = myfunction(a, b);
double bad_r = myfunction(b, a); // compiles fine
I would like to make sure that a and b are never provided in the wrong order.
What is the best way to ensure this in C++?
Other languages allow named parameters, like this:
double good_r = myfunction(a=a, b=b);
double bad_r = myfunction(a=b, b=a); // mistake immediately obvious
double bad_r = myfunction(b=b, a=a); // compiles fine
Or perhaps the problem can be partly solved using types, i.e.
double my_type_safe_function(a_type a, b_type b) {
// do something
}
a_type a = 1.0;
b_type b = 2.0;
double good_r = myfunction(a, b);
double bad_r = myfunction(b, a); // compilation error
EDIT: A couple of people have asked what I mean by the "wrong order." What I mean is that, in real code a and b have some significance. For example, the arguments might instead be height and width. The difference between them is very important for the function to return the correct result. However, they are both floats and they both have the same dimensions (i.e. a length). Also, there is no "obvious" order for them. The person writing the function declaration may assume (width, height) and the person using the function may assume (height, width). I would like a way to ensure this doesn't happen by mistake. With two parameters it is easy to be careful with the order, but in a large project and with up to 6 arguments mistakes creep in.
Ideally I would like the checks to be done at compile time, and for there to be no performance hit (i.e. at the end of the day they are treated as plain old floats or whatever).
How about this:
struct typeAB {float a; float b; };
double myfunction(typeAB p) {
// do something
return p.a - p.b;
}
int main()
{
typeAB param;
param.a = 1.0;
param.b = 2.0;
float result = myfunction(param);
return 0;
}
Of course, you can still mess up when you assign your parameter(s) but that risk is hard to avoid :)
A variant is to have one struct per "new" type, and then make them go away in optimized builds using macros.
Something along these lines (only slightly tested, so it could be way off):
#define SAFE 0
#if SAFE
#define NEWTYPE(name, type) \
struct name { \
type x; \
explicit name(type x_) : x(x_) {}\
operator type() const { return x; }\
}
#else
#define NEWTYPE(name, type) typedef type name
#endif
NEWTYPE(Width, double);
NEWTYPE(Height, double);
double area(Width w, Height h)
{
return w * h;
}
int main()
{
cout << area(Width(10), Height(20)) << endl;
// This line says 'Could not convert from Height to Width' in g++ if SAFE is on.
cout << area(Height(10), Width(20)) << endl;
}
I think you already provided the easiest solution, using types.
One alternative could be using a builder class and method chaining.
Like:
class MyfunctionBuilder {
MyFunctionBuilder & paramA(double value);
MyFunctionBuilder & paramB(double value);
double execute();
(...)
}
Which you would use like this:
double good_r = MyFunctionBuilder().paramA(a).paramB(b).execute();
But this is a lot of extra code to write!
What is the "wrong order" actually? In this example of yours
double myfunction(double a, double b) {
// do something
}
double a = 1.0;
double b = 2.0;
double good_r = myfunction(a, b);
double bad_r = myfunction(b, a);
how do you actually want to know if this is the right order? What if the variables would be named "quapr" and "moo" instead of "a" and "b"? Then it would be impossible to guess whether the order is right or wrong just by looking at them.
With this in mind, you can do at least two things. First, is to give meaningfull names to the arguments, e.g.
float getTax( float price, float taxPercentage )
instead of
float getTax( float a, float b )
Second, do the necessary checks inside:
float divide( float dividend, float divisor )
{
if( divisor == 0 )
{
throw "omg!";
}
}
It is possible to do more complex checks, such as making a functor, and setting it's parameters explicitly, but in most of the cases that just complicates things without much benefit.
I want to write a structure containing all the functions (including GSL functions) and parameters for solving an ODE system. From the main function, I only want to call an update function defined in the struct to advance the system by one time-step. When I try this however, I get the error:
Line 27, ERROR: cannot convert ‘ODE::funcS’ from type ‘int (ODE::)(double, const double*, double*, void*)’ to type ‘int (*)(double, const double*, double*, void*)’ Below is a minimal code. \
Here is a minimal version of my code:
#include <iostream>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_matrix.h>
#include <gsl/gsl_odeiv.h>
struct ODE
{
void update(double dt)
{
// code to advance ODE solution by one time-step dt
}
int
funcS (double t, const double y[], double f[],
void *params)
{
return GSL_SUCCESS;
}
double mu = 10;
gsl_odeiv_system sysS;
void
initializeSys()
{
sysS.function = funcS; //Line 27
}
};
int
func (double t, const double y[], double f[],
void *params)
{
return GSL_SUCCESS;
}
int main()
{
// GIVES ERROR
ODE mySys;
mySys.update(0.01);
// WORKS
double mu = 10;
gsl_odeiv_system sys;
sys.function = func;
return 0;
}
You don't need to use static function directly. Instead you can write a very general wrapper.
I believe this is a duplicate question. My answer to the question I just linked is based on the wrapper presented here. However, I generalized it using templates to avoid the performance penalty of std::function due to heap allocation of the functor that std::function holds (the original answer only warns the reader about the penalty that is caused by the multiple indirection involved in std::function implementation, and this is negligible in comparison to the problem caused by heap allocation).
EDIT 1: This issue is also discussed here
EDIT 2 (to answer a question you raised in your first comment to my answer). The first caveat is that you have to make sure that whatever std::function holds is not deleted before GSL finish the calculation. Also, #Managu pointed out that the wrapper itself must not be out of scope while GSL works. This is not hard to enforce if you code carefully. Example of bad code:
// BAD PROGRAM - EXAMPLE OF WHAT YOU MUST NOT DO. DO NOT COPY THIS CODE
// HERE THE WRAPPER GETS PREMATURELY OUT OF SCOPE => CRASH
gsl_function *F
auto ptr = [](double x)->double{return 2*x;};
std::function<double(double)> FF1(std::cref(ptr))
{
gsl_function_pp Fp(FF1);
F = static_cast<gsl_function*>(&Fp);
}
(...)
// CALL GSL
My situation is following, I have two different bisection functions what will be called at some point in my code. Basically some function calls Bisection2 and this function calls either the passed function or it passes the function pointer to Bisection function.
in header I have
std::vector<double> F();
double F1(double m1, double m2);
double F2(double m1, double m2);
typedef double (MyClass::*MyClassFn)(double,double);
double Bisection(MyClassFn fEval,double min, double max,std::vector<double> args);
bool Bisection2(MyClassFn fEval1,MyClassFn fEval2,double xmin, double xmax, double ymin, double ymax,double *ax, double *ay,std::vector<double> args);
And my bisection functions look like this. I didn't include all the code because it's not necessary.
double MyClass::F1(double m1, double m2) {
m_m1 = m1;
m_m2 = m2;
F();
return m_my;
}
double MyClass::F2(double m1, double m2) {
m_m1 = m1;
m_m2 = m2;
F();
return m_mx;
}
double MyClass::Bisection(MyClass fEval,double min, double max,std::vector<double> args)
{
// Setting a lot of stuff here, including auxiliary and leftvalue...
MyClass *pObj = new MyClass(-1);
leftvalue = pObj->*fEval(auxiliary, left);
ightvalue = pObj->*fEval(auxiliary, right);
// Comparing and setting values here etc.
}
bool MyClass::Bisection2(MyClassFn fEval1,MyClassFn fEval2,double xmin, double xmax, double ymin, double ymax,double *ax, double *ay,std::vector<double> args)
{
// Setting some values here but these have nothing to do with the problem.
double yl;
double leftvalue, rightvalue, middlevalue;
MyClass *pObj = new MyClass(-1);
// Setting some values here but these have nothing to do with the problem.
std::vector <double> arg;
// pushing some values
yl = Bisection(fEval2,ymin,ymax,arg); // Here is the first way how I need to pass fEval2 to Bisection function.
arg.clear();
if(isnan(yl))
{
return M_NAN;
}
leftvalue = pObj->fEval1(xl, yl); // And here is the second way how I need to use fEval1.
//.....
}
And then I have basically a function what calls
`Bisection2(F1,F2, m_m2,0.0, 0.0, m_max2, &m_mu1, &m_mu2,args);
The Bisection2(...) call may be incorrect at the moment because I've changed the functions a lot since this worked last time. Last time I basically called F1 and F2 function pointers directly inside the functions instead of fEval's but I'm quite sure it was incorrect way after all even thought it seemed to work somehow.
Now leftvalue = pObj->*fEval(auxiliary, left); causes compiling errors:
error: must use ‘.*’ or ‘->*’ to call pointer-to-member function in ‘fEval (...)’, e.g. ‘(... ->* fEval) (...)’
I've tried to see help from here http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.2
and also checked maybe different solved problems in these forums but still can't figure out what I'm doing wrong.
Thank you.
As the error message says, you need parentheses. This is because the function call has higher precedence than the ->* operator:
leftvalue = (pObj->*fEval)(auxilary, left);
^ ^
Also, you almost certainly shouldn't be using new here; you can fix the memory leaks using automatic storage:
MyClass obj(-1);
leftvalue = (obj.*fEval)(auxiliary, left);
This is simply a matter of priority :
Instead of doing pObj->*fEval(aux, left), just do (pObj->*fEval)(aux, left)
I'm trying to dertermine if the time overhead introduced by boost::function to evaluate mathematical functions is negligeable versus using function templates.
The code for the benchmark I use is bellow.
With traditionnal g++, overhead with boost::function is negligeable :
$ g++ -O3 main.cxx
$ ./a.out
METHOD INTEGRAL TIME TO COMPUTE (SEC)
Direct 0.379885 3.360000
Function template 0.379885 3.380000
Boost function 0.379885 3.400000
With llvm-g++, there a speed gain of factor 1.5 for templates function, but no gain for boost::function.
$ llvm-g++ -O3 main.cxx
METHOD INTEGRAL TIME TO COMPUTE (SEC)
Direct 0.379885 2.170000
Function template 0.379885 2.160000
Boost function 0.379885 3.360000
Is it possible to obtain the 1.5 gain for boost::function and llvm-g++?
#include <boost/function.hpp>
#include <math.h>
#include <stdio.h>
typedef unsigned int UInt;
using namespace std;
//=============================================================================
// chrono
//=============================================================================
class Chrono
{
clock_t t1_,t2_,dt_;
public:
Chrono(){}
void start() { t1_=clock(); };
void stop() { t2_=clock(); };
double diff() { return ( (double)( t2_ - t1_) ) / CLOCKS_PER_SEC; };
};
//=============================================================================
// function to integrate
//=============================================================================
inline double fct(double x)
{
return 1. / (1.+exp(x));
}
//=============================================================================
// using direct method
//=============================================================================
double direct(double a, double b, UInt numSamplePoints)
{
double delta = (b-a) / (numSamplePoints-1);
double sum = 0.;
for (UInt i=0; i < numSamplePoints-1; ++i)
sum += 1. / (1. + exp(a + i*delta));
return sum * delta;
}
//=============================================================================
// using function template
//=============================================================================
template<double functionToIntegrate(double)>
double integrate(double a, double b, UInt numSamplePoints)
{
double delta = (b-a) / (numSamplePoints-1);
double sum = 0.;
for (UInt i=0; i < numSamplePoints-1; ++i)
sum += functionToIntegrate(a + i*delta);
return sum * delta;
}
//=============================================================================
// using Boost function
//=============================================================================
typedef boost::function<double ( double )> fct_type;
class IntegratorBoost {
public:
fct_type functionToIntegrate;
IntegratorBoost(fct_type fct): functionToIntegrate(fct){}
double integrate(double a, double b, UInt numSamplePoints)
{
double delta = (b-a) / (numSamplePoints-1);
double sum = 0.;
for (UInt i=0; i < numSamplePoints-1; ++i)
sum += functionToIntegrate(a + i*delta);
return sum * (b-a) / numSamplePoints;
}
};
//=============================================================================
// main
//=============================================================================
int main()
{
double integral;
UInt numSamplePoints = 5E07;
Chrono chrono;
printf("%-20s%-10s%-30s\n","METHOD","INTEGRAL","TIME TO COMPUTE (SEC)");
// Direct
chrono.start();
integral = direct(0., 1., numSamplePoints);
chrono.stop();
printf("%-20s%-10f%-30f\n","Direct",integral,chrono.diff());
// Function template
chrono.start();
integral = integrate<fct>(0., 1.,numSamplePoints);
chrono.stop();
printf("%-20s%-10f%-30f\n","Function template",integral,chrono.diff());
// Boost function
chrono.start();
IntegratorBoost intboost(fct);
integral = intboost.integrate(0.,1.,numSamplePoints);
chrono.stop();
printf("%-20s%-10f%-30f\n","Boost function",integral,chrono.diff());
}
Without actually measure, I am going to venture and claim that using boost::function (or std::function from C++11) cannot be as efficient as the other two options.
The reason is that function uses type erasure to remove the type of the actual functor being used, and that implies that function needs to store the actual object that makes the call through by pointer and use function calls. On the other hand, in the other two methods, the compiler is able to inline the logic and remove the cost of dispatch.
This is actually quite similar to the many times mentioned difference in performance of C library qsort compared to C++ sort, where by using a functor the compiler has better chances for inlining and optimizing.
A different question then, is whether this will have an impact on your application, and for that you need to measure. It might be the case that overall the cost of IO, or any other operation dominates your application and this won't make a difference at all.