is there a more efficient way to perform that check, or am I overestimating the computational hit?
Yeah, it's definitely not optimal. Repeatedly 'finding' in a list is annoying. If I was trying to optimize...
You could store the 'list' as yet another hash table, keying off the node name with values set to the distance, as there's no need to store that information as an ordered sequence if you save the distance. That way you could query it to find out if a node is present, step forward on the other path when its not, or add the distance returned from the hash to the distance travelled from the other path. That's a bit neater.
I'm beginning to wonder whether I just try to solve everything with hashes...
is there a more efficient way to perform that check, or am I overestimating the computational hit?
Yeah, it's definitely not optimal. Repeatedly 'finding' in a list is annoying. If I was trying to optimize...
You could store the 'list' as yet another hash table, keying off the node name with values set to the distance, as there's no need to store that information as an ordered sequence if you save the distance. That way you could query it to find out if a node is present, step forward on the other path when its not, or add the distance returned from the hash to the distance travelled from the other path. That's a bit neater.
I'm beginning to wonder whether I just try to solve everything with hashes...
Yeah, it's definitely not optimal. Repeatedly 'finding' in a list is annoying. If I was trying to optimize...
You could store the 'list' as yet another hash table, keying off the node name with values set to the distance, as there's no need to store that information as an ordered sequence if you save the distance. That way you could query it to find out if a node is present, step forward on the other path when its not, or add the distance returned from the hash to the distance travelled from the other path. That's a bit neater.
I'm beginning to wonder whether I just try to solve everything with hashes...
Yeah, it's definitely not optimal. Repeatedly 'finding' in a list is annoying. If I was trying to optimize...
You could store the 'list' as yet another hash table, keying off the node name with values set to the distance, as there's no need to store that information as an ordered sequence if you save the distance. That way you could query it to find out if a node is present, step forward on the other path when its not, or add the distance returned from the hash to the distance travelled from the other path. That's a bit neater.
I'm beginning to wonder whether I just try to solve everything with hashes...
It's hashes all the way down...