Re: [Help-gsl] Computation of gsl_sf_hyperg_1F1 fails for some values

[Sam Mason]

On 10 May 2013 12:20, Daniel Schury <address@hidden> 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