-
-
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
Allow indexing with np.int64 in doc2vec - #1231 #1254
Conversation
Agree that it should be changed throughout doc2vec. |
I meant across the codebase, but after a quick search it seems this is the only place where this actually happens. Does the CI run the tests on multiple python versions? >>> l=[42, np.int32(42), np.int64(42)]
>>> [isinstance(x, numbers.Integral) for x in l]
[True, True, True]
>>> [isinstance(x, six.integer_types) for x in l]
[True, False, False] |
Okay, did some more testing and the last commit makes the most sense I think. |
Thanks for the changes across the broader codebase. New tests of The test failure in CI in |
Well, at this point I guess it's not just |
@bogdanteleaga Are you interested in adding tests to this PR? |
Sorry, it's been a really busy week and this one's not looking that great either. But I should be able to do it at the end of this one/start of next one. If anybody else wants to take it up faster than that that's ok as well. |
b7959d0
to
2874661
Compare
Added 2 simple tests for indexed corpus and word2vec. Not really sure how to test lda/at. Also I'm not completely sure on how to test other types(if that's wanted). I could yield all the different types and iterate over them, but it could make tests take longer. Let me know what you think. |
Thanks for the fix. I am not sure what is the point of having |
This PR attempts to fix #1231.
It also includes a drive-by fix for a warning that was thrown during tests that asked the
assertEquals
to be changed into anassertEqual
.As far as the fix itself goes, I am not completely sure this is sane and am willing to discard the PR. Indexing with
np.int32
works fine with the previous code and if indexing withnp.int64
is going to be allowed here, it might as well be allowed everywhere else, which is a way bigger change.However, this does fix the original issue as it has been presented.