Bug in the Kummer Function

[X.]

Kummer function in the Mathematics>>Advanced Function>>Elementary & Special Functions>>Hypergeometric Functions Palette:

 = M(x; a, b)

A definition can be found here and calculations can be checked with the Wolfram Alpha engine (the function is also known a 1F1(a,b;x) there) or your favorite math software.

First, let's try a point where the calculation does not fail:

M(-7, 19, -0.5) = -0.5674441 according to LV 2012

1F1(19, -0.5; -7) = -0.567638 according to the WAE.

hypergeometric([19],[0.5],-7) = -0.56763766813983 according to Maxima

Who should I believe? LV, or Wolfram Alpha and the folks under the Maxima open source project?

Now let's try this:

M(-8, 19, -0.5) = NaN according to LV 2012

1F1(19, -0.5; -8) = -0.305065 according to the WAE.

hypergeometric([19],[0.5],-8) = -0.30506520459665 according to Maxima

Should I really put my faith in LV here? Any values of x smaller than -7 fails to return any meaningful results, but even when it does return a value for some parameter sets, the value might be relatively different from the "exact" one.

Conclusion: you better check (and shake) those special functions (and any function for that matter) before using them in some serious work, as it seems that's not a step that NI seems to be including in their testing protocol.

I thought I had read that NASA and some other big guys were using LV for some pretty serious stuff. I am starting to wonder...

[X.]

There are two typos above in the hypergeometric Maxima function arguments: 0.5 should be replaced by -0.5, obviously. This is JUST a typo. The calculations were performed with the same arguments in each software.

[Darin.K]

Feel free to try my Confluent Hypergeometric function.  Let me know if it works any better, at least the code is all in G so you can see where I screwed up.  I spiffed up the icon just for you.

My original is pretty old so I don't remember all of the details in writing it,but if you study the series you will see that if you do not have arbitrary precision than you better at least use EXT precision.  I don't think DBL will cut it, and that is probably why LV gets it close, but no cigar.  Why it totally screws up is hard to determine.  If I open a math VI and see a CLFN then I will not touch it.  It has bugs and I can not fix it.  If I open it and see G code then I know it still has bugs, but now I can fix them.  I'd rather roll my own and rely on NI to at least provide spiffy icons.

The series I use is probably in Abramowitz and Stegun knowing my usual go to sources.  Probably should have noted it.

[X.]

I was starting reading chapter 13 (Confluent Hypergeometric Functions) of Abramowitz and Stegun when I checked back the thread to remember which values I had used... and there is is! A nifty little G loop. Thanks. Looking fine so far.

On a side note, I was about to start a rant on those "proprietary" dll-based VIs which contain a significant fraction of road killers. I guess there is no point anymore!

Note: as I was editing the icon to put variables in the "Standard" order, I noticed that the icon itself is buggy (check the top part only):

 

That's not how a gamma looks like (not sure about the mellowing beta, but at least it does not startle me)!

Moreover the two letters are slightly offset with respect to one another.

Note that this is the template for all special function icons...

Here is my modified version:

[GregFreeman]

Nice solution, Darin. I was determined to figure out how the heck you got that, and it finally took me writing it out on paper to see how things could be factored out leaving you with something relatively simple to code up. The key was once I realized each term is the previous term * [(a+n)x]/[(b+n)n], storing the previous term in the shift register as you go.

[X.]

Still buggy in 2013.

[Norbert_B]

Filed CAR #424089 against LV 2013.

Norbert

[Yamaeda]

If you change Darins function to all Doubles you'll get closer to LV's values, so it's a repeated rounding error/precision limit that's the cause of LV's issues i deduct.

Nice one Darin!

/Y

[X.]

LV 2014 64 bits:

M(-7, 19, -0.5) = -0.567682243163

M(-8,19,-0.5) = NaN

which are the values of LV 2013.

Notice the subtle change from 2012 to 2013...

[sassyaspy]

Hi all,

This behavior has been fixed in LabVIEW 2015, as tracked by CAR 424089 that Norbert filed previously. Thanks for bringing this up!