Thank you. On Jun 23, 2013 6:16 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
> 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) > >> >
