Écrire table de frequences qui, à partir d'un dictionnaire…

def table_de_frequences(effectifs):
    """Frequences en pourcentage, a partir d'un dictionnaire d'effectifs.

    Precondition : les effectifs sont des entiers >= 0, de somme > 0.
    """
    total = sum(effectifs.values())
    assert total > 0, "aucun effectif : la frequence n'a pas de sens"
    return {cle: 100 * n / total for cle, n in effectifs.items()}

Le résultat sur onze clés.

onze = {chr(97 + i): 1 for i in range(11)}
somme = sum(table_de_frequences(onze).values())
assert somme == 100.00000000000001
assert somme != 100
assert abs(somme - 100) < 1e-9

Chaque fréquence vaut $100/11$, un nombre dont l'écriture binaire est infinie : la division rend la meilleure approximation possible, et onze approximations additionnées ne retombent pas exactement sur $100$. C'est le chapitre 2, appliqué ici.

Le comptage, et ce qui rend le défaut sournois.

en_defaut = [n for n in range(1, 101)
             if sum(table_de_frequences({i: 1 for i in range(n)}).values()) != 100]
assert en_defaut == [11, 22, 39, 44, 78, 83, 88, 91, 97]
assert len(en_defaut) == 9

Neuf tailles sur cent tombent à côté : $91\%$ des cas donnent exactement $100$. C'est précisément ce qui rend le défaut dangereux — un programme testé sur dix, vingt ou cinquante catégories passe, et échoue le jour où il en rencontre onze. Un test qui n'aurait essayé que $n=10$ aurait donné toutes les garanties, et n'en aurait donné aucune.

Ce qu'il faut en conclure, et une seule chose. Ne jamais tester l'égalité de deux flottants. On écrit abs(somme - 100) < 1e-9, jamais somme == 100. Le seuil se choisit en fonction du problème ; ce qui ne se négocie pas, c'est qu'il y en ait un.