Classer des nombres en ordre décroissant

Version imprimable

23/01/2011, 17h56
Alwaysin

Classer des nombres en ordre décroissant

Bonjour,

je dispose d'un fichier dont la structure globale est la suivante :

nom1,score1
nom2,score2
nomN,scoreN

Je cherche à savoir comment je pourrais trier les scores par ordre décroissant, en gardant l'association avec le nom.
Exemple du fichier :
roger,42
bertrand, 87
marion,10

qui donnerait :
bertrand, 87
roger,42
marion,10

Voilà, je souhaite si possible une méthode simple car j'ai essayé des tas de trucs compliqués mais sans parvenir à un résultat.
Merci d'avance.
23/01/2011, 18h04
tomlev
En supposant que tu charges ton fichier dans une liste d'objets comme ça :
Code:

1 2 3 4 5 class ScoreEntry { public string Name { get; set; } public int Score { get; set; } }
Tu peux trier comme ça :
Code:

1 2 List<ScoreEntry> scores = ... List<ScoreEntry> sortedScores = scores.OrderByDescending(e => e.Score).ToList();
La technique ci-dessus crée une nouvelle liste, si tu veux trier la liste sans en créer une nouvelle, tu peux faire ça :

Code:

scores.Sort((a, b) => a.Score.CompareTo(b.Score));

Sinon, si tu veux éviter d'ajouter une nouvelle classe tu as aussi la possiblité d'utiliser la classe Dictionary.

Code:

1
2
3
4
5
6
7
8
9
10
11
Dictionary<string, int> scores = new Dictionary<string, int>();
scores.Add("roger", 42);
scores.Add("bertrand", 87);
scores.Add("marion", 10);
 
var sortedScores = scores.OrderByDescending(x => x.Value);
 
foreach (var score in sortedScores)
{
     Console.WriteLine("Score: " + score.Value);
}

24/01/2011, 10h42
kineton

Il existe même directement une classe SortedDictionary.
24/01/2011, 11h10
tomlev

Citation:

Envoyé par kineton

Il existe même directement une classe SortedDictionary.

Oui mais ça trie sur la clé, pas sur la valeur...

Et pour rafiner tu peux ecrire ton propre compareur

Code:

1
2
3
4
5
6
7
8
9
10
11
 public class ScoreEntryComparer : IComparer<ScoreEntry>
    {
      public int Compare(ScoreEntry a, ScoreEntry b)
      {
        int dif;
        dif = a.Score - b.Score;
        if (dif != 0) return dif;
        dif = a.Name.CompareTo(b.Name);
        return dif;
      }
    };

Dans ce cas tu peux faire

Code:

MaListe.Sort(new ScoreEntryComparer());

Citation:
Envoyé par MigsFR
Sinon, si tu veux éviter d'ajouter une nouvelle classe tu as aussi la possiblité d'utiliser la classe Dictionary.
Code:

1 2 3 4 5 6 7 8 9 10 11 Dictionary<string, int> scores = new Dictionary<string, int>(); scores.Add("roger", 42); scores.Add("bertrand", 87); scores.Add("marion", 10); var sortedScores = scores.OrderByDescending(x => x.Value); foreach (var score in sortedScores) { Console.WriteLine("Score: " + score.Value); }
Le type anonyme marche très bien aussi :)

24/01/2011, 12h11
kineton

Citation:

Envoyé par tomlev

Oui mais ça trie sur la clé, pas sur la valeur...

certes,mais il est également possible de trier les valeurs de la même manière qu'un dictionnary...

http://msdn.microsoft.com/fr-fr/library/yy2kxzhx.aspx
24/01/2011, 13h28
MigsFR

Citation:

Envoyé par PitMaverick78

Le type anonyme marche très bien aussi :)

C'est vrai tant qu'à mettre de l'anonyme autant y aller jusqu'au bout... ;)

Cela dit, j'ai pas mis les vrais types ici par flème mais de manière général il vaut mieux éviter les types anonymes, ne serait-ce que pour la libilisité du code.
24/01/2011, 14h04
tomlev

Citation:

Envoyé par MigsFR

Cela dit, j'ai pas mis les vrais types ici par flème mais de manière général il vaut mieux éviter les types anonymes, ne serait-ce que pour la libilisité du code.

Ah ? Je trouve pas que ça nuise à la lisibilité du code... au contraire, c'est souvent plus clair, parce que le type ne contient que ce dont tu as vraiment besoin.

D'ailleurs je ne vois pas non plus d'autres raisons de pas les utiliser... C'est comme des types normaux, le compilateur génère une vraie classe sous le capot, c'est juste qu'elle n'a pas de nom dans le code.
24/01/2011, 15h41
MigsFR

Citation:

Envoyé par tomlev

Ah ? Je trouve pas que ça nuise à la lisibilité du code... au contraire, c'est souvent plus clair, parce que le type ne contient que ce dont tu as vraiment besoin.

D'ailleurs je ne vois pas non plus d'autres raisons de pas les utiliser... C'est comme des types normaux, le compilateur génère une vraie classe sous le capot, c'est juste qu'elle n'a pas de nom dans le code.

Le problème principal c'est qu'un code avec des "var" partout prend beaucoup plus de temps à le comprendre. Tu es sans cesse obligé d'analyser le code pour comprendre de quel type est ta variable. Tandis qu'avec un type explicitement écrit, t'as l'info directe sous les yeux. Cela ne t'empêche pas de prendre que ce dont tu as besoins, par exemple tu peux déclarer une variable avec "ICollection" même si c'est une List<T> si tu as juste besoin des éléments définis dans ICollection.

Maintenant je te l'accorde, en terme de compilation ça change rien mais quand tu reprends le code de quelqu'un (ou même le tiens après un certain temps) tu gagnes un temps précieux!
24/01/2011, 15h57
tomlev

Citation:

Envoyé par MigsFR

Le problème principal c'est qu'un code avec des "var" partout prend beaucoup plus de temps à le comprendre. Tu es sans cesse obligé d'analyser le code pour comprendre de quel type est ta variable. Tandis qu'avec un type explicitement écrit, t'as l'info directe sous les yeux.

Faut voir... en général le type est assez évident d'après l'expression d'initialisation. Si ce n'est pas évident, je mets le type explicitement...
D'une manière générale, je n'aime pas me répéter, donc j'évite ce genre de truc :

Code:

UnTypeAvecUnNomTropLong x = new UnTypeAvecUnNomTropLong();

Avec var, pas besoin de répéter l'évidence...

Enfin bon, on s'écarte un peu du sujet de départ ;)
25/01/2011, 10h02
MigsFR

Citation:

Envoyé par tomlev

Enfin bon, on s'écarte un peu du sujet de départ ;)

Oui on s'écarte, donc je vais clore le débat avec un lien:

http://richarddingwall.name/2008/06/...-it-all-wrong/

:ccool: