This is a question about multiple graph creation. I'm looking to develop some code which runs uses evolutionary techniques to build graphs and test them for various properties. I've noticed a previous question that asks about the default graph labelling, and for ways to reset it. I can re-write my code to use labels that I place in, but I was wondering whether there is some way of resetting the counter contained within this label? I appreciate that I shouldn't rely on the default counter - but if I use userdata I'm effectively going to re-implement this style of behaviour (as label names aren't important, just some identifier), so thought it might be beneficial to check on both counts.
As my code progresses I'm partially concerned over the potential for overflow. Though I appreciate that this is partially fear in my mind - but I've no real way at present of putting an upper bound on the number of generations, and indeed how many vertices could appear within a network. But also picking up from a previous thread maintaining consistency between graphs isn't especially important since once I've evaluated the fitness, I can effectively thrown them away. Most of the history won't be important. Is this counter held in some state that I can access and reset? Or am I unable to do anything and so should adjust my code accordingly?
Thanks,
Jon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure exactly what you're trying to accomplish here, since you're talking mostly in generalities. But perhaps I can clear a couple of things up.
(0) JUNG vertices (and edges) can be any object that you want.
(1) As a consequence of (0), JUNG has no "default labels" for vertices, nor any particular specification for how labels must behave. You tell the renderer how to label things by telling it how to retrieve labels for each element; there is plenty of sample code that demonstrates this.
(2) As a further consequence of (0), labels and other data about graph elements need not bear any particular relationship to one another (although of course they can). If you want more information on how to associate user data with graph elements, please take a look here: https://sourceforge.net/apps/trac/jung/wiki/JUNGManual#UserData
Hope this helps.
Joshua
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. I'll try and elaborate a little bit more to give you an idea of the code setup that I have. I'm modelling network connections using JUNG - this relies on the DISCO network calculus library underneath which also uses JUNG.
I create a graph as an abstract representation of the network is encapsulated within one class, along with the data from the simulation. This class contains the reference to JUNG, and any associated objects.
I appreciate the need for userdata, however, this isn't used in the underlying toolbox for the network calculus. The only access I have to the transformation is through getVertices() which I can then can toString() to get a list . I know this isn't ideal, and isn't using userdata.
However, when I create a new object this labelling picks up where the previous network left off, despite recreating the object (using new) - so I would get . Although the story isn't this simple as there's an underlying mapping that takes place in the network calculus library which also recreates a much larger network.
I'm puzzled as to how this information is actually persisting, given as far as I can figure I should have disposed of the any information related to JUNG within the run.
At present I can create the network, transform it and analyse the data. I'm in the process of testing network dependability to link failure which means recreating various different forms of that graph, and then analysing them. I accept it's possibly to just modify the network - but that's only a short term fix as ultimately I'm going to need to create vastly different models for the evolutionary process to work over.
My concern stems partially from getting things working generally and partially about whether I'm setting myself up for a fall later on. I need to build, analyse and modify a large number of networks. I'm seeing (if I understand correctly? I also fully accept that I may not be) a numeric parameter that's always going to climb, and that I have no way of capping/resetting - that makes me wonder whether there is a maximum number of vertices that I can create as part of a single run. Between executions no problems, everything resets. But within an execution it's always going to climb. From my perspective, there's no need for it to - as each sub-graph I create is independent. If I can't reset it, then no problems, but at some-point is it going to overflow and cause a problem?
It's really possible that I've misunderstood something here, and I'm hoping I have. I also appreciate that I've got a restriction that I'm trying to work with, which is another underlying library; which doesn't use userdata to append labels. So my main method of getting information has been getVertices() and then just using toString().
Thanks,
Jon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think you need to worry about those labels. They're an artifact of how the vertices are being constructed and they're not important.
There is no cap on the number of vertices that you can create in a run. Depending on exactly what the vertex construction is doing, it might eventually overflow…once you hit 2B vertices. But without knowing exactly what the library is doing with JUNG, I can't really say.
One question: any idea what version of JUNG that library is using? It sounds like it might be 1.x, which is a few years old at this point and no longer supported.
Joshua
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the information. With regards to any overflow, I can clean up/remove vertices from the network models once I've finished with them, so I'd only have around the number that each individual model (plus any more for potential solutions). But that number should remain limited, even if the total number used can rise pretty quickly.
I manage the creation/destruction in the basic model, which I pass into the calculus library which performs a transform, generating a new network that can then be analysed. So even for a relatively small network there is a little bit of an explosion of vertices created. I'm currently re-coding some areas of my own code to provide the functionality I need. Whilst this isn't ideal, it should provide a solution that's robust to what I need to do.
There is a significant chance though that in the process quite a few will get created and subsequently removed though. Especially if I extend some of the ideas that I am working on.
You are quite correct, they are using an older library. Their library comes with 1.7.6, which is linked directly from the jar file.
Thanks,
Jonathan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
JUNG 1.x uses int values for its vertex IDs. Those will wrap around on overflow, so if you run a single instance long enough you'll get vertices with negative indices, but everything should still work.
Hypothetically if you have extremely long-lived vertices, you could try to assign two vertices the same ID once you've gone through all 4B possible values for an int. In practice this seems unlikely.
Joshua
Joshua
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a question about multiple graph creation. I'm looking to develop some code which runs uses evolutionary techniques to build graphs and test them for various properties. I've noticed a previous question that asks about the default graph labelling, and for ways to reset it. I can re-write my code to use labels that I place in, but I was wondering whether there is some way of resetting the counter contained within this label? I appreciate that I shouldn't rely on the default counter - but if I use userdata I'm effectively going to re-implement this style of behaviour (as label names aren't important, just some identifier), so thought it might be beneficial to check on both counts.
As my code progresses I'm partially concerned over the potential for overflow. Though I appreciate that this is partially fear in my mind - but I've no real way at present of putting an upper bound on the number of generations, and indeed how many vertices could appear within a network. But also picking up from a previous thread maintaining consistency between graphs isn't especially important since once I've evaluated the fitness, I can effectively thrown them away. Most of the history won't be important. Is this counter held in some state that I can access and reset? Or am I unable to do anything and so should adjust my code accordingly?
Thanks,
Jon
Jon:
I'm not sure exactly what you're trying to accomplish here, since you're talking mostly in generalities. But perhaps I can clear a couple of things up.
(0) JUNG vertices (and edges) can be any object that you want.
(1) As a consequence of (0), JUNG has no "default labels" for vertices, nor any particular specification for how labels must behave. You tell the renderer how to label things by telling it how to retrieve labels for each element; there is plenty of sample code that demonstrates this.
(2) As a further consequence of (0), labels and other data about graph elements need not bear any particular relationship to one another (although of course they can). If you want more information on how to associate user data with graph elements, please take a look here: https://sourceforge.net/apps/trac/jung/wiki/JUNGManual#UserData
Hope this helps.
Joshua
Joshua,
Thanks for your reply. I'll try and elaborate a little bit more to give you an idea of the code setup that I have. I'm modelling network connections using JUNG - this relies on the DISCO network calculus library underneath which also uses JUNG.
I create a graph as an abstract representation of the network is encapsulated within one class, along with the data from the simulation. This class contains the reference to JUNG, and any associated objects.
I appreciate the need for userdata, however, this isn't used in the underlying toolbox for the network calculus. The only access I have to the transformation is through getVertices() which I can then can toString() to get a list . I know this isn't ideal, and isn't using userdata.
However, when I create a new object this labelling picks up where the previous network left off, despite recreating the object (using new) - so I would get . Although the story isn't this simple as there's an underlying mapping that takes place in the network calculus library which also recreates a much larger network.
I'm puzzled as to how this information is actually persisting, given as far as I can figure I should have disposed of the any information related to JUNG within the run.
At present I can create the network, transform it and analyse the data. I'm in the process of testing network dependability to link failure which means recreating various different forms of that graph, and then analysing them. I accept it's possibly to just modify the network - but that's only a short term fix as ultimately I'm going to need to create vastly different models for the evolutionary process to work over.
My concern stems partially from getting things working generally and partially about whether I'm setting myself up for a fall later on. I need to build, analyse and modify a large number of networks. I'm seeing (if I understand correctly? I also fully accept that I may not be) a numeric parameter that's always going to climb, and that I have no way of capping/resetting - that makes me wonder whether there is a maximum number of vertices that I can create as part of a single run. Between executions no problems, everything resets. But within an execution it's always going to climb. From my perspective, there's no need for it to - as each sub-graph I create is independent. If I can't reset it, then no problems, but at some-point is it going to overflow and cause a problem?
It's really possible that I've misunderstood something here, and I'm hoping I have. I also appreciate that I've got a restriction that I'm trying to work with, which is another underlying library; which doesn't use userdata to append labels. So my main method of getting information has been getVertices() and then just using toString().
Thanks,
Jon
Jon:
I don't think you need to worry about those labels. They're an artifact of how the vertices are being constructed and they're not important.
There is no cap on the number of vertices that you can create in a run. Depending on exactly what the vertex construction is doing, it might eventually overflow…once you hit 2B vertices. But without knowing exactly what the library is doing with JUNG, I can't really say.
One question: any idea what version of JUNG that library is using? It sounds like it might be 1.x, which is a few years old at this point and no longer supported.
Joshua
Hi Joshua,
Thanks for the information. With regards to any overflow, I can clean up/remove vertices from the network models once I've finished with them, so I'd only have around the number that each individual model (plus any more for potential solutions). But that number should remain limited, even if the total number used can rise pretty quickly.
I manage the creation/destruction in the basic model, which I pass into the calculus library which performs a transform, generating a new network that can then be analysed. So even for a relatively small network there is a little bit of an explosion of vertices created. I'm currently re-coding some areas of my own code to provide the functionality I need. Whilst this isn't ideal, it should provide a solution that's robust to what I need to do.
There is a significant chance though that in the process quite a few will get created and subsequently removed though. Especially if I extend some of the ideas that I am working on.
You are quite correct, they are using an older library. Their library comes with 1.7.6, which is linked directly from the jar file.
Thanks,
Jonathan
Jonathan:
JUNG 1.x uses int values for its vertex IDs. Those will wrap around on overflow, so if you run a single instance long enough you'll get vertices with negative indices, but everything should still work.
Hypothetically if you have extremely long-lived vertices, you could try to assign two vertices the same ID once you've gone through all 4B possible values for an int. In practice this seems unlikely.
Joshua
Joshua