Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep track of link and node sub-type counts in the Network class #11

Open
ttaxon opened this issue Jul 26, 2016 · 3 comments
Open

Keep track of link and node sub-type counts in the Network class #11

ttaxon opened this issue Jul 26, 2016 · 3 comments

Comments

@ttaxon
Copy link
Contributor

ttaxon commented Jul 26, 2016

I noticed that the counts for the individual sub-types of Node and Link aren't stored anywhere as they were in EPANET2, but there are couple of places where they are used. In both places, the element list is iterated over and the elements are counted. As this is is fairly inefficient, I propose that the counts be added to the Network class and tallied as the elements are added and that there are two overloaded count() methods added - one for NodeTyes and one for LinkTypes.

I have made the modifications already (they were fairly simple) and will commit or change based on this discussion.

@samhatchett
Copy link
Member

Good points Tom. I've penned some thoughts over on #10 related to this and the use of containers in the Network class. A custom container class could help solve this problem. I could imagine a map derivative that offers pre-computed access to countOfType(Element::ElementType type). Or cache the count as an ivar in Network, which just requires that logic to reside in the brain of the Network instead. Any thoughts on that?

@ttaxon
Copy link
Contributor Author

ttaxon commented Jul 26, 2016

For the current use cases that I see, simply counting the different subtypes as they are encountered and storing the counts in ivars is what is needed. I haven't seen any cases that need to obtain all instances of a specific type (i.e. "give me all the pumps"), although i readily admit that I have not scoured every line of code. What you are describing is exactly what I've done (here is a link to the commit in my fork).

@samhatchett
Copy link
Member

I do see DataManager::getCount, but that only works for a subset of (sub)types. However, i could absolutely see the value in fetching a list of subtypes. "Give me all the pumps" should be a valid behavior, probably at the Network level. So I think a vector would be helpful. Whether to cache the info and/or count maybe has to do with your tolerance for potential invalidation bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants