[
https://issues.apache.org/jira/browse/MATH-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264696#comment-14264696
]
Sriram Natarajan commented on MATH-1185:
----------------------------------------
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.2E-308 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/Double-precision_floating-point_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 10e-17 ?
> ----------------------------------------------
>
> Key: MATH-1185
> URL: https://issues.apache.org/jira/browse/MATH-1185
> 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.1102230246251565E-16
> 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)
