On 10 May 2013 12:20, Daniel Schury <[email protected]> wrote: >> Is that double negation really needed? Seems redundant, or am I >> missing something? > I don't know where the double minus came from, but the third parameter > is in fact -1.0/2.0*pow((E1-x)/dE,2.0)). Then The value should be > something around 457.
If I evaluate the above in Mathematica (v8) with the values you gave before I get 1895.95 back; not sure why we're getting different answers. Then again I don't have any experience of these hypergeometric functions so can't suggest much to help here—sorry! >> In this case; in C the ^ operator is a bitwise xor and doesn't raise >> things to a power. > As you can see, I changed the ^ to pow(), but that doesn't help. The > Origin C compiler understands the ^, so that's not the problem. OK, but that's strange; if it's really a C++ compiler underneath that's overloading this for doubles then that seems sort of reasonable. You really need to isolate the bit of code and run it in a plain C compiler to figure out where the problem is coming from. >> You be better off reporting the actual values of a, b and x that >> caused the program to crash. When you printed these out you may >> notice that something strange is happening. > The given values _are_ values I got problems with. No, you're doing some calculations. If you reported: gsl_sf_hyperg_1F1(-1.045, 0.5, -706.88) then things would be clearer. > Interestingely, the last time I got a new error message: "R6025 - pure > virtual function call" But the description given by microsoft > (http://support.microsoft.com/kb/125749/en-us) doesn't help me. This is a C++ error message; something has gone wrong with your class hierarchy; you need to look at your C++ code as this isn't anything to do with the GSL. Maybe the wrappers from Origin are breaking something? Sam
