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
This came up when I was trying to sort out the documentation. Right now, we have a Layers module which provides a lot of common functionality, like re-usable blocks and some utilities. But I realised that there are some inconsistencies:
Currently, while the inverted residual block functions live inside of the Layers module, the residual block functions are in plain old Metalhead.
Given that we export ViT and convolutional blocks from the Layers module, the residual block functions should also probably be moved here?
I also considered doing a drastic reduction of the module to only fundamentally re-usable layers – this would mean all the block functions would go out and leave only things like conv_bn, MHA and AdaptiveMeanMaxPool. This makes more sense from the perspective of the average user – someone who wants more functionality can just load Metalhead directly anyways.
The utilities don't really make sense in a Layers module (to be honest, they don't really make sense outside of the extremely specific use-cases of Metalhead) but have been documented there because of the fact that the layers needed them and they needed to go somewhere. If we go with the second suggestion in the previous point, this allows us to probably rework things to avoid documenting the utilities with the Layers, and create a separate section for developers who are more likely to need these anyways.
All of these changes in organisation would be breaking, which is why I am unsure how exactly we can implement these, and also the reason I am opening this issue to understand what the prevalent opinion is.
Reorganizing sounds like a good plan. We can have deprecations for anything in Layers that moves out and is unexported at the top level. If it is exported then I don't think it needs a deprecation.
Right now, we don't export anything at the top level from Layers 😅 This is probably because at the time I felt the Layers module was always going to undergo changes. Maybe we can look at what could possibly be exported once the re-organisation is done.
This came up when I was trying to sort out the documentation. Right now, we have a
Layers
module which provides a lot of common functionality, like re-usable blocks and some utilities. But I realised that there are some inconsistencies:Layers
module, the residual block functions are in plain old Metalhead.Layers
module, the residual block functions should also probably be moved here?conv_bn
, MHA andAdaptiveMeanMaxPool
. This makes more sense from the perspective of the average user – someone who wants more functionality can just load Metalhead directly anyways.Layers
module (to be honest, they don't really make sense outside of the extremely specific use-cases of Metalhead) but have been documented there because of the fact that the layers needed them and they needed to go somewhere. If we go with the second suggestion in the previous point, this allows us to probably rework things to avoid documenting the utilities with theLayers
, and create a separate section for developers who are more likely to need these anyways.All of these changes in organisation would be breaking, which is why I am unsure how exactly we can implement these, and also the reason I am opening this issue to understand what the prevalent opinion is.
cc: @ToucheSir @darsnack
PS: A very Happy New Year!
The text was updated successfully, but these errors were encountered: