Whether hygeinv command returns 'NaN' depends on form of vector

Question

Matthew Brenneman 2020-12-21

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/698915-whether-hygeinv-command-returns-nan-depends-on-form-of-vector

评论： Matthew Brenneman 2020-12-21

Hi,

I am analyzing the median of a hypergeometric distribution using MatLab. I know the hygeinv command is known to return "NaN", but I have a strange case where this problem seems to depend only on the way I input a vector.

So I have X~hyper(N,n,n) where N = size of population and n=sample size and n=number of successes. I express n as a % of N, so I define a vector of percentages

Pi_n = [0.1:0.1:0.5];

from which n is computed as n=N*Pi_n and the median is computed using hygeinv(0.5,N,n,n)

When I do this (and the code is shown below), MatLab returns "NaN" for p=0.3

BUT, when I enter the values of ther percenatges explicityl

Pi_n = [0.1,0.2,0.3,0.4,0.5];

I have no problems.

%%%%%%%%%%%%%%%%%%%%%% CODE %%%%%%%%%%%%%%%%%%%%%%%%

% II INITIALIZING VARIABLE AND ARRAY

clear all

N = 100; % Population size

Pi_n = [0.1:0.1:0.5]; % sample size as % of popltn size (DOES NOT WORK)

% Pi_n = [0.1,0.2,0.3,0.4,0.5]; % sample size as % of popltn size (DOES WORK)

%

% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% III CALCULATIONS FOR MEDIAN

n = N*Pi_n; % compute n, which is both sample size & # successes

Median = hygeinv(0.5,N,n,n);

% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% IV OUTPUT

plot(100*Pi_n,Median(1,:),'-or','Linewidth',2)

7 个评论
显示 5更早的评论隐藏 5更早的评论

Stephen23 2020-12-21

编辑：Stephen23 2020-12-21

"But the vectors are the same"

Nope, they are not. I already showed in my last comment, that the values are different.

"So if it was an error associated with numerical precision why would it occur with the one form and not the other"

You defined two different binary floating point vectors and provided them to some function and got two different sets of output values. All you have shown is that the algorithm implemented in that function is perhaps slightly numerically unstable.

"they should be the same vector in MatLab"

There no reason to expect that two different numeric methods should resolve to exactly the same binary floating point number, even if they are algebraically equivalent. Writing 0.3 and using the colon operator from 0.1 with a step of 0.1 apparently don't give exactly the same value (both values are however perfectly correct within the precision of the data class).

If you want to see what their exact values are then download this:

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

This explains how the colon operator worked on earlier versions, I presume it is similar today:

https://www.mathworks.com/matlabcentral/answers/53912-floating-point-accurarcy-and-colon#comment_624049

"... there is round off in the process"

Not really, it has nothing to do with any "process" as such: all binary floating point numbers are limited to a fixed precision. Any way of defining or operating on them will, in general, result in floating point error (which can accumulate with any further operations) Just writing 0.3 does not give you exactly the value 0.3, nor will any operation give you exactly 0.3. This has nothing to do with any "process", just the fact that 0.3 cannot be represented exactly using binary floating point numbers.

"The article doesn't say the form (or precision) depends on the way you define the vector though."

It doesn't. The (binary) precision of binary floating point numbers is fixed, it is determined solely by the class of numbers that you are using and nothing else. It most certainly does NOT depend on what operations you perform!

Matthew Brenneman 2020-12-21

I really appreciate the information. You've definitely pinpointed the source of the error: that is crystal clear.

But I think it is still unresolved (to me) why if 0.3 is never exact, it seems to work with the one method but not the other. If it is just because the number 0.3 is not exact, it seems that it shouldn't work for any method (no matter how it is arrived at). To get a better understanding of what you are saying, I am trying to reconcile what you say earlier, "There no reason to expect that two different numeric methods should resolve to exactly the same binary floating point number, even if they are algebraically equivalent.", with what you say near the end, " The (binary) precision of binary floating point numbers is fixed, it is determined solely by the class of numbers that you are using and nothing else. It most certainly does NOT depend on what operations you perform!". The first statement suggests the operations (which I take you to mean by "numeric methods") could affect the precision, while the second seems to say that it can't. I suspect the former is true. In the end, I can deal with it, but it is a pain because it means that the shorthand way of defining vectors may be less reliable for some applications and I may have to write out the vector in some cases (in this case, I can correct the issue by using the "round" command on the inout to the hygeinv command).

Stephen23 2020-12-21

编辑：Stephen23 2020-12-21

"The first statement suggests the operations (which I take you to mean by "numeric methods") could affect the precision..."

The (binary) precision of a binary floating point number does not change. Different operations affect the values, not the precision. Even changing the order of the same operations can affect the values: associative laws of algebra do not necessarily hold for floating-point numbers. But the precision of the data class cannot change (subnormals excluded).

"it seems that it shouldn't work for any method"

I don't see why that would be true. An algorithm's implementation can be sensitive to accumulated error for specific values, for specific edge-cases, for error accumulating in one particular direction (but not the other), or ... etc. etc. Apparently the algorithm implemented in that function is numerically unstable: use the debugging tools to find out why (it is also possible that there is a bug in the code... such things are known to occur).

"... it is a pain because it means that the shorthand way of defining vectors may be less reliable for some applications and I may have to write out the vector in some cases"

Neither is more "reliable" than the other, they are both "correct" within the precision of the data that you are using. Understanding that is key to understanding how to write robust code that works on binary floating point numbers.

Matthew Brenneman 2020-12-21