Translate this to python?

[KraftDiner]

I'm porting a routing from C++ to python.
There is a complex for loop that I don't know how to code in python

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

Thanks.

 

[Patrick Maupin]

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

A simple translation of this would be:

i = npoints-1

for j in range(npoints):
... (your code here)
i = j

HTH,
Pat

 

[Patrick Maupin]

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

Alternatively, if you don't like the initial setup of i and would
prefer your setup code at the top of the loop:

for j in range(npoints):
i = (j-1) % npoints
... (your code here)

Finally, you could always do something like this:

pointrange = range(npoints)

for i,j in zip(pointrange[-1:]+pointrange[:-1], pointrange):
... (your code here)

This latter could be useful if you are reusing the range on a regular
basis -- in fact you could store a "rotatedpointrange" as well as a
point range.

HTH,
Pat

 

[Peter Hansen]

I'm porting a routing from C++ to python.
There is a complex for loop that I don't know how to code in python

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

i = nPoints - 1
j = 0
while j < nPoints:
# do stuff
i = j
j += 1

For loops in C aren't really complicated. They have stuff that happens
before the loop is entered, a test that occurs at the top of the loop
before each pass, and stuff that happens at the end of the loop just
after the body has executed. Using a while loop in Python makes it
mechanical to translate any such C for loop...

-Peter

 

[Peter Hansen]

A simple translation of this would be:

i = npoints-1

for j in range(npoints):
... (your code here)
i = j

Though, without knowing what the body does, one can't be sure that's
going to be a faithful translation. The for loop in Python always
iterates over the entire set of items given to it, unless it's told to
break early. But if "j" or "nPoints" is modified in the body of the C
for loop, the loop might execute a different number of times than the
above Python for loop would.

(I agree it appears unlikely that the OP's code is going to do that, but
it's worth mentioning for safety.)

-Peter

 

[KraftDiner]

Thanks all!

 

[Zeng Nan]

I'm porting a routing from C++ to python.
There is a complex for loop that I don't know how to code in python

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

i = nPoints - 1
for j in range(nPoints):
<statements>
i = j
--
Zeng Nan
Simple is Beautiful.
~~~~~~~~~~~~~~~~~~~~
MY BLOG: http://zengnan.blogspot.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDu0SPxFSvMHT0z4kRAl+HAJ9yzwjcXBisMcUd03OF6MUamqXbHQCdH5MK
I65h1ofidvAG8qqsQH0AuAA=
=82Cs
-----END PGP SIGNATURE-----

 

[Patrick Maupin]

Though, without knowing what the body does, one can't be sure
that's going to be a faithful translation. The for loop in Python
always iterates over the entire set of items given to it, unless
it's told to break early. But if "j" or "nPoints" is modified in the
body of the C for loop, the loop might execute a different
number of times than the above Python for loop would.

(I agree it appears unlikely that the OP's code is going
to do that, but it's worth mentioning for safety.)

You are absolutely correct, sir.

I definitely made the assumption that either: a) the OP presented his
_entire_ loop control code for our perusal, or that b) the OP could
possibly learn to do a better job of phrasing his questions (ESR
treatise, anyone?) in the future if he finds out that my response is
inadequate due to his incomplete description of the problem.

Whether none, either, or both of these assumptions is a mistake is a
question only the OP can answer

Regards,
Pat

 

[Bengt Richter]

I'm porting a routing from C++ to python.
There is a complex for loop that I don't know how to code in python

for (i = nPoints-1, j = 0; j < nPoints; i = j, j++)

Perhaps most directly comparable semantics (untested):

i = nPoints-1
j = 0
while j<nPoints:
# whatever body code
i = j
j += 1

Not sure what i is really for, but j seems to be independent,
so perhaps (also untested, and caveat: it's past bedtime)

i = nPoints - 1
for j in xrange(nPoints):
# whatever
i = j

Regards,
Bengt Richter

 

[pyguy2]

For some reason, ocassionally when I see xrange, I think "But wasn't
that deprecated since range is now a . . oh wait that's xreadlines".
xrange is a cool thing the few times where you really need it.

john

 

[Xavier Morel]

For some reason, ocassionally when I see xrange, I think "But wasn't
that deprecated since range is now a . . oh wait that's xreadlines".
xrange is a cool thing the few times where you really need it.

john

I think that xrange is also soon-to-be deprecated (xrange eats a little
less memory and is slightly faster to _create_, but much slower to
_iterate over_ than range)

 

[Heiko Wundram]

I think that xrange is also soon-to-be deprecated (xrange eats a little
less memory and is slightly faster to _create_, but much slower to
_iterate over_ than range)

It might be slower to iterate using xrange, but xrange certainly has its
place in Python... Try the following on your computer:

for x in range(10**10):
print x

for x in xrange(10**10):
print x

Tell me which one doesn't overflow your memory. ;-) And before you come
telling me that these constraints are articial, I've _written_ programs
that had to iterate over 2**24 (the set of 10.* IP addresses), and I most
certainly wouldn't have wanted the machines to contain 384+ MB of RAM just
to store the number objects that range creates.

--- Heiko.

 

[Xavier Morel]

It might be slower to iterate using xrange, but xrange certainly has its
place in Python... Try the following on your computer:

for x in range(10**10):
print x

for x in xrange(10**10):
print x

Tell me which one doesn't overflow your memory. ;-) And before you come
telling me that these constraints are articial, I've _written_ programs
that had to iterate over 2**24 (the set of 10.* IP addresses), and I most
certainly wouldn't have wanted the machines to contain 384+ MB of RAM just
to store the number objects that range creates.

--- Heiko.

While xrange does have it's place in Python, it has very few actual uses
(yours being one of the few), and is usually more harmful than beneficial.

While the deprecation of xrange is not that "soon", it is part of the
Python 3000 PEP (http://www.python.org/peps/pep-3000.html#id38) along
with the deprecation of most FP-facilities of Python (filter, map, reduce).

It should also be noted that reimplementing xrange when needed is
trivial and can be done with a 5-lines generator for the minimal version
(1 argument, 0-n range) and probably less than 10 lines for the full
blown version equivalent to the current one (including start, end and
step arguments)

 

[bonono]

While xrange does have it's place in Python, it has very few actual uses
(yours being one of the few), and is usually more harmful than beneficial.

While the deprecation of xrange is not that "soon", it is part of the
Python 3000 PEP (http://www.python.org/peps/pep-3000.html#id38) along
with the deprecation of most FP-facilities of Python (filter, map, reduce).

It should also be noted that reimplementing xrange when needed is
trivial and can be done with a 5-lines generator for the minimal version
(1 argument, 0-n range) and probably less than 10 lines for the full
blown version equivalent to the current one (including start, end and
step arguments)

Seems that xrange() would be deprecated because range() will be the
lazy version, so a name change or more like that the current range(),
i.e. the one that returns a list will be deprecated, feature wise.

 

[Heiko Wundram]

While the deprecation of xrange is not that "soon", it is part of the
Python 3000 PEP (http://www.python.org/peps/pep-3000.html#id38) along
with the deprecation of most FP-facilities of Python (filter, map,
reduce).

I know this, and that's one of the reasons I'm a little at odds with Python
3000... There are many good things in there (such as removing the
FP-facilities which are much more clearly and cleverly implemented using
generator- and list-comprehensions), but some things are so basic (such as
xrange) I wouldn't want to have to implement them every time I need such a
beast.

Unless of course range() becomes "more clever" and returns an iterator in
case the amount of memory to store the needed range is too large, which
would of course mean obfuscation at other places...

I just don't know.

--- Heiko.

 

[Robert Kern]

I know this, and that's one of the reasons I'm a little at odds with Python
3000... There are many good things in there (such as removing the
FP-facilities which are much more clearly and cleverly implemented using
generator- and list-comprehensions), but some things are so basic (such as
xrange) I wouldn't want to have to implement them every time I need such a
beast.

Unless of course range() becomes "more clever" and returns an iterator in
case the amount of memory to store the needed range is too large, which
would of course mean obfuscation at other places...

I believe range() will always return an iterator in Python 3000. See the first
item in the section "Built-In Changes" on http://wiki.python.org/moin/Python3.0.
xrange() will be going away because it will be utterly obsolete in every
conceivable way.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Steven D'Aprano]

While xrange does have it's place in Python, it has very few actual uses
(yours being one of the few), and is usually more harmful than beneficial.

While the deprecation of xrange is not that "soon", it is part of the
Python 3000 PEP (http://www.python.org/peps/pep-3000.html#id38) along
with the deprecation of most FP-facilities of Python (filter, map, reduce).

Er, I thought it was range that was being depreciated, and xrange being
renamed range?

Or if you prefer, xrange being depreciated, and range being turned into an
iterator just like xrange *wink*

(I'm aware that xrange isn't implemented as an iterator, or at least it
wasn't, it was a unique object type. But it is conceptually an iterator.)

It should also be noted that reimplementing xrange when needed is
trivial and can be done with a 5-lines generator for the minimal version
(1 argument, 0-n range) and probably less than 10 lines for the full
blown version equivalent to the current one (including start, end and
step arguments)

I have a problem with this attitude. Yes, it is true that many of the
features of Python scheduled for eventual depreciation in Python 3.0 (map,
filter, str.find, xrange, etc.) can easily be re-written in just a couple
of lines.

But these functions are useful, and I don't see that it is a step forward
to remove useful functionality from the language and expect people to fill
their programs with boilerplate code recreating that lost functionality.
Guido introduced True, False because so many people were writing

False = 0; True = not False

at the start of their code. Will Guido end up re-introducing str.find
to Python 4.0 because people define this in all their code (complete with
deliberately included bug)?

def find(s, target, start=None, end=None):
try:
return s.index(target, start, end)
except:
return -1

On the other hand, there are genuine improvements: apply(f, L) is *much*
better written as f(*L). I don't think anyone will miss apply.

 

[Paul Rubin]

I know this, and that's one of the reasons I'm a little at odds with Python
3000... some things are so basic (such as
xrange) I wouldn't want to have to implement them every time I need such a
beast.

Itertools.count could be extended to replace xrange.

Unless of course range() becomes "more clever" and returns an iterator in
case the amount of memory to store the needed range is too large...

That could break things. Range is supposed to return a list.

 

[Robert Kern]

That could break things. Range is supposed to return a list.

Except that we're talking about Python 3.0, which will break things anyways.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter