Ok then, now my roadmap is: Tomorrow I will re-submit the Lucene Matrix patch with support for multiple fields (Probably SRM sub-classed version of multi-matrices after testing it).
Multi-vectors is another thing that the community may be interested in (maybe to help them to assign a row of multi-matrices), I can submit it upon request after asking in dev-list. This week I will refactor the factorization machine with SGD implementation to make it operate on a single matrix as input, and then try it on a dataset. Then we can talk on submitting a diff for the algorithm. (And possible use cases for the algorithm, e.g. integration with Recommender interface) Then the persistent version of the LuceneMatrix and an InputFormat on top of it will come. Ted, Robin, Thank you for all responses, all helped me a lot. On Sun, Apr 14, 2013 at 11:05 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > > On Sun, Apr 14, 2013 at 11:59 AM, Gokhan Capan <gkhn...@gmail.com> wrote: > >> - I strongly suspect that you don't need to implement VectorSuperView. >>> Won't the normal handling of viewRow in AbstractMatrix work here? Speed >>> may be an issue, but all speed questions should be decided by measurements. >>> >> It was because the iterateNonZero didn't work, and this was intended to >> work on mostly sparse matrices. I think (but I'm not sure yet) making this >> ConcatenatedMatrix a direct subclass of SparseRowMatrix would solve this >> problem, that may be an option. (I personally needed this multi-vectors >> anyway, so I implemented it) >> > > This is an interesting option (sub-classing from SRM). > > Having the multi-vectors is nice as you say. My only point was that they > weren't necessarily implied by the need for row views. I am not sure which > would be faster in the end. > > > -- Gokhan
