Fault trees structure

Alex Martelli aleaxit at yahoo.com
Tue Dec 12 12:26:27 CET 2000


"Darrell" <news at dorb.com> wrote in message
news:yfhZ5.23310$Ia1.4003773 at typhoon.nyroc.rr.com...
> Jumping right to code :)
> Seemed more fun than reading too deeply about fault trees.

Nice general structure, it seems -- I'll just offer a few
observations based on Python 2:

>     def connectInput(self, name):
>         if not hasattr(self, "_input"):
>             self._input={}
>         self._input[name]=None

def connectInput(self, name):
    self.__dict__.setdefault('_input',{})[name] = None

is a possible alternative (also in other cases), but
not very readable.  It would seem best to just set
empty dictionaries in __init__ for _input and _output,
so as to avoid having test for them at every connect,
and possibly having errors lurking elsewhere, too:

>     def signal(self, collection, name, value=1):
>         self._input[name]=value
>         self.logic(collection)

This will cause an exception if self has no _input,
but work just fine if _input does exist (because ANY
connectInput was previously called on self -- be it
on this specific name, or another).  It seems not
likely that this is the intended semantics.  Having
_input set at __init__ will make this just work; if
the intent is that name must be a string for which
self.connectInput was previously called, this can
also easily be checked with an has_key, for example.

Of course, giving NodeBase an __init__ means having
to call it in lieu, or from, specific subclasses'
ones, but that seems OK; right now OrNode and
AndNode sport identical __init__ methods, so why
not factor them out of the subclasses and up into
the NodeBase common baseclass.


>     def logic(self, collection):
>         cc= reduce(lambda x,y: x and y, self._input.values())
>         self.propagate(collection, cc)

If the values are constrained to "boolean" (0 and 1), then
using operator.and_ as the first argument to reduce might
well be faster, and perhaps more readable (similarly for
or-nodes).


Alex






More information about the Python-list mailing list