More conversion in PDMat

[timholy]

This allows one to convert both the eltype and matrix type. In practice, my main use for this is to support generic programming with both Matrix and StaticArrays.SMatrix.

Perhaps the only potentially-controversial aspect is moving the dimensionality check into the inner constructor. If we want to make it impossible to construct an inconsistent PDMat, that's where it has to be.

[devmotion]

Did you check whether this is covered by #188? At least it seems the matrix element type is restricted in the same way in #188.

[timholy]

Did you check whether this is covered by #188? At least it seems the matrix element type is restricted in the same way in #188.

The eltype restriction is just a small cleanup. The key aspect of this is the "constructor cascade" that supports conversion/coercion via PDMat{T}(args...) or PDMat{T,S}(args...). This is needed to support, e.g., push!(pdmats, pdmat) where eltype(pdmats) may not be identical to typeof(pdmat). #188 doesn't add these methods.

Also, #188 is a pretty deep change, and it's been open for more than a year. I hoped this could get merged quickly and a new release made.

[timholy]

Concretely, if one runs the test block "test the functionality" from this PR on master, one gets this (with T = Float32):

Testing PDMat{Float32, Matrix{Float32}} of size (3, 3)
PDMat from Matrix: Error During Test at REPL[8]:7
  Got exception outside of a @test
  MethodError: no method matching (PDMat{Float64})(::Matrix{Float32})
  Stacktrace:

and several similar errors.

[timholy]

If you're OK with it, I'd plan to solve the failure on Julia 1.0 by dropping support for anything before 1.10. Since this package is still in 0.x releases, we don't have to bump the minor version to do so.

The CI error on nightly is unrelated to this PR.

[devmotion]

If you're OK with it, I'd plan to solve the failure on Julia 1.0 by dropping support for anything before 1.10.

I'm fine with that but I'm still curious which and why some of the changes are problematic on Julia 1.0.

[timholy]

I'm fine with that but I'm still curious which and why some of the changes are problematic on Julia 1.0.

I'm a little puzzled about that as well. But it's only the @allocated test that fails and that is indeed pretty sensitive (especially in old Julias) to minor details. Looking at the produced code

julia> @code_typed PDMat(S, C)
CodeInfo(
22 1 ─ %1 = %new(PDMat{Float64,SArray{Tuple{4,4},Float64,2,16}}, mat, chol)::PDMat{Float64,SArray{Tuple{4,4},Float64,2,16}}                       │╻ Type
   └──      return %1                                                                                                                             │
) => PDMat{Float64,SArray{Tuple{4,4},Float64,2,16}}

it's a little weird that it allocates at all.

I dunno, I am not personally that interested in pursuing why Julia 1.0 allocates in this circumstance.

[timholy]

You may want to think about whether we want a5c0ce8, I added it hoping that it would fix the allocations on Julia 1.0. But it doesn't, and it makes the code more verbose; on the other hand, it tightens the applicability of the methods to things that can actually work. Let me know whether you'd prefer to drop it or keep it.