-
Notifications
You must be signed in to change notification settings - Fork 149
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
Should we introduce a guideline for decoupling models and training code? #447
Comments
I agree, to make models and datasets reusable they should ideally be separate library projects that are composed together to form specific examples. We've been working towards this in simpler cases, such as for the image classification models, where we've separated the models into the ImageClassificationModels library target and reusable dataset wrappers into the Datasets target. This makes something like the ResNet-CIFAR10 example consist almost entirely of a training loop (and we'll even be replacing that with a reusable abstraction in the near future). Some models have taken a little more work to pull apart, such as our text models, but even they are being cleaned up to be generalized. If you wanted to start work on an general-purpose image segmentation model library target, or even one specific to U-Nets, I'd be totally behind that. What we've done with the ImageClassificationModels target might be a template for how this could go, or there might be a different way to approach these models. |
Unfortunately I have very limited time for my S4TF fun, but I'm into making stuff reusable. My current priority is to get #365 merged and then I will try to decouple models/layers from there into reusable libraries so that both projects (CycleGAN and pix2pix) could mix and match models/approaches. |
It sounds like we're on the same page as far as organization, and I totally agree with getting pix2pix in to match with CycleGAN, then generalizing the model. I'll close this out as a result, but thanks for bringing it up. |
I see that most of current model implementations come in a form of highly-specialized command-line app. It usually can only perform training on a hardcoded dataset or a specific task. However I can see users (including myself) wanting to just grab a U-Net model from say #365 and reuse it for another projects.
I think what we should do is to introduce two targets for each model: a library and an executable. A library should be designed with
public
interfaces and an executable should be an example on how to use the library.I think this will make swift-models repo much more convenient because now it is mostly used for reference or implementation example.
The text was updated successfully, but these errors were encountered: