Java Node class for a Graph

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
4
down vote

favorite
3












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;







share|improve this question

















  • 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
















up vote
4
down vote

favorite
3












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;







share|improve this question

















  • 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












up vote
4
down vote

favorite
3









up vote
4
down vote

favorite
3






3





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;







share|improve this question













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;









share|improve this question












share|improve this question




share|improve this question








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 be private final List<Node> adjacent (+ the necessary accessor methods)
    – Marco13
    Jan 20 at 21:09












  • 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







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










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.






share|improve this answer























    Your Answer




    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("mathjaxEditing", function ()
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
    );
    );
    , "mathjax-editing");

    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "196"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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.






    share|improve this answer



























      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.






      share|improve this answer

























        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.






        share|improve this answer
















        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.







        share|improve this answer















        share|improve this answer



        share|improve this answer








        edited Jan 17 at 5:40









        Brandon Gomes

        25017




        25017











        answered Jan 16 at 18:02









        user8426627

        1343




        1343






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            Chat program with C++ and SFML

            Function to Return a JSON Like Objects Using VBA Collections and Arrays

            Will my employers contract hold up in court?