List of integers & L.I.S.

[n00m]

Given a list of N arbitrarily permutated integers from set {1..N}.
Need to find the ordering numbers of each integer in the LONGEST
increasing sequence to which this number belongs. Sample:

List:
[4, 5, 6, 1, 2, 7, 3]

Corresponding ordering numbers:
[1, 2, 3, 1, 2, 4, 3]

Details:
e.g. number 7 belongs to increasing sequence 1, 2, 7;
but this sequence is not the LONGEST sequence for "7".
The longest sequence for the 7 is 4, 5, 6, 7.
So, the 7's ordering number in this sequence is 4.

The salt of the thing is to do this with an O(n*log(n))
algorithm!
The straightforward O(n^2) algorithm is toooo slooow.

Any ideas?

[Tim Peters]

[Tim Peters, on the problem at
http://spoj.sphere.pl/problems/SUPPER/
]

Oh, it's not that bad <wink>. I took a stab at a Python program for
this, and it passed (3.44 seconds).
...
I didn't make any effort to speed this, beyond picking a reasonable
algorithm, so maybe someone else can slash the runtime

[Bryan Olson] Hmmm ... I used the Theta(n lg n) algorithm ... how the heck...
Aha! The 'bisect' module changed since last I looked. It still
has the Python implementation, but then the last few lines say:

# Overwrite above definitions with a fast C implementation
try:
from _bisect import bisect_right, bisect_left, insort_left, insort_right, insort, bisect
except ImportError:
pass

Binary-search is the inner-loop in this algorithm. I wrote my
own binary-search, so I was executing Theta(n lg n) Python
statements. Tim's use of bisect means that his inner-loop is
in C, so he does Theta(n) Python statements and Theta(n lg n) C
statement.
That's part of it, but doesn't account for enough. If I disable the C
implementation of bisect (replace the "from ..." import above with a
"pass"), the program takes about 50% longer, which would still leave
it well under the 9-second SPOJ time limit. That's without psyco.
With psyco, it takes about the same time with the Python
implementation of bisect as with the C implementation.

Proably more important was my findall() routine. It does redundant
work, and its runtime seems hard to analyze, but it's conceptually
simple and actual timing showed it takes about a third of the time
consumed by my crack() on random 100,000-element permutations. In
fact, findall() takes very close to the amount of time needed just to
read a giant line of input and convert it to a list of ints (without
psyco; with psyco converting the input takes longer than findall()).

Possible surprise: there's a simple trick that allows rewriting
findall() to produce the result list in sorted order directly, instead
of building it in "random" order and sorting it at the end. That made
no measurable difference.
The key to fast Python: use a good algorithm,
Absolutely!
and keep the inner loop in C.

Usually ;-)

Add another: especially for long-term maintenance, readability,
stability and performance, use a library function instead of rolling
your own. The chance that Raymond Hettinger is going to recode _your_
functions in C is approximately 0 ;-)

[n00m]

Tim Peters wrote:

The chance that Raymond Hettinger is going to recode _your_
functions in C is approximately 0 ;-)

Who is Raymond Hettinger?

[Reinhold Birkenfeld]

n00m wrote:

Tim Peters wrote:

The chance that Raymond Hettinger is going to recode _your_
functions in C is approximately 0 ;-)

Who is Raymond Hettinger?

See python-dev and, wrt this thread, http://docs.python.org/whatsnew/node12.html.

Reinhold

[n00m]

Got it! He is a kind of pythonic monsters.

Btw, why it's impossible to reply to old threads?
Namely, there're no more "Reply" link in them.
Only "Reply to author" etc.

[Terry Reedy]

"n00m" <n0**@narod.r u> wrote in message
news:11******** ************@f1 4g2000cwb.googl egroups.com...

Who is Raymond Hettinger?

The Python developer who, in the last few years, has perhaps been the most
active in coding or recoding library modules, such as itertools and sets,
in C. He also partipates in development discussions, helps with
SourceForge tracker items (RFEs, bugs, and patches) and occasionally posts
here, especially about his modules, for which he is the expert.

Terry J. Reedy

[Reinhold Birkenfeld]

n00m wrote:

Got it! He is a kind of pythonic monsters.

Btw, why it's impossible to reply to old threads?
Namely, there're no more "Reply" link in them.
Only "Reply to author" etc.

Perhaps because you are not using a real Usenet client?

Reinhold

[n00m]

Thank you both for your replies.
And my personal "Thank you!" to Mr. Hettinger for
all his tremendous work!

Perhaps because you are not using a real Usenet client?

Yes! And I don't even know what is the beast - Usenet client.
I just keep in Favorites of my browser (IE 6.0) this link:
http://groups.google.com/group/comp.lang.python/

[antonmuhin]

I hope nobody have posted similar solution (it's tested, but I didn't
submit it to contest):

from bisect import bisect_right as find

def supernumbers(ls ):
indices = [0]*len(ls)
for i, e in enumerate(ls):
indices[e - 1] = i

result = [None]*len(ls)

borders = []

for i in indices:
ind = find(borders, i)
result[i] = ind + 1
if ind == len(borders):
borders.append( i)
else:
borders[ind] = i

return result

At least, it looks shorter than other solutins.
Of course, it allows number of optimizations like
prefetching length and caching borders.append.

If I'm correct, it takes O(n*log (max sequence length)) time that can
be a win for huge datasets.

With the best regards,
anton.

[n00m]

Anton,

it simply does not work! Try supernumbers([2,1,4,5,3]).

[antonmuhin]

Hellom n00m!

I beg your pardon for not having replied for such long time---I was
really busy.

Yes, the posted code doesn't solve the supernumbers problem, but solves
the problem you posted first as I understood it :) --- for each number
find a position of this number in the longest sequence it belongs to.

Ok, anyway, I hope that I can suggest a solution to the supernumbers
problem (see below).

Actually, as I find out today testing it against Tim Peters's solution,
they are of the same kind, but I use one additional optimimization.

And the last note: I didn't persue the maximal performace, rather
clarity of the algorithm.

With the best regards,
anton.

from bisect import bisect as find

def supernumbers(l) :
indices = [0]*len(l)
for i, e in enumerate(l):
indices[e - 1] = i

# Now we can find out index of each element in the longest ascending
sequence it belongs to
# I call this index 'generation'

# ess is an array indexed by generations and holding
# ascending list of generation's elements
# Note: suffix s stands for a list, therefore ess---list of lists
of elements
# Note: ess holds not the elements itself, but elements decreased
by 1
ess = []

# Borders i.e. positions that separate generations
borders = []

for e, i in enumerate(indic es):
ind = find(borders, i)
if ind < len(borders):
borders[ind] = i
ess[ind].append(e)
else:
borders.append( i)
ess.append([e])

# Now we should filter out those elements that don't
# belong to the longest sequences
gens = reversed(ess) # walk generations in reverse order
fes = gens.next() # fes stands for elements' filter
r = fes # r is a list of supernumbers; obvioulsy all the elements of
the latest generation belong to r
for es in gens:
new_fes = []

s = 0 # As elements are sorted ascendingly we can check lesser and
lesser lists
for e in es:
s = find(fes, e, s)
if s == len(fes):
# There is no more elements in filter that are greater
# than elements in the current generation
break
if indices[fes[s]] > indices[e]: # Nice---element e belongs to
the longest sequence
new_fes.append( e)

# Note: the following invariant holds: len(new_fes) > 0

fes = new_fes
r += new_fes

return [e + 1 for e in r] # As we used numbers from 0 internally