O ( n log log k )

We consider the complexity of computing a longest increasing subsequence parameterised by the length of the output. Namely, we show that the maximal length k of an increasing subsequence of a permutation of the set of integers { 1 , 2 , . . . , n } can be computed in time O ( n log log k ) in the RAM model, improving the previous 30-year bound of O ( n log log n ) . The optimality of the new bound is an open question.


Computing a Longest Increasing Subsequence of Length k in Time
Liben-Nowell et al. [7] explore the LIS problem in the streaming model which typically aims at reducing to a polylogarithmic amount the memory space required by the computation, in addition to effi cient running time (see also [10]).
A direct solution to computing a longest increasing subsequence, running in O(n log n) time, was proposed by Fredman [4].The solution is optimal if the elements are drawn from an arbitrary set due to the Ω(n log n) lower bound for sorting n elements.Parameterised by the LIS length k, the running time is O(n log k).On integer alphabets, the fastest known solution runs in O(n log log n) time (see [16] and references therein).It relies on the priority search trees of van Emde Boas [14,15], which provide O(log log n) amortised time per operation when keys are drawn from the set {1, 2, . . ., n}.
The solution presented in this paper breaks the long-standing O(n log log n) upper bound down to O(n log log k), where k is the maximal length of increasing subsequences.It extends immediately to the computation of a longest increasing subsequence (not only its length).We assume the RAM model for evaluating the running time and the algorithm can be viewed as a parameterised solution (k is the length of the output).This is certainly a result mostly of theoretical nature but it opens the road to a possible linear-time LIS computation.
To get the O(n log log k) bound, we feed the priority queue used in the standard algorithm with elements drawn from a restricted range.This is done through a series of careful renamings of the elements.Downsizing the key universe to size O(k) leads the priority queue to work in amortised time O(log log k) and yields the announced result.But the length k of a longest increasing subsequence is not an input of the algorithm: we show that an approximation of it is enough, and how to compute such an approximation.Section 2 recalls the core algorithm for computing a longest increasing subsequence and Section 3 describes our improved solution.

CORE ALGORITHM
We recall the core algorithm for computing a longest increasing subsequence, starting with the computation of its length.
Elements are processed in the order π(1), π(2), . . ., π(n).Conceptually we compute, for each length ℓ = 1, 2, .., the smallest last element that can end an increasing subsequence of that length.It is called the best element for that length and denoted by B[ℓ].
Note that best elements B [1], B [2], . . ., form an increasing sequence.This fact is used for the choice of a data structure to implement the list and is essential for getting an effi cient computation.
One step in the algorithm is as follows (see [1]).The currently processed element π(i) can extend any increasing subsequence having the last element smaller than it.If π(i) is larger than all the best elements computed so far for the sequence (π(1), π(2), . . ., π(i − 1)), it produces an increasing subsequence longer than any previous one, for which it is the last element.Otherwise, π(i) becomes the best element for an existing length: it replaces the smallest element greater than it in B. This leads to the next algorithm to compute the maximal length of increasing subsequences of S, in which B is a priority queue that stores the best elements.
Computing a longest increasing subsequence (not just its length) is a simple extension of the algorithm.Instead of storing best elements only in the queue B, it suffi ces to store pairs of the form (x, y) where y is a best element predecessor of x.Then, tracing back predecessor information from the last best element in B produces a longest increasing subsequence.
The running time of the algorithm relies mainly on the implementation of the queue B of best elements.Using an array and binary search (since elements are naturally sorted) to locate the position of the next element x (i.e. to implement the operations Insert, Delete, prev , and succ) yields a O(n log n) running time algorithm [4].
Using a more sophisticated priority list implementation in the form of van Emde Boas trees [14,15], each step can be performed in O(log log n) amortised time yielding an overall O(n log log n) running time algorithm [6].
In the next section we keep the same algorithm and the same priority list implementation but process the initial sequence differently to get the announced running time.

IMPROVEMENT BY RENAMING
In order to compute a longest increasing subsequence, having length k, from the sequence S of length n in time O(n log log k) we want a priority queue that works in O(log log k) amortised time per operation.Our strategy to get this result is to downsize the key universe of the queue to size O(k).This is done through a series of careful renamings of the elements of the sequence.
We assume that a good approximation m of k, m ≥ k, is given.We discuss how to fi nd such an m at the end of the section.
The solution splits the initial sequence S into blocks of size m (except of course the last block that can be smaller), and processes each block separately in the order of the sequence.We discuss these two points.
Splitting S into blocks and sorting them.The sequence S is split into blocks, C j , j = 1, . . ., ⌈n/m⌉, of consecutive elements: We also consider sorted blocks: C s j is the sorted list of elements of C j .Sorted and unsorted blocks are kept in memory.
Processing the third block.Queue B = (a, b, d) corresponds to the list of elements (1,2,7).It is merged with C s 3 producing the list (1,2,3,4,5,7,10).The content of B is update to (a, b, f).After processing keys g, d, e, c of elements of C 3 , the contents of queue B are successively: (a, b, f, g), (a, b, d, g), (a, b, d, e), and (a, b, c, e).
The list of elements whose keys are in B is: (1, 2, 3, 5), which give an LIS of length 4 ending with 5. Computing an LIS can be done as explained above.
In the implementation of Algorithm LIS, the cost of all renamings is O(n) if radix sorting is used.Each operation on the queue (Insert, Delete, Update) takes only O(log log m) amortised time because the elements in B belong to the set {1, 2, . . ., 2m}.This gives the following statement.

Lemma 1
The implementation of Algorithm LIS with blocks of size m, m ≥ k, and renamings runs in time O(n log log m) for a sequence of length n.
Finding the size of blocks.In above presentation an approximation m of the length k of longest increasing subsequences of S satisfying m ≥ k, is assumed to be given.We discuss now how to fi nd it.
The idea is to try increasing values of m until we get the approximation leading to the announced running time.Starting with some value m 0 , expected to be no more than k, for m (for instance, m 0 = 4), we consider the sequence For a given value of m in the sequence, we run Algorithm LIS implemented as described above but with this change: the run stops if the size of the queue B becomes larger than m, and the algorithm signals the fact.Therefore, the fi rst time the algorithm does not stop due to this condition is when the value of m is the smallest value in the list that is larger than k.Let m i be this value.Doing so, the running time of the modifi ed Algorithm LIS is O(n log log m j ) for 0 ≤ j < i because during all these runs the queue B contains no more than m j elements that all belong to {1, 2, . . ., 2m j }.For the value m i the run fi nishes normally because the condition of its complete execution, m ≥ k, is met.The running time for this value of m is O(n log log m i ).
Noting that log log(m log m ) = 2 log log m, the total running of the whole execution of Algorithm LIS for m = m 0 , m 1 , . . ., m i is O(n(Σ j=0,...,i 1/2 j−1 ) log log m i ), which is also O(n log log m i ), and eventually O(n log log k) because m < k log k implies log log m < 2 log log k.
The conclusion lies in the next statement.
Theorem 2 Let S be a permutation of the integers {1, 2, . . ., n} and let k be the maximal length of its increasing subsequences.Computing k and extracting a longest increasing subsequence from S can be done in time O(n log log k).

CONCLUSION
The result stated in Theorem 2 is valid for sequences of integers with repetitions.Although the problem seems more general its solution comes down to that of a permutation as follows: each element x occurring at position i in S is renamed as the rank of the pair (x, i) in the lexicographically sorted list of all these pairs.This process is yet similar to the renaming by ranking used in our solution.
As to whether the upper bound in Theorem 2 is optimal, and not linear, raises the question of fi nding a totally different approach to compute longest increasing subsequences because the implementation of Schensted's algorithm is squeezed as much as possible with the present solution.But this is unlikely to happen if we consider that many researchers have already worked on the problem.
Another possible way for exploring the complexity of the problem is to use other techniques for sorting integers (see for example [5]).But some of them are affi liated to van Emde Boas' method and are mostly designed to avoid the non-linear space coming from the large range of input integers.This is not the problem we have for computing the LIS of a permutation, though the techniques might simplify the solution or give a direct answer to the question.