Performance Suggestion for adjacency_matrix
Opened this issue · 10 comments
Since the adjacency matrix representation will be used primarily by people who are trying to do algebraic graph theory, it would make sense to not make a boolean array and rather actually make a float array of 1.0s and 0.0s so when multiplying, the user does not lose performance due to type changes.
@onlyhalfwaytrue, why don't you try to come up with something and make a pull request?
Sure, I can try to modify it, but I am still new to Julia so it will take me some time.
It's likely that you working on it would be the fastest way for it to get done. If you submit it as you're working on it with "WIP" (work in progress) in the title, and ask for help or review, you'll usually get useful feedback as well!
You might take a look at https://github.com/JuliaGraphs/LightGraphs.jl/blob/9d47ee186a0c09c926d9975e67ecd8c1d38eb363/src/linalg.jl#L2-L28 for the way LightGraphs does it - it allows you to specify the datatype of the adjacency matrix (defaults to Int).
We can allow additional input argument for users to specify the element type.
Julia main is moving toward specifying type parameters using Type{ElemType} constructors directly.
@kmsquire how does that work, exactly? (Is there a link explaining the change somewhere?)
From https://github.com/JuliaLang/julia/blob/master/NEWS.md#language-changes:
• Arrays can be constructed with the syntax Array{T}(m,n) (#3214, #10075).
• Dict literal syntax [a=>b,c=>d] is replaced by Dict(a=>b,c=>d), {a=>b} is replaced by Dict{Any,Any}(a=>b), and (K=>V)[...] is replaced by Dict{K,V}(...). The new syntax has many advantages: all of its components are first-class, it generalizes to other types of containers, it is easier to guess how to specify key and value types, and the syntaxes for empty and pre-populated dicts are synchronized. As part of this change, => is parsed as a normal operator, and Base defines it to construct Pair objects (#6739).
It's not clear from this description, but you can also construct empty Vectors directly with Vector{Int}() (although this was already pretty easy with Int[]).
@kmsquire well, yes - but that's for object/variable instantiation. Is there a similar syntax for functions or is the canonical behavior still to pass a type in as an argument when you want the function to be able to return instances of variable types?
Not as far as I know, although I haven't explored the limits if the call function yet.
Sorry, I had forgotten that we were talking about the adjacency_matrix function. I was somehow expecting this to be for a type constructor. Oh, well.