You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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).
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.
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.
The text was updated successfully, but these errors were encountered: