[
https://issues.apache.org/jira/browse/SPARK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14389281#comment-14389281
]
Joseph K. Bradley commented on SPARK-6065:
------------------------------------------
I'm not sure what the best solution would be; I'm actually not sure what the
gcode implementation does. I would guess the most practical solution would be
to use some sort of space-partitioning data structure such as a
[Quadtree|http://en.wikipedia.org/wiki/Quadtree], but you could read more about
other options: [http://en.wikipedia.org/wiki/Nearest_neighbor_search]
As far as naming, I haven't thought of a good choice. If all else fails, we
could have something very explicit like:
{code}
class FastWord2VecModel extends Word2VecModel
class Word2VecModel {
def convertToFastModel: FastWord2VecModel
}
{code}
> Optimize word2vec.findSynonyms speed
> ------------------------------------
>
> Key: SPARK-6065
> URL: https://issues.apache.org/jira/browse/SPARK-6065
> Project: Spark
> Issue Type: Improvement
> Components: MLlib
> Affects Versions: 1.2.0
> Reporter: Joseph K. Bradley
>
> word2vec.findSynonyms iterates through the entire vocabulary to find similar
> words. This is really slow relative to the [gcode-hosted word2vec
> implementation | https://code.google.com/p/word2vec/]. It should be
> optimized by storing words in a datastructure designed for finding nearest
> neighbors.
> This would require storing a copy of the model (basically an inverted
> dictionary), which could be a problem if users have a big model (e.g., 100
> features x 10M words or phrases = big dictionary). It might be best to
> provide a function for converting the model into a model optimized for
> findSynonyms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
