[ https://issues.apache.org/jira/browse/MATH1185?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=14264696#comment14264696
]
Sriram Natarajan commented on MATH1185:

Thanks for the responses. I didn't think my post made it.
Stats packages like R, dcdf, Excel must be compromising with the precision in the representation
before the exponent in order to at least represent the order of magnitude of the probability
(so a result upto Double.MinValue 2.2E308 is feasible). Isn't that what happens naturally?
f(130)/100 would be the same number of digits but the exponent would change to 18. Is the
decision made by R etc. in some way "wrong"?
http://en.wikipedia.org/wiki/Doubleprecision_floatingpoint_format does say that beyond 2^52
there are gaps in representable integers. All that means is that the representation is not
exact. AFAIK, even 0.1 does not have an exact representation as a double. Hence 0.1 + 0.2
isn't exactly 0.3.
> Tail probability drops to zero beyond 10e17 ?
> 
>
> Key: MATH1185
> URL: https://issues.apache.org/jira/browse/MATH1185
> Project: Commons Math
> Issue Type: Wish
> Affects Versions: 3.3, 3.4
> Reporter: Sriram Natarajan
> Priority: Minor
>
> This could be a simple question, In which case I can expect a clarification. If this
is the wrong place to post such a question, let me know.
> OS: Windows 8.1, Java 1.8.0_25
> ChiSquaredDistribution chisq = new ChiSquaredDistribution(23)
> 1.0  chisq.cumulativeProbability(130) is 1.1102230246251565E16
> 1.0  chisq.cumulativeProbability(131) is 0.0
> Am pretty sure it is not a formatting issue. Is there a reason why the tail drops to
zero at this point?

This message was sent by Atlassian JIRA
(v6.3.4#6332)
