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.
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.
3 Both MathException and ConvergenceException don't compile on Java 1.3 and nobody noticed. This is ugly:
Ouch! need to fix this.
Ranks inserted (IMHO, of course)
- implement the recursive exception mechanisms in MathException, as
everybody else does, or
#2
- get such an implementation from elsewhere
#1 Look at the nested package in lang.
(commons-recursive-exception? :-),
- conditionally compile something, probably making a JDK 1.4 compiled
commons-math.jar incompatible with JRE 1.3
#4 boo hiss -- violates stated commitment
- remove the constructors with recursive throwables, as they aren't
yet used anyway.
#3.
4 LU composition and equation system solvers should be put in a separate class, similar to root finders. RealMatrix should only hold data and provide arithmetic. It may be necessary to have an additional object for holding the LU-data as a result of the decomposition algorithm. a static function can provide a simple interface to solving equation systems using default algorithms, the same way it is done in the root solving framework.
I could go along with the bean vs. operations separation, but I would want to do the whole thing -- not just separate out solve and LU decomp. That is what I did in the still not submitted Complex class. If others agree, I can refactor to leave only properties in the matrix class -- i.e., encapsulate all matrix operations, including add, multiply, etc and certainly solve in a MatrixUtils class. Part of the reason for packing it all into RealMatrix was the need to keep the LU decomposition handy to avoid having to recompute it. I will think about ways to do this without having to either a) keep recomputing the LU decomp b) copy too much data or c) expose too much. Suggestions are welcome. The other part of the reason that I left everything in RealMatrix was "navigability" or "convenience". The current interface is really very simple and I thought it would be easy for users to quickly find what they were looking for if all supported real matrix operations were encapsulated in RealMatrix. I have to confess, however, that I have never liked this.add(that) syntax -- regardless of how "functionalist" or "non-OO" that perspective may brand me. I am interested in what others think about this -- especially others who might actually use real matrices in their programs.
Note that to me, solve() is conceptually no different from add -- both are matrix -> matrix operations and neither can meaningfully be construed as a matrix property.
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.
Thanks for the feedback.
Phil
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
