J.Pietschmann wrote:
Paul Libbrecht wrote:
a.) logging:
I don't really agree here. I do think it is very useful for any system to be able to raise a logging verbosity at any-time so that bugs and misunderstandings can be tracked.
It depends on the complexity of the stuff potentially being prepared for logging. I don't think [math] is already complex enough that built-in logging is warranted. The implemented algorithms should be reasonably fail-safe for the most part. Failures could be sensibly handled with exceptions, and data for tracking down the problem (e.g. convergence problems in the solver) should be available. If not, this should be corrected of course.
The issues where I found Logging occurring where in situations such as this catch in GammaDistributionImpl
/** * For this disbution, X, this method returns P(X ≤ x). * @param x the value at which the PDF is evaluated. * @return PDF for this distribution. */ public double cummulativeProbability(int x) { double ret; if (x < 0) { ret = 0.0; } else if (x >= getNumberOfTrials()) { ret = 1.0; } else { try { ret = 1.0 - Beta.regularizedBeta(getProbabilityOfSuccess(), x + 1.0, getNumberOfTrials() - x); } catch (MathException ex) { LogFactory.getLog(getClass()).error( "Failed to compute cummulative probability, returning NaN.",ex);
ret = Double.NaN;
}
}
return ret;
}I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here?
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
