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
It seems like whenever the custom vector-type is <:AbstractArray, and has IndexLinear indexing style, we eagerly assume that it can be treated as if it is an Array, taking this path in the code for basistransform!. I think it would probably be more reasonable to have <:DenseArray or even just <:Array there, as we are no longer adhering to the VectorInterface set of allowed operations there.
For example, similar is being used instead of zerovector (
Additionally, there really is no guarantee that AbstractArrays are efficiently indexable (or the indexing even means the same thing).
For example in MPSKit (where I ran into this issue), we have that QuasiParticle states subtype AbstractVector, because you can index into them by site, while we also have that they are elements of a vectorspace, for which we overload VectorInterface. While this design might be questionable, I would still expect KrylovKit to use the VectorInterface methods, instead of the AbstractVector methods.
[Edit] Actually, the reason it was going wrong is that in the Multiline tests, we used a RecursiveVec for the different lines, which I now changed for a regular Vector, thus changing this to <:DenseArray or <:Array also does not suffice.
The text was updated successfully, but these errors were encountered:
I am certainly happy to further restrict this to DenseArray, or maybe even just Array, as we want to exclude GPU arrays, and this condition is probably one of the only reasons why we depend on GPUArraysCore.jl. Furthermore, I am also happy to see similar replaced with zerovector.
I will try and have a look at it later this week. <:DenseArray actually does not really solve the problem, I think it would even have to be <:DenseArray{<:Number}, as the case I am having is Vector{Quasiparticle}, which is dense.
It seems like whenever the custom vector-type is
<:AbstractArray
, and hasIndexLinear
indexing style, we eagerly assume that it can be treated as if it is anArray
, taking this path in the code forbasistransform!
. I think it would probably be more reasonable to have<:DenseArray
or even just<:Array
there, as we are no longer adhering to theVectorInterface
set of allowed operations there.For example,
similar
is being used instead ofzerovector
(KrylovKit.jl/src/orthonormal.jl
Line 336 in 1b175b7
KrylovKit.jl/src/orthonormal.jl
Line 342 in 1b175b7
isbits
types.Additionally, there really is no guarantee that
AbstractArray
s are efficiently indexable (or the indexing even means the same thing).For example in MPSKit (where I ran into this issue), we have that
QuasiParticle
states subtypeAbstractVector
, because you can index into them by site, while we also have that they are elements of a vectorspace, for which we overloadVectorInterface
. While this design might be questionable, I would still expect KrylovKit to use theVectorInterface
methods, instead of theAbstractVector
methods.[Edit] Actually, the reason it was going wrong is that in the
Multiline
tests, we used aRecursiveVec
for the different lines, which I now changed for a regularVector
, thus changing this to<:DenseArray
or<:Array
also does not suffice.The text was updated successfully, but these errors were encountered: