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.
> 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.
> (commonsrecursiveexception? :),
>  conditionally compile something, probably making a JDK 1.4 compiled
> commonsmath.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 LUdata 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 "nonOO" 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 numbertheoretic 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, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@jakarta.apache.org
>

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
