• "H. S. Teoh" <hsteoh quickfur.ath.cx> Jan 14 2013

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Sun, Jan 13, 2013 at 01:05:25PM +0100, Peter Alexander wrote:
 I'm repeatedly hitting a range API problem in my combinatorics
 library. Many of the ranges require (potentially sizeable) internal
 buffers to maintain their current state (permutations, set
 partitions, power sets etc.) Also, many of these ranges are
 bidirectional. What this means is they have to store *two* buffers,
 one for the front, and one for the back.


 The only (ugly) solution I can come up with is to create three
 different ranges, e.g.
 
 ForwardPermutations
 ReversePermutations
 BidirectionalPermutations
 
 (or equivalently, one range with an iteration policy).



On Sun, Jan 13, 2013 at 05:23:24PM +0100, Phil Lavoie wrote:
[...]
 That. I am not sure why you find it so ugly however :(. When the
 most capable/general range yields a noticeable cost on
 performance/space consumption (which seems to be the case here), I
 think it better to empower the user with choices rather than try to
 make decisions for him/her.


+1.


 Documentating how bidirectionalPerms modifies perf/space might just
 be what you need to make peace with yourself. In the event a user
 REALLY needs the bidirectional functionality, he/she will most
 likely read that documentation and  comprehend why it wasn't the
 default in the first place and I am sure they will be thankful to
 know why.


Another point I'd like to ask is, are these ranges transient, or do they
allocate per iteration? If they are transient (i.e., .front is
invalidated upon calling popFront()), they need to be clearly marked as
such.  Also, I think the default setting should be non-transient, and
only when the user asks for higher performance, a transient range should
be given.


T

-- 
Guns don't kill people. Bullets do.