Geniterator? / Re: (infinite) sequences using recurrence relations

From: Eric Ford (eford_at_[hidden])
Date: 2001-08-06 02:09:54

> Based on my initial musing, I thought that there should be four
> elements: state, recurrence relation, geniterator (to adopt your
> terminology), and sequence.  At least as I'm thinking, a geniterator
> needs to know both the current state and how to generate additional
> elements (recurrence relation).  I like the idea of separating those
> into three separate classes.  Originally, I was hoping that by
> separating the state and the recurrence relation into separate
> classes, there could be some additional code reuse.  However, if that
> doesn't pan out, I might change my mind to prefer combining the state
> and recurrence relation classes into one.
Thinking more about this...

In favor of combining the state and recurrence relation into one
class...  
Reduce number of classes and therefore complexity.  
Most recurrence relations will work closely with the state class and
hence not work with multiple state classes.    

In favor of separating the state and recurrence relation into separate
classes...  
Desire to keep the parameters for the recurrence relation (const over
life of geniterator) separate from the variables making up the state
(may change at each operator++).  
If recurrence relation has significant member variables (parameters
for the recurrence relation) and several geniterators are active for
the same recurrence sequence, then memory savings are possible by
having several geniterators could share a const reference or reference
counted pointer to the recurrence relation.  

Possible solution...  Hybrid.  Have a generic geniterator class take a
single template parameter, a class containing both the state and
recurrence relation (what to call that?).  For simple recurrences that
one class could implement both the state and recurrence relation.  For
more complex cases, that class could contain separate state and
recurrence relation classes.  Essentially, this ammounts to presenting
interfaces for both the unified and the separated options.
Can someone think of another factor I'm not considering or a problem
with the hybrid design?