Sorry for my non-response on any part of this thread. I've been away on vacation.
> -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Friday, June 27, 2003 7:20 PM > To: Jakarta Commons Developers List > Subject: Re: [math][functor] More Design Concerns > > > J.Pietschmann wrote: > > Mark R. Diggory wrote: > > > > > > > Further comments: > > 1 Now there are two root finding frameworks in place. I think > this should > > be unified. > > I agree. My preference would be to eliminate the original > RootFinding.java and refactor the distribution inversion methods to use > the new framework. Before taking that step, however, I would like to > hear Brent's opinion on what might be improved in the new framework. The only issues I have are with the UnivariateRealSolverFactory class. I feel there should be a separation of the factory method and the solve methods. I don't think the solve method belong on a factory. They are more appropriately placed (do I dare say) in a SolverUtils utility type class. Also, for the factory to provide its intended flexibility, I would reimplement it using the abstract factory design pattern. This allows the factory to be swapped in and out at the user's leisure. As it stands the factory can only create one product even though there are several products that could be created. If a user wants/needs to create a specific solver, they must circumvent the factory and use the constructor. This defeats the whole purpose of the factory which is to control product creation. I would suggest adding factory methods that enable the creation of the other products. > > > 2 Either derive ConvergenceException from MathException and use it in > > BrentSolver and SecantSolver too for indicating convergence problems, > > or replace it in or somewhere near Gamma.java with a MathException. > > I agree. My vote would be to leave MathException in math and derive > ConvergenceException in analysis from it. > That makes sense. I would suggest moving ConvergenceException out of org.apache.commons.math.analysis because I think we'll eventually have a cyclical package dependency with org.apache.commons.math.util as ContinuedFraction depends on ConvergenceException. > > > 6 Factorials and binominal coefficients are classical classroom > examples, > > but I never saw them in any real world implementation of a numerical > > algorithm. Well, with the possible exception of number theory related > > stuff. In fact, encountering these is usually an indication that the > > algorithm could be sped up by at least an order of magnitude. > > Interesting perspective. The uses that I had in mind were for discrete > probability distributions (and yes, maybe some number-theoretic or > purely combinatorial stuff). I have from time to time needed to compute > binomial coefficients and/or probabilities in testing or simulation > applications. Now that we have the Gamma function, binomial > probablilities don't really need binomial coefficients. If others agree > that these will have limited practical application, I would be OK with > dropping them. 1) "limited practical application" implies some practical application. 2) They are already coded, tested, and working. Therefore, I would suggest leaving them in. Brent Worden http://www.brent.worden.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
