LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

gamma probabilty distribution

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.

0 Kudos
Message 1 of 10
(2,837 Views)

Hello

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.

http://sine.ni.com/apps/we/nicc.call_me?p_action=country&p_lang_id=US

The rest is in their hands.

 

-Rahul

Hit KUDOS for Thanks

 

0 Kudos
Message 2 of 10
(2,786 Views)

@miklovicd wrote:

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!

0 Kudos
Message 3 of 10
(2,729 Views)

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

Message 4 of 10
(2,708 Views)

@altenbach:

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" ...

 

Bob Schor

0 Kudos
Message 5 of 10
(2,701 Views)

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.

0 Kudos
Message 6 of 10
(2,695 Views)

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).

 

Bob Schor

Message 7 of 10
(2,685 Views)

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. 😄

 

CDFWTF.png

0 Kudos
Message 8 of 10
(2,680 Views)
0 Kudos
Message 9 of 10
(2,677 Views)

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.

0 Kudos
Message 10 of 10
(2,663 Views)