[PEAK] recursion limit
pje at telecommunity.com
Fri Jul 15 14:41:19 EDT 2011
At 07:36 PM 7/15/2011 +0200, nicky van foreest wrote:
>I ran into a RuntimeError: maximum recursion depth exceeded in cmp
>with Trellis in this (simple) piece of code.
I ran the code and it does not produce an error for me; it just runs.
>I think I can repair this by resetting the recursion depth. However, I
>suppose this will not work if I run a simulation with a 10e6 jobs. Why
>actually does trellis run into this problem?
Since I'm not able to reproduce the problem, I couldn't
say. However, if you are getting recursion in a comparison, it's
possible that it's because you are using a __cmp__ or other
comparison method in your code that's not in the sample you sent me,
wherein that comparison relies on trellis properties. (OTOH, if that
were the case, then changing the recursion depth wouldn't fix it.)
> It makes me a bit
>suspicious about the scaleability of trellis, or should I not worry
I don't think so. The recalculation algorithm is only recursive if
you request calculation of a value that has not previously been
calculated. That is, if you set up a chain of a million items, and
only then request some info about the last one, *and* the values it
depends on are lazy (that is, they don't get automatically computed
just by initializing their owner object), then yes, it will have to
recurse to one million depth (times a constant).
So, if you are going to set up a heavily chained calculation, you can
make it non-recursive simply by ensuring that the desired property is
calculated eagerly, e.g. by using trellis.maintain(). This will both
amortize the initial calculation over your setup time, *and* ensure
that any subsequent read operations can't end up being recursive.
>thanks for any hints.
FYI, there is potentially a bug in your code if a Job's 'prev'
attribute can be changed. As your code stands, changing a job's
'prev' attribute will leave its calculations linked to the old
'prev', until something causes the rules to be recalculated. (At
which time they'll link to the new 'prev'.) You should make 'prev' a
Trellis attribute if it's not a constant. Then, changing it will
cause the appropriate recalcuations to occur.
More information about the PEAK