On Feb 8, 2009, at 10:30, Magnus Lie Hetland wrote:
>> http://trac.cython.org/cython_trac/ticket/208
>
> I could have a look.
I tried what seemed to me to be the obvious solution here -- surround
the loop with an if statement with the same condition that is used for
ending the loop.
Early in "generate_execution_code":
> from_range = getattr(self, "from_range", False)
Then, before the loop:
> if from_range:
> code.putln("if (%s%s %s %s) {" % (
> self.bound1.result(), offset, self.relation2, self.bound2.result()
> ))
An end brace is output after the "undo" operator (which is also
conditional on from_range).
I realize we again risk double-evaluating bound1 and bound2 here, but
I'm guessing that the expressions will have been evaluated before
they're used here anyway (as with step).
It seems correct, and the tests work without the refnanny (except for
the NumPy stuff, which all fails because I haven't properly installed
NumPy at the moment; there also seemed to be a problem when running
with the refnanny). Should I upload a patch to the tracker?
By the way, while thinking of this, it occurred to me that it might be
cleaner to just ditch the for loop than to undo its semantics. It
won't help on the extra check needed to see if we assign to the loop
variable at all (i.e., what I'm doing here), but by using a while-loop
with the proper test, we should be able to avoid the spurious
increment and the "undo" operation. Worth a shot? (Or do C compilers
somehow rely on the use of for loops for some kind of optimization
inference or something? Then again, as was pointed out, the extra
assignment is probably optimized away when not needed -- perhaps
that's the best solution, after all.)
--
Magnus Lie Hetland
http://hetland.org
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
