text
text copied to clipboard
add projection layer to roberta encoder
User may want to additionally project the features from encoder. This PR add support for projecting features to different dimensional space.
Codecov Report
Merging #1451 (157da8b) into main (aea6ad6) will decrease coverage by
0.37%. The diff coverage is42.10%.
@@ Coverage Diff @@
## main #1451 +/- ##
==========================================
- Coverage 86.38% 86.01% -0.38%
==========================================
Files 58 58
Lines 2226 2245 +19
==========================================
+ Hits 1923 1931 +8
- Misses 303 314 +11
| Impacted Files | Coverage Δ | |
|---|---|---|
| torchtext/models/roberta/modules.py | 78.08% <23.07%> (-4.34%) |
:arrow_down: |
| torchtext/models/roberta/model.py | 96.29% <83.33%> (-1.04%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update aea6ad6...157da8b. Read the comment docs.
Overall LGTM. It seems like we're getting a lot of code coverage warnings. Should we also add unit tests for the ProjectionLayer class?
Overall LGTM. It seems like we're getting a lot of code coverage warnings. Should we also add unit tests for the
ProjectionLayerclass?
Yes, I think it's a good idea. The models tests didn't really touch this part of the code since we are not projecting the encoder output for standard architectures. Though, it would be more like integration/smoke tests instead of unit-test. We also do not have unit tests for other modules as well, but they are covered well through our end-2-end model tests (we call them unit-tests for now, but as @mthrok commented in here, we are going to move them to integration tests as well).
Overall LGTM. It seems like we're getting a lot of code coverage warnings. Should we also add unit tests for the
ProjectionLayerclass?Yes, I think it's a good idea. The models tests didn't really touch this part of the code since we are not projecting the encoder output for standard architectures. Though, it would be more like integration/smoke tests instead of unit-test. We also do not have unit tests for other modules as well, but they are covered well through our end-2-end model tests (we call them unit-tests for now, but as @mthrok commented in here, we are going to move them to integration tests as well).
Gotcha this makes sense. We can have some followup tasks to add these integrations tests. Stamped!
@Nayef211 @parmeet Is this still relevant?