I think that this contract has migrated a bit from the first starting point.
My feeling is that there is a de facto contract now that the matrix slice is a single row. Sent from my iPhone On Jun 23, 2013, at 16:32, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > What does Matrix. iterateAll() contractually do? Practically it seems to be > row wise iteration for some implementations but it doesnt seem > contractually state so in the javadoc. What is MatrixSlice if it is neither > a row nor a colimn? How can i tell what exactly it is i am iterating over? > On Jun 19, 2013 12:21 AM, "Ted Dunning" <ted.dunn...@gmail.com> wrote: > >> On Wed, Jun 19, 2013 at 5:29 AM, Jake Mannix <jake.man...@gmail.com> >> wrote: >> >>>> Question #2: which in-core solvers are available for Mahout matrices? I >>>> know there's SSVD, probably Cholesky, is there something else? In >>>> paticular, i need to be solving linear systems, I guess Cholesky should >>> be >>>> equipped enough to do just that? >>>> >>>> Question #3: why did we try to import Colt solvers rather than actually >>>> depend on Colt in the first place? Why did we not accept Colt's sparse >>>> matrices and created native ones instead? >>>> >>>> Colt seems to have a notion of parse in-core matrices too and seems >> like >>> a >>>> well-rounded solution. However, it doesn't seem like being actively >>>> supported, whereas I know Mahout experienced continued enhancements to >>> the >>>> in-core matrix support. >>>> >>> >>> Colt was totally abandoned, and I talked to the original author and he >>> blessed it's adoption. When we pulled it in, we found it was woefully >>> undertested, >>> and tried our best to hook it in with proper tests and use APIs that fit >>> with >>> the use cases we had. Plus, we already had the start of some linear apis >>> (i.e. >>> the Vector interface) and dropping the API completely seemed not terribly >>> worth it at the time. >>> >> >> There was even more to it than that. >> >> Colt was under-tested and there have been warts that had to be pulled out >> in much of the code. >> >> But, worse than that, Colt's matrix and vector structure was a real bugger >> to extend or change. It also had all kinds of cruft where it pretended to >> support matrices of things, but in fact only supported matrices of doubles >> and floats. >> >> So using Colt as it was (and is since it is largely abandoned) was a >> non-starter. >> >> As far as in-memory solvers, we have: >> >> 1) LR decomposition (tested and kinda fast) >> >> 2) Cholesky decomposition (tested) >> >> 3) SVD (tested) >>
