Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractArray vector subtypes get wrongly handled #100

Closed
lkdvos opened this issue Nov 10, 2024 · 2 comments · Fixed by #103
Closed

AbstractArray vector subtypes get wrongly handled #100

lkdvos opened this issue Nov 10, 2024 · 2 comments · Fixed by #103

Comments

@lkdvos
Copy link
Collaborator

lkdvos commented Nov 10, 2024

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 (

let b2 = [similar(b[1]) for j in 1:n], K = K, m = m, n = n
), and then we index into these vectors (
b2j[i] = zero(b2j[i])
), which fails for non-isbits types.

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.

@Jutho
Copy link
Owner

Jutho commented Nov 10, 2024

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.

@lkdvos
Copy link
Collaborator Author

lkdvos commented Nov 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants