 Phil Steitz <phil@steitz.com> wrote:
> There are two significant things that remain to be resolved before we can
> release RealMatrix.
>
> 1. We need to decide what to do about solve(). After reviewing the code
> again, I am OK leaving the current setup alone. If users want to
> implement a different solve() method they can a) subclass RealMatrixImpl,
> b) implement RealMatrix directly, or c) Add their own Solver class (which
> we could also do later if we want to). The cached lu decomposition in
> RealMatrixImpl makes the basic operations straightforward, relatively
> efficient and generally OK numerically (absent any information about the
> matrix). < IANANA (NA = numerical analyst), so please correct me if this
> is wrong :). The main point is that I don't see us painting ourselves
> into a corner here  external solvers can easily be added later. Here
> again, pls correct me if I am missing something.
I had hoped to review the code myself but just haven't had time. IANANLA (NLA
= numerical linear algebraist), but my understanding is, as you say, that LU
decomposition is the best general purpose (i.e., needing no knowledge of
particular properties of the matrix) approach to solving sets of linear
equations. So if the code is open to easily substituting other solution
algorithms, LU plus backsubstitution is a good default algorithm. I wonder if
it would be worthwhile making it easier to switch algorithms (Strategy
pattern?) before releasing 1.0.
> 2. Rank computation. I am sorry that I missed this in the task list and
> Release Plan. Based on what other packages do, I think that the right way
> to do this is to implement singular value decomposition and return the
> "effective numerical rank" by counting singular values that are bounded
> away from zero (see, e.g.
>
http://math.nist.gov/javanumerics/jama/doc/JamaSingularValueDecomposition.html).
>
> Some implementations add an epsilon argument to determine the bound.
> Unfortunately, I do not have an SVD impl laying around and this will be a
> fair amount of work. Our choices would then seem to be:
>
> (i) Hold the realease until someone volunteers to implement SVD
> (ii) Remove the method from the RealMatrix interface (ouch!!)
> (iii) Release RealMatrixImpl throwing UnsupportedOperationException
> (iv) Cobble together a "naive" implementation using row reduction
>
> Thoughts? Other suggestions??
>
> Phil
Here is where IANANLA comes in for real: is rank computation used very often?
It would be a shame to have to remove it from the interface, but if it's too
hard to implement and isn't used much, maybe it's worth reconsidering whether
it should be a required member of the interface. Could there be an
RealMatrixOptional interface? Would that be too weird?
I am leaning toward option (iv) unless others prefer (i), (iii), or (ii), which
is my order of preference for those options. SVD, from a skim of NR's chapter
on it (I was careful to only read the little margin comments when I was
skimming through the pages with code <g>), seems to be a much more complicated
algorithm than we should take on this close to releasing 1.0. Although there
are public domain implementations found via GAMS (http://gams.nist.gov/),
deciding which among them to translate to Java  assuming we even wanted to do
that  would take time, as would the translation process. SVD seems extremely
useful for many purposes, but I have a feeling that insisting upon providing it
just for accurate rank computation would delay 1.0 an unacceptably long time.
Al
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

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