You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We are planning to drop tensorflow/keras dependencies and switch to pytorch. This is a big breaking change and it will be on multiple critical pivot points in the code base. One of those points is the aydin.it level API that we use to serve current tensorflow/keras models. Currently, aydin.it.cnn has so much business logic that is tightly bounded with current unet/jinet keras implementations. For the sake of a more modular design we are planning to change this. Also we can refine our aydin.it level API to comfort any model that might be implemented with pytorch, not only CNNs.
Describe the solution you'd like
I am here suggesting to refactor/re-write a new API on aydin.it level to serve all models implemented with torch right now and future models. As a complementary change, also, I am suggesting to rename our module to a more generic name such as aydin.it.torch.
Describe alternatives you've considered
An alternative idea could be implementing a new module for each new pytorch model in aydin.it level package. This would clutter the aydin.it subpackage and cause code-duplication (probably) often. Another alternative could be sticking to old approach and keep extending the amount business logic implemented in aydin.it.cnn but as we already experience this is not really a sustainable option.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We are planning to drop tensorflow/keras dependencies and switch to pytorch. This is a big breaking change and it will be on multiple critical pivot points in the code base. One of those points is the
aydin.it
level API that we use to serve current tensorflow/keras models. Currently,aydin.it.cnn
has so much business logic that is tightly bounded with current unet/jinet keras implementations. For the sake of a more modular design we are planning to change this. Also we can refine ouraydin.it
level API to comfort any model that might be implemented with pytorch, not only CNNs.Describe the solution you'd like
I am here suggesting to refactor/re-write a new API on
aydin.it
level to serve all models implemented with torch right now and future models. As a complementary change, also, I am suggesting to rename our module to a more generic name such asaydin.it.torch
.Describe alternatives you've considered
An alternative idea could be implementing a new module for each new pytorch model in
aydin.it
level package. This would clutter theaydin.it
subpackage and cause code-duplication (probably) often. Another alternative could be sticking to old approach and keep extending the amount business logic implemented inaydin.it.cnn
but as we already experience this is not really a sustainable option.The text was updated successfully, but these errors were encountered: