Bring over tests from ChainRulesCore. And report possible bug. #1228
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We previously had these tests in ChainRulesCore (@mcabbott wrote them)
They stated breaking in julia 1.9, and some debugging determined that it was because StaticArray.jl has changed which method is hit. (This is good)
They test the behavour as it was for without the ProjectTo overload, just hitting our generic functionality.
They now error. because of a change (which might be a correct change) which we can't fix in CRC so I think these tests belong here
The failure boils down to:
I kind of think this particular function all should work: projecting a 1 row
Matrix
onto aTranspose{StaticVector{...}}
makes perfect sense. It is the kinda thing that comes up relatively often when writing rules and the adjoint type hasn't been written with care -- which is somethingProjectTo
is often used to fix.And it did used to work.
I believe the difference is that
ProjectTo{StaticArray}
no longer storesaxes
in away that works withProjectTo{Transpose}
's expectation: https://github.com/JuliaDiff/ChainRulesCore.jl/blob/main/src/projection.jl#L424We really need to document how to implement an
ProjectTo
and what the requirements are.E.g. here seems to assume if its an array we always store the axes in a
.axes
field and that that field can be indexed into.(Help working this out and documenting it would be appreciated)
without the extension loaded:
vs with the extension loaded:
I think that is the key change. though i might not have it quite right.
@avik-pal can I leave this PR with you to decide what behavior is correct and to make sure it is tested appropriately?