mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: factorization machines as new project
Date Sun, 14 Apr 2013 21:17:22 GMT
Awesome progress.

Thanks much!

On Sun, Apr 14, 2013 at 1:27 PM, Gokhan Capan <> 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 <>wrote:
>> On Sun, Apr 14, 2013 at 11:59 AM, Gokhan Capan <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message