Documentation Update Part 2#200
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
There is still an open discussion about ruff checks SIM102, SIM117, and E501.
|
|
Does this https://growingnet.github.io/gromo/auto_examples/plot_growing_container_tutorial.html correspond to Alex and Sebastien first suggestion ? If not, we could discuss what is missing. |
|
For the example, what I would recommend is to create a branch then you can merge this branch ( Thank you for changing |
TODO:
GrowingDAGSébastian suggestions:
Alex suggestions:
Reminder to address Issues:
*_volumeinGrowingModuleis wrong #153in_features,in_volume,input_shape... #140test_GrowableDAG.py#36Notes for documentation:
I managed to grow layers that have an average pooling in between. Use case: GrowingDAG -> downsampling -> GrowingDAG. Now the hidden dimensions between GrowingContainers can be increased.
Constraints: (1) each GrowingDAG starts and ends with a MergeGrowingModule so effectively the order of operations is Merge -> Merge. (2) the first MergeGrowingModule needs to be aware of the correct output shape in order to grow so the pooling operation needs to be inside the post_merge_function. It is not possible to grow if it appears directly in the forward function. (PR #179)
I fixed the issue with the GlobalAveragePooling by correcting the padding. Now we can also grow Use case: MergeGrowingModule -> GlobalAveragePooling ->MergeGrowingModule. (PR #179)
I found a way to also grow Use case: Conv -> GlobalAveragePooling -> Flatten -> Lin. For the GrowingDAG Conv -> Lin is equivalent to Conv -> Conv1x1.
Constraints: (1) the global average pooling is still in the post_merge_function (2) the flattening CANNOT be in the post_merge_function as it does not allow the unfolding of the activity (reminder: the activity is the post-activity and if we flatten in the module the activity is flat) (no, I cannot just not unfold the activity because it will change the tensor_s shape). Instead Flatten should be called in the forward function. (3) Because this creates a shape mismatch in ωσ(αx) I added a new attribute in Conv2dMergeGrowingModule that keeps track of potential reshapes (e.g. flatten before a linear layer) and applies it when necessary. One of this situations is the calculation of the output_volume of the module. (PR #177) (4) When growing Conv -> Lin the previous layers α should use the tensor_s of the last Conv2dMergeGrowingModule and the next layers ω should use the tensor_s of the first LinearMergeGrowingModule. So now the second MergeGrowingModule in a Merge -> Merge sequence is always updating the shape of its tensor_s. (PR #179)