It is my understanding that during an AB optimization which the user specifies as, and understands logically to be, exactly N iterations, various statements in the AFL may be executed internally some number other than N times.
This is a result of the design of AB. While we are assured that the results generated by AB are correct as to equity, statistics, etc., in the general case, we are cautioned that our code _cannot_ rely upon a specified # of iterations of any given AFL statement. If our code logic is counting, or writing files, or doing anything else based upon the # of iterations, then we are outside the design scenario of AB code execution. I invite correction if I have stated the above inaccurately. (Of course, a more detailed explanation would have to come from TJ.) I'll add that I do, personally, find this to be one of the limiting edge cases to coding in AFL. Writing code that expects and relies upon a fixed number of executions is a very "normal" thing to do. Not being able to write such code is "abnormal", IMO. It might not actually make sense vis-a-vis the AB internals, but logically, given the situation, it seems to me that a new AB construct that allows the user to specify "Do this _exactly_ once per optimization iteration" would be a helpful thing to have.
