Add LinearUnderScalingProperty

[PierreQuinton]

• Add LinearUnderScalingProperty
• Make all non-random LUS aggregator testers extend LinearUnderScalingProperty

I think that the code is self explanatory, we could if needed add a docstring to explain what this tests, but this is rather directly the LUS property. Note that Config seems to fail it, we need to investigate why (and on what matrices).

Note that UPGrad is not too good at this test, and it is the aggregator that pushed the atol to 0.008, this is probably due to linear approx.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ValerianRey]

I rebased your commits onto main (with the new input matrix generation). I chose to test LUS property on strong stationary matrices + matrices.

Now, ConFIG passes the LUS tests, so I added its property back in the documentation and I readded its LUS test. Are there special cases where ConFIG is not LUS in theory? @PierreQuinton

[ValerianRey]

Currently we use the following inputs:

• ExpectedStructureProperty: scaled_matrices + zero_matrices
• NonConflictingProperty: weak_stationary_matrices + matrices
• PermutationInvarianceProperty: matrices
• LinearUnderScalingProperty: strong_stationary_matrices + matrices

This is very confusing. In reality, the only "problematic" matrices are the scaled matrices. They make the NonConflictingProperty, PermutationInvarianceProperty and LinearUnderScalingProperty fail for most aggregators. But we could have:

• ExpectedStructureProperty: scaled_matrices + M
• NonConflictingProperty: M
• PermutationInvarianceProperty: M
• LinearUnderScalingProperty: M

with M = matrices + zero_matrices + weak_stationary_matrices + strong_stationary_matrices.
With this, all tests pass and coverage increases.

Of course, names could be improved. This could also come in another PR.

[ValerianRey]

There's something that is a bit weird in my opinion. For the PermutationInvarianceProperty, we do not test random aggregators, and therefore we do not have to reset any seed during its operations. For LinearUnderScalingProperty, we do test random aggregators and reset the seed in the middle of operations. I think we should either do one or the other.

I think we can consider random aggregators to be some kind of stateful aggregators whose state (the current random state) is held globally. I think we could improve our support for those aggregators in the future without touching the global state (messing with the torch seed) in the property testers. So IMO we should:

• Remove LinearUnderScalingProperty from RGW and PCGrad testers.
• Remove all lines related to storing and setting the seed in LinearUnderScalingProperty.