Orthogonal but the use case is there is no repetition of pattern
presentation and that was in answer to why patterns can be depleted. Now as
to whether PatternGenerator should return None or not, depends on whether
the intent of GeneratorSheet. My code works for now and I dont need the fix
(i may end up cloning GeneratorSheet at some stage).  But it raises the
question of why i have to raise an "exception" if for my use case it is
really not an exception. Maybe GeneratorSheet should be able to accommodate
other type of pattern inputs (that can be depleted) and that also notifies
the simulator engine. The bottom line is the real-use case requires that
input is not necessarily forever.


On Tue, May 28, 2013 at 4:53 AM, James A. Bednar
<notifications@github.com>wrote:

> In topo/misc/generatorsheet.py:
>
> > @@ -97,7 +97,15 @@ def generate(self):
> >          # JABALERT: What does the [:] achieve here?  Copying the
> >          # values, instead of the pointer to the array?  Is that
> >          # guaranteed?
> > -        self.activity[:] = self.input_generator()
> > +        ac = self.input_generator()
> > +        if ac is not None:
> > +            self.activity[:] = ac
> > +        else:
> > +            # Note that a generator may return a None if it has run out of patterns it is loading.
>
> The question of whether to keep the entire list of patterns in memory is
> orthogonal to whether a PatternGenerator may return None. Yes, it's
> desirable to have a good way to read from a list one at a time without
> consuming extra memory, and I'm all in favor of having that.
>
> But unless I'm misunderstanding you, the problem of having the network
> state wiped out is caused by returning None, *not* caused by the existing
> assignment. Isn't that what you are really saying? I.e., in the current
> code no PatternGenerator is allowed to return None, and you've now added
> one that returns None, and found that when it happens the weights get wiped
> out. If so, the solution seems to me to be to make sure never to return
> None, because returning None is *not* allowed and not supported. So I
> agree that there is a problem, I agree with the overall goal, but at least
> with the information I have so far, I don't agree that checking for None in
> the GeneratorSheet is the appropriate fix, because I don't think None
> should ever have been allowed to be returned by a PatternGenerator in the
> first place.
>
> Maybe the best way forward would be to supply the entire set of code for
> the example where this occurs, so that I can suggest a more appropriate
> place to make the fix. I'm a bit hamstrung right now because I can only see
> the code on one side, and don't think the fix belongs there, and can't see
> the part where I think it does belong. Hope that makes sense!
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/ioam/topographica/pull/516/files#r4408773>
> .
>