@@ -59,12 +59,12 @@ msgid ""
59
59
"\" max heap\" is more common in texts because of its suitability for in-place "
60
60
"sorting)."
61
61
msgstr ""
62
- "L'API ci-dessous diffère de la file de priorité classique par deux aspects : "
63
- "(a) L 'indiçage commence à zéro. Cela complexifie légèrement la relation "
62
+ "L'API ci-dessous diffère de la file de priorité classique par deux aspects : "
63
+ "(a) l 'indiçage commence à zéro. Cela complexifie légèrement la relation "
64
64
"entre l'indice d'un nœud et les indices de ses fils mais est alignée avec "
65
65
"l'indiçage commençant à zéro que Python utilise. (b) La méthode *pop* "
66
- "renvoie le plus petit élément et non le plus grand (appelé « tas-min » dans "
67
- "les manuels scolaires ; le « tas-max » étant généralement plus courant dans "
66
+ "renvoie le plus petit élément et non le plus grand (appelé « tas-min » dans "
67
+ "les manuels scolaires ; le « tas-max » étant généralement plus courant dans "
68
68
"la littérature car il permet le classement sans tampon)."
69
69
70
70
#: ../Doc/library/heapq.rst:34
@@ -74,8 +74,8 @@ msgid ""
74
74
"the heap invariant!"
75
75
msgstr ""
76
76
"Ces deux points permettent d'aborder le tas comme une liste Python standard "
77
- "sans surprise : ``heap[0]`` est le plus petit élément tandis que ``heap."
78
- "sort()`` ne modifie pas le tas !"
77
+ "sans surprise : ``heap[0]`` est le plus petit élément et ``heap.sort()`` "
78
+ "conserve l'invariant du tas !"
79
79
80
80
#: ../Doc/library/heapq.rst:38
81
81
msgid ""
@@ -88,7 +88,7 @@ msgstr ""
88
88
89
89
#: ../Doc/library/heapq.rst:41
90
90
msgid "The following functions are provided:"
91
- msgstr "Les fonctions suivantes sont fournies :"
91
+ msgstr "Les fonctions suivantes sont fournies :"
92
92
93
93
#: ../Doc/library/heapq.rst:46
94
94
msgid "Push the value *item* onto the *heap*, maintaining the heap invariant."
@@ -244,9 +244,9 @@ msgid ""
244
244
"Heap elements can be tuples. This is useful for assigning comparison values "
245
245
"(such as task priorities) alongside the main record being tracked::"
246
246
msgstr ""
247
- "Les éléments d'un tas peuvent être des n -uplets. C'est pratique pour "
247
+ "Les éléments d'un tas peuvent être des *n* -uplets. C'est pratique pour "
248
248
"assigner des valeurs de comparaison (par exemple, des priorités de tâches) "
249
- "en plus de l'élément qui est suivi ::"
249
+ "en plus de l'élément qui est suivi ::"
250
250
251
251
#: ../Doc/library/heapq.rst:165
252
252
msgid "Priority Queue Implementation Notes"
@@ -259,15 +259,15 @@ msgid ""
259
259
msgstr ""
260
260
"Une `file de priorité <https://fr.wikipedia.org/wiki/File_de_priorit"
261
261
"%C3%A9>`_ est une application courante des tas et présente plusieurs défis "
262
- "d'implémentation :"
262
+ "d'implémentation :"
263
263
264
264
#: ../Doc/library/heapq.rst:170
265
265
msgid ""
266
266
"Sort stability: how do you get two tasks with equal priorities to be "
267
267
"returned in the order they were originally added?"
268
268
msgstr ""
269
- "Stabilité du classement : comment s'assurer que deux tâches avec la même "
270
- "priorité sont renvoyées dans l'ordre de leur ajout ?"
269
+ "Stabilité du classement : comment s'assurer que deux tâches avec la même "
270
+ "priorité sont renvoyées dans l'ordre de leur ajout ?"
271
271
272
272
#: ../Doc/library/heapq.rst:173
273
273
msgid ""
@@ -282,15 +282,15 @@ msgid ""
282
282
"the heap?"
283
283
msgstr ""
284
284
"Si la priorité d'une tâche change, comment la déplacer à sa nouvelle "
285
- "position dans le tas ?"
285
+ "position dans le tas ?"
286
286
287
287
#: ../Doc/library/heapq.rst:180
288
288
msgid ""
289
289
"Or if a pending task needs to be deleted, how do you find it and remove it "
290
290
"from the queue?"
291
291
msgstr ""
292
292
"Si une tâche en attente doit être supprimée, comment la trouver et la "
293
- "supprimer de la file ?"
293
+ "supprimer de la file ?"
294
294
295
295
#: ../Doc/library/heapq.rst:183
296
296
msgid ""
@@ -349,7 +349,7 @@ msgid ""
349
349
"representation for a tournament. The numbers below are *k*, not ``a[k]``::"
350
350
msgstr ""
351
351
"L'invariant étrange ci-dessus est une représentation efficace en mémoire "
352
- "d'un tournoi. Les nombres ci-dessous sont *k* et non ``a[k]`` ::"
352
+ "d'un tournoi. Les nombres ci-dessous sont *k* et non ``a[k]`` ::"
353
353
354
354
#: ../Doc/library/heapq.rst:247
355
355
msgid ""
@@ -372,7 +372,7 @@ msgstr ""
372
372
"Afin d'occuper moins de mémoire, on remplace le vainqueur lors de sa "
373
373
"promotion par un autre élément à un plus bas niveau. La règle devient alors "
374
374
"qu'un nœud et les deux nœuds qu'il chapeaute contiennent trois éléments "
375
- "différents, mais le nœud supérieur « gagne » contre les deux nœuds "
375
+ "différents, mais le nœud supérieur « gagne » contre les deux nœuds "
376
376
"inférieurs."
377
377
378
378
#: ../Doc/library/heapq.rst:256
@@ -387,7 +387,7 @@ msgid ""
387
387
msgstr ""
388
388
"Si cet invariant de tas est vérifié à tout instant, alors l'élément à "
389
389
"l'indice 0 est le vainqueur global. L'algorithme le plus simple pour le "
390
- "retirer et trouver le vainqueur « suivant » consiste à déplacer un perdant "
390
+ "retirer et trouver le vainqueur « suivant » consiste à déplacer un perdant "
391
391
"(par exemple le nœud 30 dans le diagramme ci-dessus) à la position 0, puis à "
392
392
"faire redescendre cette nouvelle racine dans l'arbre en échangeant sa valeur "
393
393
"avec celle d'un de ses fils jusqu'à ce que l'invariant soit rétabli. Cette "
@@ -406,11 +406,11 @@ msgid ""
406
406
"easily go into the heap. So, a heap is a good structure for implementing "
407
407
"schedulers (this is what I used for my MIDI sequencer :-)."
408
408
msgstr ""
409
- "Une propriété agréable de cet algorithme est qu'il possible d'insérer "
409
+ "Une propriété agréable de cet algorithme est qu'il est possible d'insérer "
410
410
"efficacement de nouveaux éléments en cours de classement, du moment que les "
411
- "éléments insérés ne sont pas « meilleurs » que le dernier élément qui a été "
411
+ "éléments insérés ne sont pas « meilleurs » que le dernier élément qui a été "
412
412
"extrait. Ceci s'avère très utile dans des simulations où l'arbre contient la "
413
- "liste des événements arrivants et que la condition de « victoire » est le "
413
+ "liste des événements arrivants et que la condition de « victoire » est le "
414
414
"plus petit temps d'exécution planifié. Lorsqu'un événement programme "
415
415
"l'exécution d'autres événements, ceux-ci sont planifiés pour le futur et "
416
416
"peuvent donc rejoindre le tas. Ainsi, le tas est une bonne structure pour "
@@ -426,7 +426,7 @@ msgid ""
426
426
"efficient overall, yet the worst cases might be terrible."
427
427
msgstr ""
428
428
"Plusieurs structures ont été étudiées en détail pour implémenter des "
429
- "ordonnanceurs et les tas sont bien adaptés : ils sont raisonnablement "
429
+ "ordonnanceurs et les tas sont bien adaptés : ils sont raisonnablement "
430
430
"rapides, leur vitesse est presque constante et le pire cas ne diffère pas "
431
431
"trop du cas moyen. S'il existe des représentations qui sont plus efficaces "
432
432
"en général, les pires cas peuvent être terriblement mauvais."
@@ -469,12 +469,12 @@ msgid ""
469
469
msgstr ""
470
470
"Qui plus est, si vous écrivez l'élément 0 sur le disque et que vous recevez "
471
471
"en entrée un élément qui n'est pas adapté au tournoi actuel (parce que sa "
472
- "valeur « gagne » par rapport à la dernière valeur de sortie), alors il ne "
472
+ "valeur « gagne » par rapport à la dernière valeur de sortie), alors il ne "
473
473
"peut pas être stocké dans le tas donc la taille de ce dernier diminue. La "
474
474
"mémoire libérée peut être réutilisée immédiatement pour progressivement "
475
475
"construire un deuxième tas, qui croit à la même vitesse que le premier "
476
476
"décroît. Lorsque le premier tas a complètement disparu, vous échangez les "
477
- "tas et démarrez une nouvelle séquence. Malin et plutôt efficace !"
477
+ "tas et démarrez une nouvelle séquence. Malin et plutôt efficace !"
478
478
479
479
#: ../Doc/library/heapq.rst:296
480
480
msgid ""
@@ -507,8 +507,8 @@ msgstr ""
507
507
"que de la lecture séquentielle, comme les gros lecteurs à bandes, le besoin "
508
508
"était différent et il fallait être malin pour s'assurer (bien à l'avance) "
509
509
"que chaque mouvement de bande serait le plus efficace possible (c'est-à-dire "
510
- "participerait au mieux à l'« avancée » de la fusion). Certaines cassettes "
510
+ "participerait au mieux à l'« avancée » de la fusion). Certaines cassettes "
511
511
"pouvaient même lire à l'envers et cela était aussi utilisé pour éviter de "
512
512
"remonter dans le temps. Croyez-moi, les bons tris sur bandes étaient "
513
- "spectaculaires à regarder ! Depuis la nuit des temps, trier a toujours été "
514
- "le Grand Art ! ☺"
513
+ "spectaculaires à regarder ! Depuis la nuit des temps, trier a toujours été "
514
+ "le Grand Art ! ☺"
0 commit comments