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

Indexability of vertices and neighbors #282

Open
gdalle opened this issue Jul 5, 2023 · 6 comments
Open

Indexability of vertices and neighbors #282

gdalle opened this issue Jul 5, 2023 · 6 comments
Labels
question Further information is requested

Comments

@gdalle
Copy link
Member

gdalle commented Jul 5, 2023

In the PRs done by @simonschoelly to test on generic graphs, he frequently ran into trouble because collections like vertices(g) or neighbors(g, v) were not indexable. This explains the appearance of the function collect_if_not_vector throughout the code.

@etiennedeg what will this behavior look like in GraphsBase?

@gdalle gdalle added the question Further information is requested label Jul 5, 2023
@gdalle
Copy link
Member Author

gdalle commented Jul 5, 2023

See #270

@etiennedeg
Copy link
Member

Very good question, for the moment, the collect_if_not_vector sounds like the best workaround but feels a bit clunky, maybe it can be refined by checking outneighbors implement indexing methods ?

@simonschoelly
Copy link
Contributor

The collect_if_not_vector also has the downside, that we might unnecessary allocate some things. What we maybe want, is that these methods return something that implements the Indexing operators. So we could require that all these methods return something that is an AbstractVector. Can we think of some cases were that would be a to strict of a requirement?

One downside I already see is the neighbors function for directed graph, Where we have to take the union of the in and out neighbors. On the other hand, this is such a rare case, maybe we can just create some weird wrapper type that has a non-constant indexing time. We already allocate a whole vector at the moment for SimpleDiGraph, so we also pay a cost there.

@simonschoelly
Copy link
Contributor

Very good question, for the moment, the collect_if_not_vector sounds like the best workaround but feels a bit clunky, maybe it can be refined by checking outneighbors implement indexing methods ?

This might be possible with something like Base.hasmethod - I am just always a bit careful with such reflection based methods, as I think I run into some world age issues when I had much less experience with Julia. But the julia standard library also seems to use it, so maybe it is indeed possible.

@simonschoelly
Copy link
Contributor

Something like

function collect_if_not_indexable(vs)
    if Base.hasmethod(getindex, (typeof(vs), Integer))
        return vs
    else
        return collect(vs)
     end
 end

@gdalle
Copy link
Member Author

gdalle commented Jul 5, 2023

Either that or we wrap it inside a struct that does indexing by enumeration, and we pay non-constant indexing cost

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

No branches or pull requests

3 participants