Phil Steitz (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510905 > ] > > Phil Steitz commented on MATH-167: ---------------------------------- > > > Thanks for reporting this. I see three alternatives to address - > appreciate comments. 1) Determine tail resolution possible with > current impl (hopefully not different on different JDKs, platforms) and "top code", checking arguments and returning 0 or 1, resp if argument is too far in SD units from the mean. To find the cut points, empirically determine where convergence starts to fail. Document the cut points in javadoc for Impl. > 2) Catch ConvergenceException and return 0 or 1, resp if argument is > far from the mean; rethrow otherwise (though this should never > happen). > 3) Resolve as WONTFIX and leave it to client to catch and handle > ConvergenceException, examining argument. Document algorithm more > fully and warn that ConvergenceException will be thrown if tail > probability cannot be accurately estimated or distinguished from 0. > My first thought was 2 and I guess I still favor that, since 3) is > inconvenient for users and 1) may not be stable unless cut points are > conservative. Note that this same problem may apply to tail > probablilities of other continuous distributions and we should check > and address all of these before resolving this issue.
I also think 2) is the better choice. I don't think finding the cut point for 1) is even feasible reliably for all JVM implementations, so 2) as the advantage of being self-adaptive. Another reason I like this is that this is really an "exceptional" case so exceptions are really suited to that, they should not be restricted to error handling only. Using them here is probably more efficient as it saves two a priori "if" statements that are really not needed most of the time. Luc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
