Awesome progress. Thanks much!
On Sun, Apr 14, 2013 at 1:27 PM, Gokhan Capan <[email protected]> wrote: > 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 <[email protected]>wrote: > >> >> On Sun, Apr 14, 2013 at 11:59 AM, Gokhan Capan <[email protected]> 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 >
