• # piste

    Posté par  . Évalué à 3.

    je me demande si ça n'est pas une sorte d'héritage de l'impression ? Lettres majuscules utilisées en priorité et ça se retrouve même sur nos claviers, hérité des machines à écrire.

    Du coup, ils ont peut-être commencé par les majuscules ??

    • [^] # Re: piste

      Posté par  . Évalué à 10.

      Les premiers encodage de caractères en informatique n'avaient pas de notion de casse, tout était en majuscule (et sur moins que 7 bits). Ça me semble donc logique que les caractères minuscules, venus après, aient pris des valeurs supérieurs.

      Après, il y a peut-être un autre raison, par exemple pour avoir les caractères majuscule avant les minuscule en triant numériquement.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: piste

        Posté par  . Évalué à 6. Dernière modification le 21 novembre 2019 à 21:42.

        Autre élément rigolo: une lettre minuscule s'obtient en prenant la lettre majuscule et en mettant le bit 5 à 1 (et inversement):

        >>> chr(ord('A') | 2**5)
'a'
>>> chr(ord('a') & ~2**5)
'A'

        L'implémentation de toupper() et tolower() en ASCII est triviale et laissée en exercice au lecteur.

        • [^] # Re: piste

          Posté par  . Évalué à 3.

          Autre élément rigolo:

          Tu sous entends que c’est du hasard en utilisant « rigolo » alors que au contraire, c’était voulu dès le départ, pour pouvoir comparer des chaines facilement avec une conversion rapide et facile sur des ordinateur d’une puissance toute relative.

          if ((chaine1[index] | (1<<5)) > (chaine2[index] | (1<<5)))

          permet de tester sans savoir si on a une majuscule ou une minuscule pour le coût d’une instruction binaire que tout CPU fait rapidement. Évidemment, ça a été pensé sans accent.

          • [^] # Re: piste

            Posté par  (site web personnel) . Évalué à 7.

            Ce n'est même pas la vrai raison. C'est surtout que pour la douce époque des programmes avec carte perforées, passer de majuscule à minuscule consistait à créer un trou au même endroit pour toutes les lettres ASCII (je ne sais pas si c'était possible de le boucher si nécessaire).

            • [^] # Re: piste

              Posté par  . Évalué à 5. Dernière modification le 22 novembre 2019 à 17:19.

              je ne sais pas si c'était possible de le boucher

              Ça se faisait avec un adhésif transparent et du papier : un petit morceau de papier sur le trou, et l'adhésif par dessus qui faisait le tour du ruban pour ne pas se décoller.

              Il fallait aussi perforer l'adhésif au niveau des trous afin qu'il ne réfléchisse pas la lumière à cause de certains système de détection des trous, mais c'était peut-être une légende urbaine de l'époque.

          • [^] # Re: piste

            Posté par  . Évalué à 3. Dernière modification le 22 novembre 2019 à 22:00.

            Je ne sous-entend pas du tout que c'est du hasard, je parle d'ailleurs de la trivialité de la conversion dans mon commentaire… Ça me paraissait évident que c'était fait exprès.

  • # Numéro de code ASCII?

    Posté par  (site web personnel) . Évalué à 0.

    Le A a comme code ASCII 65 et le a 97, c'est peut être la justification.
    https://fr.wikibooks.org/wiki/Les_ASCII_de_0_%C3%A0_127/La_table_ASCII

    • [^] # Re: Numéro de code ASCII?

      Posté par  . Évalué à 8.

      Ce n'est pas peut-être, c'est la justification. La question, c'est pourquoi les majuscules ont un code plus petits que les minuscules.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Numéro de code ASCII?

        Posté par  . Évalué à 2. Dernière modification le 21 novembre 2019 à 11:08.

        Elles arrivent en premier dans la table, donc leur code est plus petit.

        Ça ne me semble pas absurde que les majuscules arrivent avant les minuscules, l'inverse aurait été étrange.

        • [^] # Re: Numéro de code ASCII?

          Posté par  . Évalué à 2.

          EBCDIC définit les minuscules avant les majuscules et les chiffres sont placés en fin de table. Donc, tout le contraire de ASCII.

        • [^] # Re: Numéro de code ASCII?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Les minuscules, ou bas de casse, sont ainsi nommées en français car elles étaient rangées dans les cases en bas des casses des imprimeurs car elles sont plus souvent utilisées que les majuscules (haut de casse). Donc, personnellement, j'aurais trouvé plus logique qu'elles arrivent en premier justement du fait de leur usage.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Numéro de code ASCII?

        Posté par  . Évalué à 10.

        La raison est toute simple. On évite ainsi que les utilisateurs demandent pourquoi les majuscules ont un code plus grand que les minuscules.

      • [^] # Re: Numéro de code ASCII?

        Posté par  . Évalué à 6.

        La réponse se trouve probablement dans les nombreux encodages ayant précédé l'ASCII. Je pense en particulier aux encodages sur 6 bits qui ne possédaient pas de minuscules.

        Dans la page https://en.wikipedia.org/wiki/Six-bit_character_code je remarque en particulier DEC SIXBIT et ECMA-1 qui se retrouvent quasiment inchangés dans l'ASCII.

        • [^] # Re: Numéro de code ASCII?

          Posté par  . Évalué à 5.

          Je te conseille aussi l'excellent commentaire sur le sujet: https://linuxfr.org/users/serge_ss_paille/journaux/rigolons-avec-l-ascii#comment-1790973

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Numéro de code ASCII?

            Posté par  . Évalué à 1.

            Je sais. Mon intention initiale était de donner quelques liens en réponse à ce commentaire mais d'un autre coté c'est aussi toi qui a explicitement posé la question "c'est pourquoi les majuscules ont un code plus petits que les minuscules?" dans ce fil de discussion :-)

            • [^] # Re: Numéro de code ASCII?

              Posté par  . Évalué à 2.

              Ayant moi même fait partie de quelques comités de normalisation, je peux aussi affirmer par expérience qu'il ne faut pas toujours chercher l'explication la plus rationnelle. Ces comités sont essentiellement contrôlés par des grandes entreprises avec des agendas différents. Les décisions sont souvent politiques ou tout simplement pragmatiques (la 1ere proposition qui tient la route est acceptée).

              • [^] # Re: Numéro de code ASCII?

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Je crois en effet que la seule raison est une décision plus ou moins arbitraire à prendre à un moment donnée.

                En fait, c'est aussi valable pour tout système de mesure.

                « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # Question de type

    Posté par  . Évalué à 1.

    Quand un langage transtype par défaut il faut bien faire un choix.

    (qu'on me corrige si je me trompe) … Pour une chaîne vu que python3 fait de l'utf8 il utilise par défaut le "code point" convertit en numérique, pour une comparaison qui se voudrait numérique, ici ">".

    Ce qui revient à :

    ord("a") > ord("A")

    D'autres langages ne transtypent pas par défaut, et donc indiqueraient une erreur.

    • [^] # Re: Question de type

      Posté par  (site web personnel) . Évalué à 3.

      Ici python ne "transtype" pas, Il trie deux chaines de caractère ensemble en suivant un ordre lexicographique. C'est une relation d'ordre qui marche pas trop mal sur les chaines de caractères. On pourrait utiliser une autre relation d'ordre.

      Maintenant l'algorithme lexicographique se base sur l'ordre des caractères entre eux et ici on peut se poser la question de cet ordre, qui pourrait être différent.

      • [^] # Re: Question de type

        Posté par  . Évalué à 0.

        Si il n'y a pas transtypage, il y a au minimum un test de type effectué par l'opérateur.

        Dans https://docs.python.org/2/reference/expressions.html#value-comparisons Il est indiqué :

        • Strings (instances of str or unicode) compare lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters.

        • When comparing an 8-bit string and a Unicode string, the 8-bit string is converted to Unicode. If the conversion fails, the strings are considered unequal.

        Ce qui est une convention, la valeur renvoyée par ord() étant un retour sans doute de la position dans la table de caractères.

        Le fait que :

        > '1'.__gt__(1)
NotImplemented

        Donne a penser que les types String, Number, etc …sont bien pris en compte quand il y a comparaison entre deux objets.

      • [^] # Re: Question de type

        Posté par  (site web personnel) . Évalué à -4. Dernière modification le 21 novembre 2019 à 18:22.

        Ici python ne "transtype" pas, Il trie deux chaines de caractère ensemble en suivant un ordre lexicographique.

        Je peux me planter mais alors je demande démo, sinon : il y a transcryptage. l'ordre lexicographique n'est pas utilisé.

        print("ss" < "ß")
        True

        Alors que c'est égal (vite fait une source : ß, In alphabetical order, it is treated as the equivalent of ⟨ss⟩, donc pas inférieur lexigrographiquement.

        Et lexigrographiquement, jamais vu non plus dire que majuscule c'est inférieur ou supérieur de minuscule.

        Bref, Python (comme les autres) a l'air de faire un "bête" transtypage de lettre (une notion de l'alphabet) à valeur Unicode (un nombre, qui a explicitement une notion de comparaison). Quelqu'un pour démontrer avec un seul exemple que l'ordre Unicode (arbitraire, non lexicographique) n'est pas respecté dans la comparaison?

        Edit : tiens, on me montre une différence. Donc certaines choses ont un ordre lexicographique, peut-être juste pas le tri par défaut.

      • [^] # Re: Question de type

        Posté par  (site web personnel) . Évalué à 3.

        Les personnes qui désirent faire des comparaisons plus riches doivent se taper des algos un peu plus complexes (et long à exécuter – là on a une simple comparaison numérique des code-point, directement accessibles dans la mémoire où est stockée la chaîne).

        Cf Collation et algos unicode.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # Note pour Self ... ou autres selon.

    Posté par  . Évalué à 1. Dernière modification le 21 novembre 2019 à 11:33.

    Les symboles de comparaison sont pris comme des fonctions.

    Dans python : https://docs.python.org/2/library/operator.html

    Reste à savoir à l'interne comment ces fonctions transtypent ?

    Dans raku les opérateurs (infix seulement ?) attendent des types précis ex ">" : https://docs.raku.org/routine/>

    Ou si ils attendent un type "Mu", ils tentent de transtyper ex "gt" : https://docs.raku.org/routine/gt

    En fait ça va un peu plus loin que l'ascii tout çà …

  • # Pas toujours

    Posté par  . Évalué à 10.

    L'ordre des caractères est censé être définit par la locale. Cela peut être important quand on utilise certaines commandes telles que ls ou sort.

    for i in $(locale -a) ; do echo == $i ; printf "a\nA\nz\nZ\n" | LC_ALL=$i sort ; done 
    == C
    A
    Z
    a
    z
    == C.UTF-8
    A
    Z
    a
    z
    == en_US.utf8
    a
    A
    z
    Z
    == fr_FR.utf8
    a
    A
    z
    Z
    == POSIX
    A
    Z
    a
    z

    On voit ici que les locales en_US.utf8 et fr_FR.utf8 n'utilisent pas l'ordre ASCII ou Unicode. J'imagine que pour des raisons de performances Python, comme la plupart des langages, ignore la locale lors des comparaisons de chaînes de caractères (voir aussi locale.strcoll()).

    Remarque: Les utilisateurs des locales UTF-8 qui n'apprécient pas que 'ls' mélange les majuscules et les minuscules peuvent déclarer LC_COLLATE=C.UTF-8 pour revenir à un tri plus 'classique'.

    • [^] # Re: Pas toujours

      Posté par  (site web personnel) . Évalué à 1.

      On voit ici que les locales en_US.utf8 et fr_FR.utf8 n'utilisent pas l'ordre ASCII ou Unicode

      Très intéressant, je n'avais pas tilté que les locales fournissent un ordre lexicographique, alors que ça peut être un piège pour moi parfois.
      il y a un endroit qui explique les choix d'ordre lexicographique de chaque locale?

      • [^] # Re: Pas toujours

        Posté par  . Évalué à 4.

        C'est en effet un piège assez classique dans les scripts. Il n'est pas toujours évident de savoir quelles commandes respectent la locale. En général, il est recommandé de définir LC_ALL=C en début de script pour éviter les surprises.

        Pour obtenir une description des règles, le plus simple est probablement de jeter un coups d'oeil dans les fichiers de description des locales de la glibc.

        Chez moi (Debian), ils sont dans /usr/share/i18n/locales et, pour la syntaxe, voir la section décrivant LC_COLLATE dans man 5 locale

        Une autre source d'information pourrait être le CLDR http://cldr.unicode.org/ mais je ne sais pas si la glibc respecte cette specifications.

      • [^] # Re: Pas toujours

        Posté par  . Évalué à 3.

        Je n'ai pas trouvé de description simple des règles de tri lexicographiques mais voici une méthode simple pour se faire une idée:

        (1) Télécharger https://raw.githubusercontent.com/bits/UTF-8-Unicode-Test-Documents/master/UTF-8_sequence_separated/utf8_sequence_0-0x10ffff_assigned_printable.txt

        (2) Un caractère par ligne

        sed 's/ /\n/g' utf8_sequence_0-0x10ffff_assigned_printable.txt > all.txt

        (3) Trier avec la locale souhaitée 

        LC_ALL=C.UTF-8 sort all.txt > ordre-C.txt
LC_ALL=fr_FR.utf8 sort all.txt > ordre-fr_FR.txt

        Le tri en locale fr_FR.utf8 est BIEN PLUS LENT qu'en locale C ce qui n'est pas vraiment surprenant car les règles sont bien plus complexes.

      • [^] # Re: Pas toujours

        Posté par  . Évalué à 1.

        Très intéressant, je n'avais pas tilté que les locales fournissent un ordre lexicographique, alors que ça peut être un piège pour moi parfois.

        Oui, les étiquettes IETF ne représentent pas qu'une langue, mais aussi une « culture » (particularités régionales pour une même langue). L'ordre lexicographique peut être vu comme culturel (ce concept se retrouve par exemple en Java ou en .NET avec les entités de comparaison).

  • # Autre endroit

    Posté par  (site web personnel) . Évalué à 10.

    « L'informatique, le seul endroit où quand tu es minuscule, tu es plus grand. »

    Pas le seul. Dans la Bible on trouve aussi :

    « Ainsi les derniers seront les premiers et les premiers seront les derniers. » Matthieu 20.16

    Où premier et derniers est souvent compris comme grand et petit ou encore comme important et négligeable.
    De là à pousser un parallèle entre informatique et royaume de Dieu, ou à voir en Jésus-Christ un précurseur d'Ada Lovelace, il y a tout de même un pas. Remarquons cependant que c'est bien en vertu de leur prééminence de lettre capitales que les majuscules se sont ainsi souvent vues attribuées des numéros inférieures aux lettres minuscules.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Autre endroit

      Posté par  . Évalué à 3. Dernière modification le 21 novembre 2019 à 13:11. 

      Python 3.7.5
>>> 'ç' > 'c'
True

      La cédille diacritique visigothe de ce peuple païen prenant le pas sur le bon "c" Roman, me fait dire que Dieu s'est fait avoir.

      Mais que fait l'église catholique !

      • [^] # Re: Autre endroit

        Posté par  (site web personnel) . Évalué à 2.

        Ne se déconsidérerait-elle pas elle-même en contre-disant précisément celui qu'elle prétend avoir pour chef ?

        Il se trouve que l'une des interprétations les plus constante et unanime de ce verset consiste à y voir une dénonciation des élus (les ~croyants inconséquents) et l'annonce de la bonne nouvelle du salut aux païens.

        Sauf erreur de ma part, cet exemple va précisément dans le même sens que le précédent. Toutes réserves gardées sur la valeur à accorder à ces considérations anecdotiques. Du coup, je ne comprend guère votre propos. Souhaitiez-vous juste signifier que vous n'aviez pas lu le commentaire auquel vous répondez en plus de signaler un autre exemple du même acabit que celui du journal ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Autre endroit

          Posté par  . Évalué à 2.

          Le fait que Matthieu n'apparaisse que dans le nouveau testament (cf) me fait douter sur la valeur vraiment "unanime" de cette citation impliquant des "premiers" et des "derniers", et donc une inversion impossible de l'ordre cosmique.

          D'ailleurs, le "Prosélytisme" vis à vis des peuples païens que vous semblez choyer dans votre deuxième paragraphe, venant aussi de Matthieu, indique une foi par trop réformiste pour moi.

          Ayant déjà eut du mal avec l'arianismeen son temps, vous comprendrez (peut-être un peu tardivement) que mon commentaire veut dénoncer une cabale de l'utf8 portée contre la seule vraie foi.

          Mon commentaire, à l'encontre de cette ignominie, dont les racines remontent sans doute à l'ISO/CEI 10646 était tout à fait justifié.

  • # Con par raison

    Posté par  . Évalué à 10.

    Tout est normal, j'ai vérifié :

    Python 3.5.2
>>> "minuscule" > "majuscule"
True

    La minuscule est plus grande que la majuscule, tout va bien. Dans le même style :

    >>> "petit" > "grand"
True

    Tout ne serait donc qu'une question de perspective.

    • [^] # Re: Con par raison

      Posté par  . Évalué à 3.

      Normal si on tient compte que l'interpréteur est un TARDIS

      >>> "intérieur" > "extérieur"
True

    • [^] # Re: Con par raison

      Posté par  (site web personnel) . Évalué à 4.

      Dans la même veine

      >>> 'weak' > 'strong'
True

      Ahhh quel monde idéal :-)

    • [^] # Re: Con par raison

      Posté par  . Évalué à 10.

      Ah mais c’est pratique Python en fait, ça répond à toutes les questions qu’on se pose depuis longtemps :

      >>> "vim" > "emacs"
True

      (Python 3.7.5, et on est vendredi)

      • [^] # Re: Con par raison

        Posté par  (site web personnel) . Évalué à 9. Dernière modification le 22 novembre 2019 à 14:12. 

        >>> "Ruby" > "Python" > "Perl" > "PHP" > "Java"
True

        • [^] # Re: Con par raison

          Posté par  . Évalué à 1.

          tu as oublié Visual Basic ;-)
          (et tous sont bien sûr supérieurs à C++ et C)

  • # Et pourquoi pas ?

    Posté par  (site web personnel) . Évalué à 3.

    Petit, j'ai appris une liste triée de 26 caractères, mais je n'ai jamais appris d'ordre particulier entre majuscules et minuscules, ni d'ordre dans les versions accentuées d'un même caractère (doit-on faire eéè ? éeè ?, éèe ?).

    Partant de là, il faut bien choisir une convention, et cette version ne me surprend pas plus qu'une autre.

    • [^] # Re: Et pourquoi pas ?

      Posté par  (site web personnel) . Évalué à 3.

      dans les versions accentuées d'un même caractère

      Sans compter les autres 'variantes' type cédilles (ç), æ/œ, etc. Et le fait d'avoir des caractères d'un autre alphabet au milieu d'un texte en français (on les trie avant ? Après ? On plante ?)

      • [^] # Re: Et pourquoi pas ?

        Posté par  (site web personnel) . Évalué à 2.

        Oui, bien sûr.
        Ce que je veux dire, c'est qu'il n'y a aucun ordre naturel pour trier ces différents caractères. Ça dépendra très certainement du contexte.

        Par exemple, si je choisis l'ordre "e" puis "é" (parce que pourquoi pas), et que je veux trier "cote", "cotes", "coté", "cotés".
        Dans beaucoup de cas, je vais pourtant vouloir trier "cote", "coté", "cotes", "cotés", sans respecter l'ordre lexicographique pur.

    • [^] # Re: Et pourquoi pas ?

      Posté par  (Mastodon) . Évalué à 4.

      ni d'ordre dans les versions accentuées d'un même caractère (doit-on faire eéè ? éeè ?, éèe ?).

      L'odre est «e é è ê ë» (dixit Wikipedia). Là où ça devient drôle, c'est quand on a plusieurs mots qui ne diffèrent que par les accents, genre «cote», «coté», «côte», «côté». Dans ce cas, on doit partir de la fin du mot pour discriminer. Donc «côte» sera placé avant «coté» parce que «e» vient avant «é».

      • [^] # Re: Et pourquoi pas ?

        Posté par  . Évalué à 4.

        «côte» sera placé avant «coté» parce que «e» vient avant «é».

        Intuitivement j'aurai mis « coté » avant « côte », car « o » est avant « ô ».

        Je ne comprends pas pourquoi il faut partir de la fin du mot. Ça se passe comment avec les mots qui ont plusieurs diacritiques ?

        • [^] # Re: Et pourquoi pas ?

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 novembre 2019 à 20:46.

          Eh oui c'est bizarre, mais c'est ce que son lien indique dans le paragraphe "Ligatures, lettres accentuées et majuscules"

          • [^] # Re: Et pourquoi pas ?

            Posté par  . Évalué à 4. Dernière modification le 23 novembre 2019 à 13:43.

            c'est ce que son lien indique dans le paragraphe "Ligatures, lettres accentuées et majuscules"

            C'est bien l'objet de ma question : pourquoi cette règle qui semble étrange ?
            Je n'en saisi pas la justification logique (s'il y en a une).

            Je viens de vérifier dans un dictionnaire papier : élève puis élevé, comme l'indique Wikipedia.

            • [^] # Re: Et pourquoi pas ?

              Posté par  (Mastodon) . Évalué à 4.

              pourquoi cette règle qui semble étrange ?

              Depuis que je connais cette règle, je n'ai jamais su d'où elle venait. J'ai toujours entendu dire qu'il n'y avait qu'en français qu'on faisait comme ça et que toute bibliothèque de collation Unicode devait se farcir cette règle à la noix uniquement pour le français. Après, c'est le français, c'est pas non plus la langue la plus logique qui soit.

              • [^] # Re: Et pourquoi pas ?

                Posté par  . Évalué à 1. Dernière modification le 24 novembre 2019 à 09:07.

                Salut,

                J'ai toujours entendu dire qu'il n'y avait qu'en français qu'on faisait comme ça et que toute bibliothèque de collation Unicode devait se farcir cette règle à la noix uniquement pour le français.

                J'ai déjà dû le dire ici, donc je radote un peu, mais voilà comment on m'a introduit au russe : « Il n'y a qu'une seule règle, c'est l'exception. » (jour 1, cours 1). Et bah. On est pas sortis de l'auberge fut un peu ma réflexion, comme dira une autre plus tard :)

                Sinon, dans le genre super piège en anglais, il y a les noms de villes/régions. Exemple : Gloucester. Si vous le prononcez gloucesteur, ça va très vite se voir que vous êtes un peu étranger au patelin ;) Hélas, mes deux dicos ne contiennent que les noms communs, pas les noms propres, donc impossible de savoir où c'est rangé sur ce nom.

                L'inspection rapide des préfaces et mots finaux des deux dictionnaires anglais ne me donne pas plus de piste sur l'ordre utilisé. J'ai cependant noté un petit exemple marrant sans diacritique en anglais : bow. D'abord cité comme nom commun (arc), puis comme verbe (se courber), il revient enfin à nouveau comme nom commun (flanc d'un navire).

                Perfide Albion ;)

                Matricule 23415

              • [^] # Re: Et pourquoi pas ?

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                De toute façon, ça aurait été une règle à la noix, quelle que soit la langue concernée. C'est un domaine où il faut prendre une décision et s'y tenir. Dans un sens ou un autre. J'imagine qu'il doit y avoir d'autres règles propres à d'autres langues.

                Par contre le truc vraiment à la noix c'est de continuer à n'utiliser que l'ascii dans certains cas, nommage de fichiers ou champs de bases de données par exemple, pour éviter que cela cause des problèmes.

                « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: Et pourquoi pas ?

          Posté par  (site web personnel) . Évalué à 4.

          Je ne pense pas qu'il faille partir de la fin du mot pour trier, plutôt qu'il faut utiliser un tri plus subtil qu'un simple tri caractère par caractère. Par exemple :
          - on fait des classes d'équivalence pour chaque mot (la classe d'équivalence de ce mot étant ce même mot dépourvu d'accents et autres bizarreries),
          - on trie les classes d'équivalence,
          - on trie les différents mots au sein d'une classe d'équivalence.

        • [^] # Re: Et pourquoi pas ?

          Posté par  . Évalué à 0.

          Salut,

          Intuitivement j'aurai mis « coté » avant « côte », car « o » est avant « ô ».

          Intuitivement aussi, j'aurais rangé comme dans le sens indiqué car le diacritique ^ sur le o ne change pas la prononciation du o (chez moi :p), alors que l'apostrophe aigu sur le e le rend plus grave (je n'ai jamais compris pourquoi un accent aigu rend une lettre plus grave et un accent grave une lettre plus aiguë, mais bon, passons).

          Matricule 23415

  • # [PROMO-INSIDE] On peut au moins sourire

    Posté par  . Évalué à 1.

    Comme l'ont fait remarquer beaucoup de posteurs c'est juste une question de classement arbitraire.

    Mais comment le changer ?

    C'est pas parfait mais ça le fait :

    https://docs.raku.org/routine/collate

    > <Ç c à C A Ù z ù>.collate
(A à c C Ç ù Ù z)

    Il y a pour à cet effet une variable d'env "$*COLLATION" qui permet de changer le comportement de classement des graphèmes de la méthode.

    J'ai pas cherché dans d'autres langages, mais ça doit exister.

    Bon, tout ça pour ça, entre temps on a bien rigolé, non ?

  • # Histoire de l’alphabet latin

    Posté par  . Évalué à 7.

    À l’origine, l’alphabet latin ne comportait que des lettres capitales (souvenez-vous des péplums), qui sont en fait l’apparence “normale” des caractères.
    Les minuscules sont apparues lors du Moyen Âge quand Charlemagne voulut normaliser l’écriture de son vaste empire. Les diacritiques sont apparus plus tardivement encore.

    Il n’est donc pas absurde d’avoir placé les majuscules avant les minuscules. Mais je ne sais pas si l’histoire est la cause de ce choix d’ordonnancement.

  • # ASA X3.4-1963

    Posté par  (site web personnel) . Évalué à 3.

    La page Wikipedia anglaise sur l'ASCII explique que la norme ASA X3.4-1963 avait laissé 28 positions libres et qu'il y avait un débat sur leur utilisation pour les minuscules ou pour l'ajout d'autres codes de contrôle.

    Les minuscules ont été dans le bas de casse, puis dans le haut de l'ASCII, et finalement plutôt dans le bas de l'Unicode…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.