getproperty for Adjoint/Transpose wrappers

[jishnub]

This is the first step towards making adjoint/transpose return wrappers, and having optimized factorization defined for these wrappers. In this PR, only getproperty is defined for Adjoint/Transpose wrappers.

[andreasnoack]

Are we sure it's beneficial to return wrapped types instead of materializing them? The materialized versions should be quite cheap for many of the matrices here, no?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.15%. Comparing base (52775d6) to head (1a56721).
⚠️ Report is 32 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #97      +/-   ##
==========================================
+ Coverage   95.08%   95.15%   +0.06%     
==========================================
  Files           8        8              
  Lines         896      908      +12     
==========================================
+ Hits          852      864      +12     
  Misses         44       44              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[jishnub]

It should be cheap, but since the docstrings of adjoint and transpose suggest that these are lazy wrappers, and that the adjoint of an adjoint unwraps the parent, perhaps it's best to respect these properties. If possible, it's better to not materialize the matrices.

[andreasnoack]

I think the docstring is inaccurate. E.g. I believe adjoint(::Hermitian) is still a noop.

[jishnub]

I see, although adjoint(adjoint(H::Hermitian)) === H still holds. In any case, reducing memory allocation is perhaps a good idea? This might make it easier to port such matrices to GPUs and other memory-limited systems

[andreasnoack]

Reducing allocations is generally a good thing but my question is how much is reduced there. For a general toeplitz, you'd just swap the two vectors (e.g. in the real case), no?

[jishnub]

In the real Toeplitz case, this may not matter much, but there are other cases where this will save allocating one or two vectors

julia> C = Circulant(fill(2,1000));

julia> @btime adjoint($C);
  1.704 μs (2 allocations: 15.88 KiB)

julia> T = Toeplitz(fill(2im, 1000), fill(2im, 1000));

julia> @btime adjoint($T);
  2.658 μs (2 allocations: 31.50 KiB)

I'm only suggesting using a wrapper in cases where it would have allocated otherwise. Unfortunately, this would mean departing from the type hierarchy, but hopefully this may be mitigated by defining appropriate methods for the wrappers. I plan to add a benchmark script to track regressions. This is anyway a longer-term vision, and this PR should largely be harmless.

[andreasnoack]

Sure. Wrapped types just add a lot of complexity and also potential compilation overhead so it's just good to avoid them when it free or cheap enough.