commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math][functor] More Design Concerns
Date Sat, 28 Jun 2003 00:19:35 GMT
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.

>    (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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
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