Java Node class for a Graph
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I'm using ArrayList<Nodes>
to store adjacent nodes, and ArrayList<Integer>
to store the corresponding weights of the vertices. Is this efficient if I only use it for small inputs? Is it efficient for large inputs as well?
class Node
public ArrayList<Node> adjacent = new ArrayList<Node>();
public ArrayList<Integer> weights = new ArrayList<Integer>();
boolean visited;
java graph
 |Â
show 1 more comment
up vote
4
down vote
favorite
I'm using ArrayList<Nodes>
to store adjacent nodes, and ArrayList<Integer>
to store the corresponding weights of the vertices. Is this efficient if I only use it for small inputs? Is it efficient for large inputs as well?
class Node
public ArrayList<Node> adjacent = new ArrayList<Node>();
public ArrayList<Integer> weights = new ArrayList<Integer>();
boolean visited;
java graph
1
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
1
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
1
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should beprivate final List<Node> adjacent
(+ the necessary accessor methods)
â Marco13
Jan 20 at 21:09
 |Â
show 1 more comment
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I'm using ArrayList<Nodes>
to store adjacent nodes, and ArrayList<Integer>
to store the corresponding weights of the vertices. Is this efficient if I only use it for small inputs? Is it efficient for large inputs as well?
class Node
public ArrayList<Node> adjacent = new ArrayList<Node>();
public ArrayList<Integer> weights = new ArrayList<Integer>();
boolean visited;
java graph
I'm using ArrayList<Nodes>
to store adjacent nodes, and ArrayList<Integer>
to store the corresponding weights of the vertices. Is this efficient if I only use it for small inputs? Is it efficient for large inputs as well?
class Node
public ArrayList<Node> adjacent = new ArrayList<Node>();
public ArrayList<Integer> weights = new ArrayList<Integer>();
boolean visited;
java graph
edited Jan 16 at 14:19
Jamalâ¦
30.1k11114225
30.1k11114225
asked Jan 16 at 13:37
Bugs Buggy
1214
1214
1
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
1
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
1
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should beprivate final List<Node> adjacent
(+ the necessary accessor methods)
â Marco13
Jan 20 at 21:09
 |Â
show 1 more comment
1
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
1
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
1
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should beprivate final List<Node> adjacent
(+ the necessary accessor methods)
â Marco13
Jan 20 at 21:09
1
1
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
1
1
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
1
1
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should be
private final List<Node> adjacent
(+ the necessary accessor methods)â Marco13
Jan 20 at 21:09
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should be
private final List<Node> adjacent
(+ the necessary accessor methods)â Marco13
Jan 20 at 21:09
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
2
down vote
Is this efficient if I only use it for small inputs?
For small inputs, anything is efficient.
For big data, having each Node
as such a large object would be inefficient.
I depends what kind of actions you would do over the graph. If you access it sequentially, there can be also a linked implementation like:
class LinkedNode
public Node firstChild;
public Node nextSibling;
boolean visited;
Here's an alternative, without objects but with arrays instead:
int edgeWeights;
int edgeIndicies;
At the begin, edgeIndicies
will have values [0,1,2,...n]
.
Sorting the weights, you move the indicies instead, so if the indicies are the following:[5,7,9,...]
you know edgeWeights[5]
is the smallest, edgeWeights[7]
is the second smallest, ...etc.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
Is this efficient if I only use it for small inputs?
For small inputs, anything is efficient.
For big data, having each Node
as such a large object would be inefficient.
I depends what kind of actions you would do over the graph. If you access it sequentially, there can be also a linked implementation like:
class LinkedNode
public Node firstChild;
public Node nextSibling;
boolean visited;
Here's an alternative, without objects but with arrays instead:
int edgeWeights;
int edgeIndicies;
At the begin, edgeIndicies
will have values [0,1,2,...n]
.
Sorting the weights, you move the indicies instead, so if the indicies are the following:[5,7,9,...]
you know edgeWeights[5]
is the smallest, edgeWeights[7]
is the second smallest, ...etc.
add a comment |Â
up vote
2
down vote
Is this efficient if I only use it for small inputs?
For small inputs, anything is efficient.
For big data, having each Node
as such a large object would be inefficient.
I depends what kind of actions you would do over the graph. If you access it sequentially, there can be also a linked implementation like:
class LinkedNode
public Node firstChild;
public Node nextSibling;
boolean visited;
Here's an alternative, without objects but with arrays instead:
int edgeWeights;
int edgeIndicies;
At the begin, edgeIndicies
will have values [0,1,2,...n]
.
Sorting the weights, you move the indicies instead, so if the indicies are the following:[5,7,9,...]
you know edgeWeights[5]
is the smallest, edgeWeights[7]
is the second smallest, ...etc.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Is this efficient if I only use it for small inputs?
For small inputs, anything is efficient.
For big data, having each Node
as such a large object would be inefficient.
I depends what kind of actions you would do over the graph. If you access it sequentially, there can be also a linked implementation like:
class LinkedNode
public Node firstChild;
public Node nextSibling;
boolean visited;
Here's an alternative, without objects but with arrays instead:
int edgeWeights;
int edgeIndicies;
At the begin, edgeIndicies
will have values [0,1,2,...n]
.
Sorting the weights, you move the indicies instead, so if the indicies are the following:[5,7,9,...]
you know edgeWeights[5]
is the smallest, edgeWeights[7]
is the second smallest, ...etc.
Is this efficient if I only use it for small inputs?
For small inputs, anything is efficient.
For big data, having each Node
as such a large object would be inefficient.
I depends what kind of actions you would do over the graph. If you access it sequentially, there can be also a linked implementation like:
class LinkedNode
public Node firstChild;
public Node nextSibling;
boolean visited;
Here's an alternative, without objects but with arrays instead:
int edgeWeights;
int edgeIndicies;
At the begin, edgeIndicies
will have values [0,1,2,...n]
.
Sorting the weights, you move the indicies instead, so if the indicies are the following:[5,7,9,...]
you know edgeWeights[5]
is the smallest, edgeWeights[7]
is the second smallest, ...etc.
edited Jan 17 at 5:40
Brandon Gomes
25017
25017
answered Jan 16 at 18:02
user8426627
1343
1343
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f185218%2fjava-node-class-for-a-graph%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
It is one of the popular data structure for storing graphs - AdjencyList. So far it seems good.
â Mangat Rai Modi
Jan 16 at 14:45
I had seen some classes where they created classes for vertices as well, I found it too complicated, I guess this should work and no more classes should be needed
â Bugs Buggy
Jan 16 at 15:05
1
do you mean edges? Because here Node is a vertex and weights I believe are the weight for the edges going to adjacent nodes. Depending on problem you might need to create a class for edges too, for e.g. if edges have some extra data your problem like cost, distance and other metrics. In that case, your weights will become an array list of the Edge class
â Mangat Rai Modi
Jan 16 at 15:20
Yes I meant edges. Sorry for the confusion, can I not save that data in the node, like suppose in Node A adjacent matrix element x is Node B. Edge connecting A to B has some weight, we can store that as element x in another array. This would be applicable to unidirectional Graph, in case of bidirectional, a lot of data would be redundant but again for small number of input it will just work.
â Bugs Buggy
Jan 16 at 15:58
1
If the core of the question is whether the data structure is OK: Yes. As others have pointed out, this is an adjacency list. Depending on the desired genericity, one would/could/should try to add an abstraction layer to hide this implementation detail from the user, but this is not trivial (and may not be necessary in your case). If the question is about "low level code recommendations": It should be
private final List<Node> adjacent
(+ the necessary accessor methods)â Marco13
Jan 20 at 21:09