Yeah it's a tricky one. I agree with the functionality, because the QR decomposition can happily operate on a singular matrix. R will be singular if A is, AFAIK. So the singularity threshold business belongs more in the bit that uses R, yes.
The same could be said of the SVD. But it provides no singularity threshold parameter. Not suggesting changing that here, let's put it aside. Cholesky doesn't need a singularity threshold, but takes other thresholds in its constructor. That's OK since they are relevant to the decomposition. Same for LU -- it needs a singularity threshold because the LU decomposition can proceed but only to a point if the matrix is singular. (This is at the limit of my understanding.) EigenDecomposition resembles QR in this respect, as far as they are implemented here. This argues for them to treat arguments similarly. I suppose the best thing would be to move the threshold to getSolver() in both cases. This seems a better design, and no more trouble than, dealing with the problem of the old deprecated constructor and putting the arguments in the decomposition constructor in both places. I suppose it's also reasonable to punt and not add this threshold just now. Any more thoughts? On Wed, Oct 23, 2013 at 1:14 PM, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > Hi Sean, > > while looking at the QRDecomposition, it is interesting that the threshold > value provided to the constructor of QRDecomposition is only used to pass > it on the the Solver created by getSolver(). > > Imho, it would be more logical to chose the singularity threshold when > calling getSolver() for the respective decomposition, that way we could > also add it to the EigenDecomposition class. > > Thomas > > > On Wed, Oct 23, 2013 at 1:23 PM, Sean Owen <sro...@gmail.com> wrote: > >> In MATH-1045 (https://issues.apache.org/jira/browse/MATH-1045) we have >> discussed adding a zero threshold tolerance to EigenDecomposition just >> like QRDecomposition has. This involves adding a new constructor with >> a new double parameter. >> >> Just one problem: there's already such a constructor: >> >> /** >> * Calculates the eigen decomposition of the given real matrix. >> * >> * @param matrix Matrix to decompose. >> * @param splitTolerance Dummy parameter (present for backward >> * compatibility only). >> * @throws MathArithmeticException if the decomposition of a general >> matrix >> * results in a matrix with zero norm >> * @throws MaxCountExceededException if the algorithm fails to >> converge. >> * @deprecated in 3.1 (to be removed in 4.0) due to unused parameter >> */ >> @Deprecated >> public EigenDecomposition(final RealMatrix matrix, >> final double splitTolerance) >> throws MathArithmeticException { >> this(matrix); >> } >> >> Reusing this constructor would introduce a functionally incompatible >> change, as the previous meaning of this value was different. >> >> What are people's thoughts on proceeding anyway for a minor point >> release like 3.3? >> Or, best saved for 4.x? >> >> Sean >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
