You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, in BlockDiagonal{T,V}, T is the eltype of the blocks and we require all blocks to have the same eltype (i.e.all(eltype.(blocks) .=== T)).
However, we could allow blocks to have different eltypes, with T being the common eltype. (i.e.all(eltype.(blocks) .<: T)), with T = promote_type(map(eltype, blocks)...)`).
This is similar in spirit to #56 which generalises the V type parameters, but unlike #56, generalising T would be non-breaking as it'd only affects cases that are currently errors (and unlike #56 it doesn't change the meaning of T)
Currently, in
BlockDiagonal{T,V}
,T
is the eltype of the blocks and we require all blocks to have the same eltype (i.e.all(eltype.(blocks) .=== T)
).However, we could allow blocks to have different eltypes, with
T
being the common eltype. (i.e.all(eltype.(blocks) .<: T)
), with
T = promote_type(map(eltype, blocks)...)`).(suggested at https://github.com/invenia/BlockDiagonals.jl/pull/56/files#r576718519)
This is similar in spirit to #56 which generalises the
V
type parameters, but unlike #56, generalisingT
would be non-breaking as it'd only affects cases that are currently errors (and unlike #56 it doesn't change the meaning ofT
)The main downside seems to be that this causes inference problems for
rrule
s, which presumably has a performance cost for code using AD. See https://github.com/invenia/BlockDiagonals.jl/pull/56/files#r577136826The text was updated successfully, but these errors were encountered: