Skip to content
This repository has been archived by the owner on Oct 21, 2021. It is now read-only.

Performance Suggestion for adjacency_matrix #192

Open
onlyhalfwaytrue opened this issue Jul 1, 2015 · 10 comments
Open

Performance Suggestion for adjacency_matrix #192

onlyhalfwaytrue opened this issue Jul 1, 2015 · 10 comments

Comments

@onlyhalfwaytrue
Copy link

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 onlyhalfwaytrue changed the title SUGGESTION for adjacency_matrix Performance Suggestion for adjacency_matrix Jul 1, 2015
@kmsquire
Copy link
Contributor

kmsquire commented Jul 1, 2015

@onlyhalfwaytrue, why don't you try to come up with something and make a pull request?

@onlyhalfwaytrue
Copy link
Author

Sure, I can try to modify it, but I am still new to Julia so it will take me some time.

@kmsquire
Copy link
Contributor

kmsquire commented Jul 1, 2015

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!

@sbromberger
Copy link
Contributor

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).

@lindahua
Copy link
Contributor

lindahua commented Aug 4, 2015

We can allow additional input argument for users to specify the element type.

@kmsquire
Copy link
Contributor

kmsquire commented Aug 5, 2015

Julia main is moving toward specifying type parameters using Type{ElemType} constructors directly.

@sbromberger
Copy link
Contributor

@kmsquire how does that work, exactly? (Is there a link explaining the change somewhere?)

@kmsquire
Copy link
Contributor

kmsquire commented Aug 6, 2015

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[]).

@sbromberger
Copy link
Contributor

@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?

@kmsquire
Copy link
Contributor

kmsquire commented Aug 6, 2015

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.

KristofferC pushed a commit to KristofferC/Graphs.jl that referenced this issue Oct 9, 2021
KristofferC pushed a commit to KristofferC/Graphs.jl that referenced this issue Oct 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants