commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [jira] Commented: (MATH-167) ConvergenceException in normal CDF
Date Sat, 07 Jul 2007 18:50:15 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message