-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fastText models from 2.3.0 can't be loaded in 3.0.0 #1642
Comments
Or another idea to solve this: Can you create a utilsscript that transforms a 2.3.0 model into a 3.0.0 model? |
@Liebeck Thanks for the report I think possible to check this in Can you fix this bug and create PR @Liebeck @chinmayapancholi13? |
I'm not sure if I understand enough of gensim's architecture to contribute a quick fix. I might be able to have a further look at in January 😐 |
@Liebeck Thanks for reporting this issue! Seems to be a problem in the load function. @menshikh-iv Hey Ivan! I am a little occupied in this week. So I can take a look at this and try to get it resolved in the following week. I hope this is fine. I'll give an update about my progress here. :) |
It will be great @chinmayapancholi13, I'm glad to see you here again :) |
Fixed in #1723 |
Description
I do have a compatibility issue with fastText and version 3.0.0. In version 2.3.0, I used the fastText C++ wrapper to train a model based on the code available at that time from
https://github.com/RaRe-Technologies/gensim/blob/develop/docs/notebooks/FastText_Tutorial.ipynb
This code works in 2.3.0
In 3.0.0 it fails due to
Expected Results
I expected the model from 2.3.0 to be loadable in 3.0.0. I was able to get my code working by downgrading to 2.3.0. I made some evaluations with trained models and I'd be happy to still use these models. Otherwise, I'm stuck at gensim 2.3.0
@menshikh-iv
I guess this has something to do with this commit 6e51156#diff-cd6e655ec64f5b3927aa96ce5d006207 and split 'syn0_all' into 'syn0_vocab' and 'syn0_ngrams'. I'm guessing that models trained with 2.3.0 aren't compatible with version 3. Is it possible that the load method checks whether the model was trained in 2.3.0, loads the 2.3.0 method, and internally makes the same split?
The text was updated successfully, but these errors were encountered: