# Copyright (C) 2001-2018, Python Software Foundation # For licence information, see README file. # msgid "" msgstr "" "Project-Id-Version: Python 3.6\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2018-06-28 15:29+0200\n" "PO-Revision-Date: 2018-07-05 09:53+0200\n" "Last-Translator: FULL NAME \n" "Language-Team: FRENCH \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../Doc/library/heapq.rst:2 msgid ":mod:`heapq` --- Heap queue algorithm" msgstr "" #: ../Doc/library/heapq.rst:12 msgid "**Source code:** :source:`Lib/heapq.py`" msgstr "**Code source :** :source:`Lib/heapq.py`" #: ../Doc/library/heapq.rst:16 msgid "" "This module provides an implementation of the heap queue algorithm, also " "known as the priority queue algorithm." msgstr "" #: ../Doc/library/heapq.rst:19 msgid "" "Heaps are binary trees for which every parent node has a value less than or " "equal to any of its children. This implementation uses arrays for which " "``heap[k] <= heap[2*k+1]`` and ``heap[k] <= heap[2*k+2]`` for all *k*, " "counting elements from zero. For the sake of comparison, non-existing " "elements are considered to be infinite. The interesting property of a heap " "is that its smallest element is always the root, ``heap[0]``." msgstr "" #: ../Doc/library/heapq.rst:26 msgid "" "The API below differs from textbook heap algorithms in two aspects: (a) We " "use zero-based indexing. This makes the relationship between the index for " "a node and the indexes for its children slightly less obvious, but is more " "suitable since Python uses zero-based indexing. (b) Our pop method returns " "the smallest item, not the largest (called a \"min heap\" in textbooks; a " "\"max heap\" is more common in texts because of its suitability for in-place " "sorting)." msgstr "" #: ../Doc/library/heapq.rst:33 msgid "" "These two make it possible to view the heap as a regular Python list without " "surprises: ``heap[0]`` is the smallest item, and ``heap.sort()`` maintains " "the heap invariant!" msgstr "" #: ../Doc/library/heapq.rst:37 msgid "" "To create a heap, use a list initialized to ``[]``, or you can transform a " "populated list into a heap via function :func:`heapify`." msgstr "" #: ../Doc/library/heapq.rst:40 msgid "The following functions are provided:" msgstr "Les fonctions suivantes sont fournies :" #: ../Doc/library/heapq.rst:45 msgid "Push the value *item* onto the *heap*, maintaining the heap invariant." msgstr "" #: ../Doc/library/heapq.rst:50 msgid "" "Pop and return the smallest item from the *heap*, maintaining the heap " "invariant. If the heap is empty, :exc:`IndexError` is raised. To access " "the smallest item without popping it, use ``heap[0]``." msgstr "" #: ../Doc/library/heapq.rst:57 msgid "" "Push *item* on the heap, then pop and return the smallest item from the " "*heap*. The combined action runs more efficiently than :func:`heappush` " "followed by a separate call to :func:`heappop`." msgstr "" #: ../Doc/library/heapq.rst:64 msgid "Transform list *x* into a heap, in-place, in linear time." msgstr "" #: ../Doc/library/heapq.rst:69 msgid "" "Pop and return the smallest item from the *heap*, and also push the new " "*item*. The heap size doesn't change. If the heap is empty, :exc:" "`IndexError` is raised." msgstr "" #: ../Doc/library/heapq.rst:72 msgid "" "This one step operation is more efficient than a :func:`heappop` followed " "by :func:`heappush` and can be more appropriate when using a fixed-size " "heap. The pop/push combination always returns an element from the heap and " "replaces it with *item*." msgstr "" #: ../Doc/library/heapq.rst:77 msgid "" "The value returned may be larger than the *item* added. If that isn't " "desired, consider using :func:`heappushpop` instead. Its push/pop " "combination returns the smaller of the two values, leaving the larger value " "on the heap." msgstr "" #: ../Doc/library/heapq.rst:83 msgid "The module also offers three general purpose functions based on heaps." msgstr "" #: ../Doc/library/heapq.rst:88 msgid "" "Merge multiple sorted inputs into a single sorted output (for example, merge " "timestamped entries from multiple log files). Returns an :term:`iterator` " "over the sorted values." msgstr "" #: ../Doc/library/heapq.rst:92 msgid "" "Similar to ``sorted(itertools.chain(*iterables))`` but returns an iterable, " "does not pull the data into memory all at once, and assumes that each of the " "input streams is already sorted (smallest to largest)." msgstr "" #: ../Doc/library/heapq.rst:96 msgid "" "Has two optional arguments which must be specified as keyword arguments." msgstr "A deux arguments optionnels qui doivent être fournis par mot clef." #: ../Doc/library/heapq.rst:98 msgid "" "*key* specifies a :term:`key function` of one argument that is used to " "extract a comparison key from each input element. The default value is " "``None`` (compare the elements directly)." msgstr "" "*key* spécifie une :term:`key function` d'un argument utilisée pour extraire " "une clef de comparaison de chaque élément de la liste. La valeur par défaut " "est ``None`` (compare les éléments directement)." #: ../Doc/library/heapq.rst:102 msgid "" "*reverse* is a boolean value. If set to ``True``, then the input elements " "are merged as if each comparison were reversed. To achieve behavior similar " "to ``sorted(itertools.chain(*iterables), reverse=True)``, all iterables must " "be sorted from largest to smallest." msgstr "" "*reverse* est une valeur booléenne. Si elle est ``True``, la liste " "d'éléments est fusionnée comme si toutes les comparaisons étaient inversées. " "Pour obtenir un comportement similaire à ``sorted(itertools." "chain(*iterables), reverse=True)``, tous les itérables doivent être classés " "par ordre décroissant." #: ../Doc/library/heapq.rst:107 msgid "Added the optional *key* and *reverse* parameters." msgstr "Ajout des paramètres optionnels *key* et *reverse*." #: ../Doc/library/heapq.rst:113 msgid "" "Return a list with the *n* largest elements from the dataset defined by " "*iterable*. *key*, if provided, specifies a function of one argument that " "is used to extract a comparison key from each element in the iterable: " "``key=str.lower`` Equivalent to: ``sorted(iterable, key=key, reverse=True)[:" "n]``" msgstr "" #: ../Doc/library/heapq.rst:122 msgid "" "Return a list with the *n* smallest elements from the dataset defined by " "*iterable*. *key*, if provided, specifies a function of one argument that " "is used to extract a comparison key from each element in the iterable: " "``key=str.lower`` Equivalent to: ``sorted(iterable, key=key)[:n]``" msgstr "" #: ../Doc/library/heapq.rst:128 msgid "" "The latter two functions perform best for smaller values of *n*. For larger " "values, it is more efficient to use the :func:`sorted` function. Also, when " "``n==1``, it is more efficient to use the built-in :func:`min` and :func:" "`max` functions. If repeated usage of these functions is required, consider " "turning the iterable into an actual heap." msgstr "" #: ../Doc/library/heapq.rst:136 msgid "Basic Examples" msgstr "" #: ../Doc/library/heapq.rst:138 msgid "" "A `heapsort `_ can be implemented by " "pushing all values onto a heap and then popping off the smallest values one " "at a time::" msgstr "" #: ../Doc/library/heapq.rst:151 msgid "" "This is similar to ``sorted(iterable)``, but unlike :func:`sorted`, this " "implementation is not stable." msgstr "" #: ../Doc/library/heapq.rst:154 msgid "" "Heap elements can be tuples. This is useful for assigning comparison values " "(such as task priorities) alongside the main record being tracked::" msgstr "" #: ../Doc/library/heapq.rst:167 msgid "Priority Queue Implementation Notes" msgstr "" #: ../Doc/library/heapq.rst:169 msgid "" "A `priority queue `_ is common " "use for a heap, and it presents several implementation challenges:" msgstr "" #: ../Doc/library/heapq.rst:172 msgid "" "Sort stability: how do you get two tasks with equal priorities to be " "returned in the order they were originally added?" msgstr "" #: ../Doc/library/heapq.rst:175 msgid "" "Tuple comparison breaks for (priority, task) pairs if the priorities are " "equal and the tasks do not have a default comparison order." msgstr "" #: ../Doc/library/heapq.rst:178 msgid "" "If the priority of a task changes, how do you move it to a new position in " "the heap?" msgstr "" #: ../Doc/library/heapq.rst:181 msgid "" "Or if a pending task needs to be deleted, how do you find it and remove it " "from the queue?" msgstr "" #: ../Doc/library/heapq.rst:184 msgid "" "A solution to the first two challenges is to store entries as 3-element list " "including the priority, an entry count, and the task. The entry count " "serves as a tie-breaker so that two tasks with the same priority are " "returned in the order they were added. And since no two entry counts are the " "same, the tuple comparison will never attempt to directly compare two tasks." msgstr "" #: ../Doc/library/heapq.rst:190 msgid "" "Another solution to the problem of non-comparable tasks is to create a " "wrapper class that ignores the task item and only compares the priority " "field::" msgstr "" #: ../Doc/library/heapq.rst:201 msgid "" "The remaining challenges revolve around finding a pending task and making " "changes to its priority or removing it entirely. Finding a task can be done " "with a dictionary pointing to an entry in the queue." msgstr "" #: ../Doc/library/heapq.rst:205 msgid "" "Removing the entry or changing its priority is more difficult because it " "would break the heap structure invariants. So, a possible solution is to " "mark the entry as removed and add a new entry with the revised priority::" msgstr "" #: ../Doc/library/heapq.rst:239 msgid "Theory" msgstr "" #: ../Doc/library/heapq.rst:241 msgid "" "Heaps are arrays for which ``a[k] <= a[2*k+1]`` and ``a[k] <= a[2*k+2]`` for " "all *k*, counting elements from 0. For the sake of comparison, non-existing " "elements are considered to be infinite. The interesting property of a heap " "is that ``a[0]`` is always its smallest element." msgstr "" #: ../Doc/library/heapq.rst:246 msgid "" "The strange invariant above is meant to be an efficient memory " "representation for a tournament. The numbers below are *k*, not ``a[k]``::" msgstr "" #: ../Doc/library/heapq.rst:259 msgid "" "In the tree above, each cell *k* is topping ``2*k+1`` and ``2*k+2``. In a " "usual binary tournament we see in sports, each cell is the winner over the " "two cells it tops, and we can trace the winner down the tree to see all " "opponents s/he had. However, in many computer applications of such " "tournaments, we do not need to trace the history of a winner. To be more " "memory efficient, when a winner is promoted, we try to replace it by " "something else at a lower level, and the rule becomes that a cell and the " "two cells it tops contain three different items, but the top cell \"wins\" " "over the two topped cells." msgstr "" #: ../Doc/library/heapq.rst:268 msgid "" "If this heap invariant is protected at all time, index 0 is clearly the " "overall winner. The simplest algorithmic way to remove it and find the " "\"next\" winner is to move some loser (let's say cell 30 in the diagram " "above) into the 0 position, and then percolate this new 0 down the tree, " "exchanging values, until the invariant is re-established. This is clearly " "logarithmic on the total number of items in the tree. By iterating over all " "items, you get an O(n log n) sort." msgstr "" #: ../Doc/library/heapq.rst:275 msgid "" "A nice feature of this sort is that you can efficiently insert new items " "while the sort is going on, provided that the inserted items are not \"better" "\" than the last 0'th element you extracted. This is especially useful in " "simulation contexts, where the tree holds all incoming events, and the \"win" "\" condition means the smallest scheduled time. When an event schedules " "other events for execution, they are scheduled into the future, so they can " "easily go into the heap. So, a heap is a good structure for implementing " "schedulers (this is what I used for my MIDI sequencer :-)." msgstr "" #: ../Doc/library/heapq.rst:284 msgid "" "Various structures for implementing schedulers have been extensively " "studied, and heaps are good for this, as they are reasonably speedy, the " "speed is almost constant, and the worst case is not much different than the " "average case. However, there are other representations which are more " "efficient overall, yet the worst cases might be terrible." msgstr "" #: ../Doc/library/heapq.rst:290 msgid "" "Heaps are also very useful in big disk sorts. You most probably all know " "that a big sort implies producing \"runs\" (which are pre-sorted sequences, " "whose size is usually related to the amount of CPU memory), followed by a " "merging passes for these runs, which merging is often very cleverly " "organised [#]_. It is very important that the initial sort produces the " "longest runs possible. Tournaments are a good way to achieve that. If, " "using all the memory available to hold a tournament, you replace and " "percolate items that happen to fit the current run, you'll produce runs " "which are twice the size of the memory for random input, and much better for " "input fuzzily ordered." msgstr "" #: ../Doc/library/heapq.rst:300 msgid "" "Moreover, if you output the 0'th item on disk and get an input which may not " "fit in the current tournament (because the value \"wins\" over the last " "output value), it cannot fit in the heap, so the size of the heap " "decreases. The freed memory could be cleverly reused immediately for " "progressively building a second heap, which grows at exactly the same rate " "the first heap is melting. When the first heap completely vanishes, you " "switch heaps and start a new run. Clever and quite effective!" msgstr "" #: ../Doc/library/heapq.rst:308 msgid "" "In a word, heaps are useful memory structures to know. I use them in a few " "applications, and I think it is good to keep a 'heap' module around. :-)" msgstr "" #: ../Doc/library/heapq.rst:312 msgid "Footnotes" msgstr "Notes" #: ../Doc/library/heapq.rst:313 msgid "" "The disk balancing algorithms which are current, nowadays, are more annoying " "than clever, and this is a consequence of the seeking capabilities of the " "disks. On devices which cannot seek, like big tape drives, the story was " "quite different, and one had to be very clever to ensure (far in advance) " "that each tape movement will be the most effective possible (that is, will " "best participate at \"progressing\" the merge). Some tapes were even able " "to read backwards, and this was also used to avoid the rewinding time. " "Believe me, real good tape sorts were quite spectacular to watch! From all " "times, sorting has always been a Great Art! :-)" msgstr ""