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

support AbstractVector #41

Open
stevengj opened this issue Dec 24, 2020 · 1 comment
Open

support AbstractVector #41

stevengj opened this issue Dec 24, 2020 · 1 comment

Comments

@stevengj
Copy link

Rather than declaring arguments (and struct fields) as Vector{IntPoint}, it would be more generic to allow AbstractVector{IntPoint}. This can still be passed to C libraries as long as it supports a pointer conversion, and you could check that the stride(array,1) == 1 so that it is contiguous — these will throw a MethodError for array types that don't support these operations.

(It also might be convenient to use const IntPoint = SVector{2,Int64}.)

See also this discourse discussion

@plut
Copy link
Collaborator

plut commented Jan 8, 2021

I agree that passing vectors instead of structures is much better (I wrote some wrappers in my own code), since vectors natively support linear algebra for example.

However for point types there are two and a half possibilities that come to mind that would be even better than using a SVector{2,Int64}:

  • use a labelled vector (https://github.com/SciML/LabelledArrays.jl), or
  • even more Julian: use an abstract type (StaticArray{Tuple{2}} comes to mind — this would allow both SVector and labelled vectors).
  • also, the coordinate type should also be left open (I use some fixed-point real numbers), as long as it is 64 bits long. This can even be enforced on the Julia side using type traits (dispatching via Val(sizeof(T))).

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

No branches or pull requests

2 participants