-
Notifications
You must be signed in to change notification settings - Fork 15
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
Migrate away from tf1 #125
Comments
@kiudee pointed me to https://github.com/skorch-dev/skorch on #119. We could also build on top of that library, which may do some of the work for us so that we only have to specify the model structure. I'm not entirely sure how much it gives us over directly interacting with |
I feel like we can't put this off much longer. tf1 is becoming more and more outdated. It doesn't make much sense to continue with #116, since most of the changes are model-specific details now which might change anyway with a partial rewrite. I have been looking into pytorch and tf2 a bit. I'm tending slightly towards pytorch. I could try to rewrite a part of our codebase (I'm thinking |
I agree - the dependency restrictions also become cumbersome to work with (other libraries may require more recent versions). I would also tend towards pytorch. In addition we can simplify some of the learners quite a bit using convolutions. Here is some experiment I did with FATE:
|
Yes, but there have been breaking changes so it would have to be a major release.
Yeah there is a lot of potential for simplification. Your experimental code is interesting, I'll see if I can incorporate some of that into my work. In #164 I'm experimenting with a composition style, where your can specify different kinds of (rank-n) utility functions and have different classes to compose them. I think that might make things simpler and end up in a nicer structure than the current inheritance-based one. |
Yes, I think this is warranted. I would say we should create a release candidate before finalizing it and test it. |
Made a mistake in the annotation of #170, this is not fixed. |
There has been some internal discussion about this, but I think its time to also open an issue about it. We are still using tensorflow 1, which has been outdated for a while now. Switching to tensorflow
2
would be a significant effort, since the underlying model fundamentally changed (there is no explicit graph construction anymore). At that point, it may be worth evaluating switching topytorch
instead.pytorch
is a newer, very popular autodiff framework.This article comes to the conclusion that
Here's another relevant article. Overall it seems to me that
pytorch
is the more future-proof choice, and if we're going to have to rewrite a lot of the code anyway we might as well switch. I do not have any practical experience inpytorch
yet though, that's just what I could determine from other's opinions and first impressions.We should also think about how we want to do the transition. This is a major undertaking and probably will take a while. Should we support
tf1
andnewthing
in parallel? Gradually move models tonewthing
(thereby having mixed support)? Fork the project? Work on one big PR/branch, effectively blocking most other work for the time due to potential conflicts?The text was updated successfully, but these errors were encountered: