Phil, et alia, Thanks for the response. This is the first time I've submitted any code to any community for review and potential inclusion in any open-source project, I usually just create stuff for my own use.
<background> Matrix inverses in the traditional sense: (A) * x = b The inverse (~A) and the original matrix (A) should have these properties: (A) * (~A) * (A) = (A), or more generally: (A) * (~A) = (I) the identity matrix. Just as: (~A) * (A) * (~A) = (~A), or more generally: (~A) * (A) = (I) Matrices that are "singular" (where one or more equations is a combination of other equations) or that aren't "square" (having the same number of equations as unknowns) are not generally solvable by traditional methods. May those methods Rest In Peace. </background> When I use my matrix routines I expect: x = (~A) * b, no matter what the original (A) was... sparce, singular, non-square I don't use return codes to indicate problems with doing an inverse... I just do the inverse. I haven't found a matrix yet that I couldn't invert (the exception might be a matrix entirely consisting of 0.0 - but even that should work - it would just be a check on boundary conditions). The matrix routine I attached last time would provide an inverse for any input matrix. It really shouldn't matter if the matrix is singular or not. If the matrix is singular, it just means there's more than one equation. Using the attached routines would return the inverse, and using one of the other methods would return a matrix that represents the null-space of the original matrix. If the null-space matrix is identically zero, it just means the original matrix was not singular, and there was only one solution for the original problem. The general solution (A12) would then be the (~A) exactly. To users of matrices, it might not matter if there were multiple solutions or not, only that they got a solution. Sampled data might have many more equations than unknowns, in which case the user can either ignore the extra data or take the least-squares solution provided. The WishList didn't mention anything about singular or non-square matrices, and the documentation for the matrix class indicated its problem with such. I'd happily work with someone from the list (James Stephenson? - saw his name on the WishList) to extend the library. I originally made this algorithm when combining Taylor's series expansions for doing numerical approximations to some of my favorite differential equation sets. The original idea I learned at my graduate school, but I haven't seen anyone else implement it. It's surprising, too, since that was over 15 years ago. If you want to take this offline - send a pm to rchuso on gmail.. rand huso On 8/23/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 8/23/05, rand huso <[EMAIL PROTECTED]> wrote: > > I've written a piece of code for working with matrices - oritinal > > version was early 1989 in Fortran77. Since I've recently started > > working with Java I tried converting some of my useful code (from my > > rather large C++ template), but I've run into a snag or two with the > > limited generics. The class uses double instead of T, and simple > > arrays instead of something like <ArrayList <ArrayList T>> where <T > > implements Numeric> or similar. I just couldn't make all that work > > yet. > > > > The attached code and JUnit test are self-explanatory. Please have a > > look and let me know what you think. Is it worth integrating some of > > this into the jakarta-commons math library for others to use? If not, > > suggestions would be welcome. > > Thanks for your interest in commons-math. The attachment did not make > it. It would be better to first post a little more info about what > exactly you would like to contribute (first look at the WishList), and > then attach code to Bugzilla tickets. See the instructions here: > http://jakarta.apache.org/commons/math/developers.html > > > > <note>I am still surprised to find any mathematics library that throws > > an exception when asked to invert a singular or non-square > > matrix.</note> > > Out of curiousity, what exactly would you expect the result to be? In > Java, we use exceptions rather than "return codes" or special return > values to indicate bad arguments or computational problems. The one > exception to this is the use of NaN to represent the result of invalid > floating point operations, which is more or less required by IEEE 454 > (which we adhere to pretty consistently in [math]). > > Phil > > --------------------------------------------------------------------- > 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]
