Add parameter from_topn in evaluate_word_analogies

[divyanx]

from_topn will mark correct if the expected vector is not necessarily the most similar but among to from_topn most similar.

Useful for the evaluation of vectors like confusion vectors, in which any of the top two results match then it is marked correct.

[piskvorky]

from_topn will mark correct if the expected vector is not necessarily the most similar but among to from_topn most similar.

Useful for the evaluation of vectors like confusion vectors, in which any of the top two results match then it is marked correct.

I have no idea what you're saying, what you're trying to do. Can you rephrase?

[divyanx]

So, in the evaluation of word2vec, we apply analogy questions and the resultant vector should be closest to the actual answer then only it will be marked correct.
For example, V = King - Man + Woman, if the answer will be closest to Queen then only we will mark it correct. But suppose i want that if we find few closest vectors to V, and suppose we get {Princess, Queen, Prince...}, then my criteria of marking correct will be if they come in topn most similar, then also we will say it as correct.

I guess you get my idea @piskvorky , it's not very useful for classical word2vec, but for vectors like confusion2vec and other such vectors in which there are more dimensions (like other than semantic and syntactic meanings like acoustic confusability in word2vec), then this criterion of testing can be very useful.

You can suggest implementations and variable names and i can change them accordingly.

[gojomo]

I can understand why some projects might want a looser "@n" test of whether a model does well at analogies. And, this patch seems to achieve that.

But, the logic in the surrounding method for applying all the various caveats – case-insensitivity, limited range-of-vocab, ignoring words in analogy – already strikes me as somewhat convoluted. Adding this new looser-match as a loop-counter, with two more break-branches, makes it worse. If any new capabilities are layered-in here, I'd prefer to see them with some refactoring that makes the code, & many contrasting evaluation-possibilities here, more clear.