Arnaud Delobelle wrote: > On May 7, 7:05 pm, Bjoern Schliessmann <usenet-
>> There is a master "current controller" object which tells >> the "source" object to start a "current" by calling its >> neighbour. The calls traverse the network until they reach a >> "ground" object. Specifically, the source passes a "telegram" >> instance with these calls, and everyone it passes through >> "registers" himself with it (telegrams are duplicated at joints). >> Then, the ground object calls back to the controller with all >> received telegrams. Like this I'm already able to get all >> possible ways through the network. > > Then you can get all 'potential' paths that depend on one or more > switches being on. Each path could know what switches it depends > on and be 'active' if and only if all those switches are on. And > each switch would know what paths depend on it. Similarly each > lightbulb would know what paths it depends on and be 'on' if at > least one path is active; and each path would know which > lightbulbs it powers In principle, I thought so too, but I didn't like the fact that this involves all possible circuits be determined only once. But it seems like there is no reasonable, different way. > When you turn a switch off, it would send a message to the paths > that depend on it (maybe via the controller?) so that they would > be deactivated. In turn the lightbulbs on these paths would be > informed that they are no longer active. > > When you turn a switch on, it would send a message to the paths > that depend on it so that those who do not have another off switch > would be activated. In turn the lightbulbs on these paths would > be informed that they have a new power source. Yep. Looks like I have to do extended "bookkeeping" for this. I was looking for a more dynamic, general way. > It seems to me that it would work well with the way you started it > out, but I may have misunderstood some aspects or overlooked some > problems ;) Thanks for your input. The biggest problem I got until now are the crummy interfaces for interconnection which quickly get inconcise. I've had a look at the NetworkX tutorial and it seems like this could simplify the code a bit. Regards, Björn -- BOFH excuse #173: Recursive traversal of loopback mount points -- http://mail.python.org/mailman/listinfo/python-list
