Preserve types when adding/subtracting Herm/Sym/UniformScaling

[dalum]

This PR implements some basic type–preserving methods to +, -, real and imag for Hermitian and Symmetric matrices, which are true by definition, and I believe were probably just left out due to oversight. In addition to making Hermitian/Symmetric matrices form a group under addition (geeky yay) it is also slightly faster (more yay!). The original reason for this PR, however, was due to some head–scratching over why I couldn't add a complex UniformScaling to a Hermitian matrix, which I believe should be pretty generically implemented here (using the AbstractArray constructor). I actually found that there was a test to check that it didn't work (added in this PR: #19228), but couldn't find a good argument why adding a complex UniformScaling to a Hermitian should throw, except that, well ... it did. So I also removed those two tests.

This should probably be two PRs, functionality wise, but hopefully the changes aren't too plentiful to review.

[andreasnoack]

Thanks for adding these. I've added a few comments. Please also add some tests for real and imag.

[andreasnoack]

Couldn't this just be

Suggested change

	function (+)(A::Hermitian, J::UniformScaling{<:Complex})
	(+)(A::Hermitian{T,S}, J::UniformScaling{<:Complex}) where {T,S} = S(A) + J

[fredrikekre]

That would result in two copies though. Maybe ... = (R = S(A); R .+= J; R).

[fredrikekre]

Or I guess

R = S(A); R[diagind(R)] .+= I.λ; R

since we can't broadcast UniformScaling.

[dalum]

@andreasnoack @fredrikekre I don't think this would be an ideal solution. We need to promote to a complex type before adding to the diagonal, so we would have to special case real Hermitian matrices. But the copytri! may be unnecessary, it was just the fastest conversion I could find.

[dalum]

Actually, the tests fail for S(A) when S is a SubArray, so copytri! is probably necessary here.

[andreasnoack]

Hm. This was what full used to do and we don't have a complete replacement. It was assumed that using type parameters or explicit constructor would be sufficient but your example is a case where a generic function would be better.

[dalum]

@andreasnoack Would you mind taking another look at this? I'm not sure if there is a better solution to the conversion issue. 🙂

[StefanKarpinski]

Yes, please!

[andreasnoack]

Just a small comment but except for that it looks ready. I would have been nice to avoid the calls to _return_type and instead rely on existing promotion but I couldn't come up with a better solution (i.e. one that didn't allocate more).

[kshyatt]

Can this be merged?

[StefanKarpinski]

Rerunning CI. @andreasnoack, please merge if CI passes and you feel this is in good shape.