Is NI aware that the inputs to the gamma distribution (scale b and shape c parameters) are reversed? This labview bug has cost me many hours of code development time!!!! It would be nice to see this rectified in future versions in the full development system. Also a rebate would be nice, but that won't happen.
Reporting bugs has always been difficult with NI but they have done some corrections based on the developer's bug reports. Click the below link and try to contact "Troubleshoot and Develop" team.
The rest is in their hands.
Hit KUDOS for Thanks
Is NI aware that the inputs to the gamma distribution (scale b and shape c parameters) are reversed?
Plain LabVIEW does not have anything named "gamma probability distribution". Is this from a toolkit? Are you talking about CDF? Is this classic or NXG? Can you point us to the online help of the exact function you are talking about. Thanks!
Its in LabVIEW full development system > Math> Prob and Stats> Probability>continuous pdf (gamma option)
There is the same problem with CDF and inverse CDF
Yes, he's talking about the Gamma Distribution found as a polymorphic choice of the Continuous CDF VI found buried on the Mathematics Palette. And, in fact, he is also correct that "b" is the "shape" parameter and "c" is the "scale". Other than that, the VI seems to be correct (it calls the Incomplete Gamma Function and with b and c reversed, looks like it "does the right thing"). Another "hint" is that "c" is the divisor of "x", as though it was "scaling the input variable" ...
Yes everything works just fine if you reverse the b and c inputs. The point is that one doesn't know to do this until lots lots of debugging identifies labview as the culprit. Once you look at the labview code it is obvious what is what.
I've taken the liberty of calling NI to report this as a "Documentation Bug". As you can imagine, this has to be "checked" and a remediation plan developed. Personally, I think the most unambiguous way to fix this is to call the parameters "x", "shape", and "scale" (rather than "x", "b", and "c", because who knows what "b" and "c" mean, but "shape" and "scale" have a certain intuitive flavor about them).
I am not very familiar with these functions and their underlying math, but it seems to me that this polymorphic set of VIs has other problems and confusing assignments. Lets have a look at the diagram "Beta CDF" from the same set:
There is an entire instance of a subVI just floating around in the lower left, not connected to anything. Hopefully the compiler will drop that during dead code elimination. Also the wiring and terminal names is quite confusing (x wired to a, a wired to x, and b wired to y). Maybe it's all correct, but a common naming scheme for terminals would probably eliminate a lot of confusion and avoid errors. 😄
They are unambiguously called shape and scale in the documentation. It is just that they are not assigned correctly to the inputs. Hopefully bug fixes will only be in the documentation, otherwise software that is currently working because this bug has been accounted for will stop working.
I agree that shape and scale would be better input names than a and b.