Description de strcmp dans la norme

En news:4898d3ec$0$17334$426a74cc@news.free.fr, candide va escriure:

Antoine Leca a écrit :

En news:48966b0a$0$18200$426a74cc@news.free.fr, candide va escriure:

Si je dis z est déterminé par y et z, cela veut juste dire qu'il
existe une fonction f telle que z=f(x,y). Maintenant que
f(x,y)=sqrt(x*x+y*y) ou f(x,y)=|x|+|y| ou que sais-je encore,
ce n'est pas pareil.

Du point de vue de la détermination (ou de l'indétermination), si.

Je ne comprends pas ce que tu veux dire.

La détermination (en anglais) désigne l'existence d'une relation de
causalité, et aussi le fait que cette relation soit primordiale (de premier
ordre).
La _nature_ (extraction de racine carrée ou addition) de cette relation est
immatérielle.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Le comment est le problème de l'implémenteur, et en l'occurence il a
un peu de marge de manouvre.

Bien sûr que je ne parle pas de ce sens-là, le lecteur de la norme est
en principe un utilisateur, par un implémenteur.

Mmmm, je ne suis pas d'accord.
Il est possible que la formulation de la norme soit orientée dans le sens du
point de vue du programmeur, mais même cela ne me paraît pas complètement
évident, à juger par les formulations comme les descriptions des opérations
(qui relate purement et simplement les contraintes d'implémentation), ou
encore plus celles des fonctions de la bibliothèque standard.

La norme dit que le signe de la valeur de retour est _déterminé_
par le signe de blablabla.

Donc, qu'il existe une relation importante de causalité. Ce que dit la norme
ici, c'est qu'une implémentation ne peut pas faire le contraire, donc ne
peut donner un signe différent pour deux appels distincts avec les mêmes
arguments, où « même » est restreint à la suite des N premiers caractères,
les N-1 premiers étant identiques et le Nième étant différent (nous sommes
dans le cas où le résultat est non-nul).
Pour avoir une détermination _complète_ des fonctions, il faut donc y
ajouter d'une part la description exhaustive des cas où le résultat est nul,
et d'autre part une règle qui lie le signe avec l'ordre des entiers (ordre
croissant ou décroissant).

Je réponds : "déterminé comment ?"

parce que la spécification est incomplète.

Certes. Le mot "to determine" n'a jamais signifier la complétude, pas plus
en anglais qu'en français (où on utilise l'expression « complètement
déterminé », l'adverbe indiquant bien ici le supplément de signification).

En effet, la norme ne me dit pas _en quoi_ (ie "comment") le signe
de l'un _détermine_ le signe de l'autre :

Comme je l'explique ci-dessus (et c'était tout mon argument dans
l'elliptique « du point de vue [...], si »), elle l'explicite ailleurs.

est-ce que c'est le même signe, le signe opposé, le signe
opposé sauf si le programmeur est né un 29 février, etc.

Si, et c'est là pourquoi le mot "to determine" a été choisi : en effet il
explicite que la relation de causalité désignée est « importante » (pour
reprendre ton mot), contrairement à des presque synonymes comme "to
describe". Donc il n'est pas possible d'avoir des « sauf si », ni de
considérer des options « tordues » comme le « signe opposé ».

Mais absolument pas, ils ont surtout donné une définition complètement
bancale. A croire qu'ils n'ont pas voulu modifier une version
historique incorrecte

En fait, le propos de 7.21.4p1 est surtout de factoriser un propos qui sinon
apparaîtrait trois fois.

1°) l'emploi de "is determined",

Le fait est que cela n'a pas gêné outre mesure les exégètes (anglo-saxons)
du langage.

2°) la définition incomplète de la relation d'ordre sur les chaînes
(nulle part il n'est dit comment on les compare alors que la _valeur_
d'une chaîne, elle, est définie)

Nous sommes en désaccord ici : pour moi on a une spécification complète de
la relation d'ordre, en gros il n'est pas possible d'avoir d'ambiguité (et
je pense que la fameuse remarque dans 7.1.1 sur la valeur a été ajoutée dans
C99 justement dans l'optique d'améliorer cette spécification).

En fait, si tu trouves une ambiguité dans la formulation, il te faut remplir
un rapport d'anomalie contre C99.

3°) le fait que des notions soient présentées sans être reliées entre
elles (ici, d'une part ce que j'ai appelé le préambule du §7.21.4.2 de
C99 et d'autre part la partie "Returns" du même paragraphe).

Donc, que la forme n'est pas optimale : là-dessus nous pouvons être d'accord
;-)

Qu'est-ce qui n'est pas défini dans :
- si les premiers éléments de chacune des deux suites sont
différents, on compare leurs valeurs ;
- sinon, on compare le reste des deux suites.

(et il s'agit ici d'une reformulation inférieure au texte de la
norme).

Oui, j'ai bien vu, c'est dans le préambule. Où est-il affirmé que cela
définit l'ordre sur les chaînes dont il est questions plusieurs lignes
plus loin ?

En utilsant le mot "to determine".

Le préambule, pour sa part, il met en relation ("établit une relation
univoque" pour réutiliser ton terme) le signe d'une valeur de retour
et le signe d'une grandeur mathématique. Rien n'indique que la
positivité de cette grandeur équivaut à définir la relation d'ordre
entre les chaines.

Dans le préambule, effectivement non. En fait, je croyais initialement que
c'était exactement ce point que tu critiquais (d'où certaines de mes
réponses).
Depuis, il me semble que la confusion vient du fait que tu attribues
(peut-être inconsciement) le sens de « détermination complète » à "to
determine" : d'où par exemple l'utilise de « c'est un mot fort ».

Enfin! la norme dit clairement et explicitement dans un endroit
approprié ce que c'est que la _valeur_ d'une chaîne et elle n'est pas
capable de, même pas de "dire" mais de "suggérer", autrement qu'au
détour d'une phrase ce que voudrait dire qu'une "chaîne est plus
grande qu'une autre". C'est totalement incohérent.

C'est juste la marque du fait que la norme évolue, et que l'on est passé
d'un texte de 20 pages (l'annexe A du K&R) à un texte de 200 (C90), qui il
est vrai inclut la bibliothèque standard pour une moitié, puis à un texte de
600 pages (C99) : cette inflation de 200 % ne s'explique pas par les
nouveautés fonctionnelles (!) mais surtout par les conséquences d'un travail
de sape de la part de certains exégètes pour « améliorer » le texte, ici en
définissant la notion de valeur d'une chaîne. Auparavant, personne ou
presque ne pensait qu'il y ait matière à interpréter (au sens d'avoir des
divergences); mais d'un autre côté on ne peut pas dire au cas par cas que
cette augmentation de la précision soit mal venue, donc on a ajouté de bon
cour ces ajouts : personnellement je trouve que le résultat par sa grosseur
est un peu indigeste, même si :
1) ayant lu auparavant C90, je ne souffre absolument pas des conséquences
de cet embonpoint ;
2) quand je compare à C++ qui à la même époque est partie consciemment dans
le sens opposé à C99, avoir des définitions les plus succinctes possible
pour pouvoir produire un texte de poids acceptable, quite à devoir éclaircir
les points litigieux par la suite, je trouve que la norme C99 est largement
plus digeste (OK OK, c'est encore une fois de l'anti-C++ primaire, je sors
=>[] ).

Néanmoins, je trouve la formulation "including the first null
character" assez peu claire.

Elle est typique de la norme : volonté d'être succinct.

En français, ça donnerait [...]

Là, tu donnes une preuve que si l'on veut traduire la norme C en français,
on arriverait à un texte passablement différent, beaucoup plus écrit (plus
littéraire, moins « style télégraphique ») que ne le serait une traduction
mot-à-mot.
C'est une constante à la quelle arrive régulièrement ceux qui travaillent
sur les normes bilingues, et cela produit un avantage de qualité produite
(les normes développées conjointement en deux langues sont de meilleure
qualité, moins imprécises) qui est souvent mis en avant par ceux qui veulent
à tout prix que le français reste au même titre que l'angalis une langue
officielle de l'ISO.


<HS>

Que dire de "je suis fils premier"

C'est tellement pabô qu'en français on a un mot à cet effet, aîné !
</HS>

Sinon, en fait, je ne trouve pas leur définition parfaitement claire.
Ce qui me gêne, c'est cette histoire de "suite de caractères". On
n'arrive pas à savoir à quel niveau la définition se place. Il est
bien clair qu'une telle définition a un sens ailleurs que dans le
contexte du langage C. Par exemple, cette définition ne me dit pas si
une chaîne est un objet.

Et de fait, elle ne l'est pas (dans le cas de ton "titi", l'objet c'est le
tableau de 6 caractères auquel le littéral est affecté).

Et une chaîne est-elle de type tableau ?

Non. Les types sont une notion de la partie 6, de compilation. À l'exécution
ils sont essentiellement ignorés.
Au contraire, les chaînes sont essentiellement une notion d'exécution.

Par ailleurs, tu vois bien les différences entre un littéral en
virgule flottante et un objet de type flottant, non ?

Je sais pas ce que c'est qu'un "littéral en virgule flottante", pour
moi, comme son non l'indique, un litteral contient des lettres,

Un point pour toi :-)

mais tu veux dire un truc du genre "3.14" ? Bien, oui, je fais bien la
différence mais je vois pas trop le rapport avec notre problème qu'une
chaîne littérale n'est pas une chaîne.

littéral chaîne <=> littéral en virgule flottante
"titi" <=> 3.14

chaîne <=> objet de type flottant
{partie de mémoire {objet déclaré avec un type
commençant par un float, double, complex float etc.
't' et s'arrêtant qui contient une représentation
au premier byte nul} proche de 22/7}


Antoine

En news:489a101f$0$906$ba4acef3@news.orange.fr, Wykaaa va escriure:

Habituellement, ce sont les dictionnaires qui se plient aux usages de
la langue

Oui.

et qui introduisent de nouvelles definitions pour des mots
existants ou de nouveaux mots...

Non. Le rôle des dictionnaires n'est pas et n'a jamais été d'inventer des
mots (néologismes) : ceci est le propos des travaux publiés (au sens très
large, incluant par exemple les chansons) par les utilisateurs de la langue
; à partir du moment où un néologisme devient accepté, il est repris par les
dictionnaires et donc consacré.

Charlie Gordon a écrit :

Dans les faits, strcmp est majoritairement utilisée pour déterminer
si 2 chaines ont le même contenu, avec l'un des deux idiomes
``!strcmp(a,b)'' ou ``strcmp(a,b) == 0''.

Alors ça, ce n'est pas vrai du tout.

Euh si : l'utilisation la plus courante --celle que je vois le plus
souvent-- de strcmp(), c'est un test d'égalité contre 0; et ce n'est pas
avec un exemple qui va à l'encontre de beaucoup d'exemples que tu vas
prouver ton point de vue : il faudrait plutôt montrer un exemple
d'implémentation où la fonction strcmp() aurait été spécialement programmée
pour fournir plus rapidement le signe du résultat /plutôt/ que l'indication
de sa nullité ; et je sais bien qu'avec les processeurs actuels les deux ont
sensiblement le même coût ; mais j'ai la sensation qu'il devrait être plus
facile de rencontrer une implémentation en ligne qui se contenterait du test
de la non égalité du Nième terme, sans s'inquiéter de l'ordre des valeurs,
dans le cas où le résultat de strcmp() est évalué ==0 ou !=0.

Par ailleurs, il est clair qu'une optimisation courante (et payante) de
strcmp() consiste à comparer la valeur des pointeurs à l'entrée, et à
renvoyer de suite 0 dans le cas de coïncidence :

if( p == q )
return 0; /* les deux chaînes sont égales, ne perdons pas de temps
*/


Antoine

Antoine Leca a écrit :

En news:489a101f$0$906$ba4acef3@news.orange.fr, Wykaaa va escriure:

Habituellement, ce sont les dictionnaires qui se plient aux usages de
la langue

Oui.

et qui introduisent de nouvelles definitions pour des mots
existants ou de nouveaux mots...

Non. Le rôle des dictionnaires n'est pas et n'a jamais été d'inventer des
mots (néologismes) : ceci est le propos des travaux publiés (au sens très
large, incluant par exemple les chansons) par les utilisateurs de la langue
; à partir du moment où un néologisme devient accepté, il est repris par les
dictionnaires et donc consacré.

C'est ce que je voulais dire lorsque je mentionnais l'introduction de
nouveaux mots.

Charlie Gordon a écrit :

Dans les faits, strcmp est majoritairement utilisée pour déterminer
si 2 chaines ont le même contenu, avec l'un des deux idiomes
``!strcmp(a,b)'' ou ``strcmp(a,b) == 0''.

Alors ça, ce n'est pas vrai du tout.

Euh si : l'utilisation la plus courante --celle que je vois le plus
souvent-- de strcmp(), c'est un test d'égalité contre 0; et ce n'est pas
avec un exemple qui va à l'encontre de beaucoup d'exemples que tu vas
prouver ton point de vue : il faudrait plutôt montrer un exemple
d'implémentation où la fonction strcmp() aurait été spécialement programmée
pour fournir plus rapidement le signe du résultat /plutôt/ que l'indication
de sa nullité ; et je sais bien qu'avec les processeurs actuels les deux ont
sensiblement le même coût ; mais j'ai la sensation qu'il devrait être plus
facile de rencontrer une implémentation en ligne qui se contenterait du test
de la non égalité du Nième terme, sans s'inquiéter de l'ordre des valeurs,
dans le cas où le résultat de strcmp() est évalué ==0 ou !=0.

Par ailleurs, il est clair qu'une optimisation courante (et payante) de
strcmp() consiste à comparer la valeur des pointeurs à l'entrée, et à
renvoyer de suite 0 dans le cas de coïncidence :

if( p == q )
return 0; /* les deux chaînes sont égales, ne perdons pas de temps
*/


Antoine

Tiens, mon exemple d'utilisation de strcmp n'est pas commenté. Curieux...

Antoine Leca a écrit :

En news:4899f553$0$952$ba4acef3@news.orange.fr, Wykaaa va escriure:

Antoine Leca a écrit :

En news:48956e6b$0$945$ba4acef3@news.orange.fr, Wykaaa va escriure:

Par rapport à l'ordre lexicographique (codage des caractères).

Mmmm, ce n'est pas la même chose...

LEXICOGRAPHIQUE adj. XIXe siècle. [...]

Sauf à faire volontairement le naïf ou être réellement ignorant, tout
informaticien sait ce qu'est l'ordre lexicographique

Je n'avais pas l'intention d'être particulièrement naïf sur ce coup ; donc
j'en conclus que tu m'exclus de la catégorie des informaticiens.
Ce qui est probablement adéquat, puisque contrairement à vous le plus clair
de mon travail n'est pas de concevoir des programmes, mais plutôt de faire
marcher ceux qui existent (certains appellent cela de l'exploitation) ; et
effectivement je ne fréquente pas les spécialistes des langages (dont j'ai
découvert l'existence en travaillant sur la norme C99).


Pour moi, l'ordre de tri tel qu'utilisé en informatique est une chose, et
c'est effectivement normalement l'ordre du codage, la notion de jeu de
caractères etc. Tout cela désigne une seule et même chose pour moi, et
depuis des années je sais que cela implique que les majuscules vont d'un
côté, et les minuscules de l'autre.

Depuis un peu moins d'années (mais plusieurs quand même ;-) ), je sais aussi
que l'on peut faire des tris plus perfectionnés, avec des traitements
incorporés, par exemple pour faire que la distinction de la casse soit
abolie, voire (c'est plus récent) amenuïe --il s'agit alors de tris à
plusieurs passes.
Évidemment, la mise en ouvre de ces nouveaux ordres a un coût, ce qui fait
que pour moi, je réserve le nom de tri informatique à celui qui précède (le
plus rapide et le plus simple à programmer), et j'ai entendu divers noms
pour qualifier ces tris plus élaborés.

Depuis quelques années, j'ai appris que « l'ordre du dictionnaire », qui
n'était que l'un de ces qualificatifs sus-mentionnés, possédait d'une part
un nom, « lexicographique » (dont la liaison avec l'éthymologie me paraît
limpide), et aussi des définitions plus ou moins normalisées ; en ce qui
concerne le français on a ainsi des règles plus ou moins abscons sur l'ordre
des accents (cf. l'algorithme officiel de Unicode) ; en espagnol, il y a des
discussions sans fin sur le fait que CH et LL soient (vision européenne), ou
pas (vision américaine), des lettres séparées de l'alphabet. Etc.

J'en étais donc arrivé à considérer que d'un côté l'ordre lexicographique
désignait des règles de tri particulières et souvent complexes, associées à
des notions à géométrie variable comme celle de locale, et impliquait des
temps de traitement important ; l'archétype de ce phénomène est pour moi la
fonction strcoll().
Et que d'un ordre côté on avait toujours l'ordre lié au codage des
caractères, très souvent utilisé par les informaticiens même s'il n'est pas
toujours adéquat pour la présentation, et symbolisé par la fonction strcmp()
dont il est question dans cette discussion.

Il me semblait donc que ta remarque induisait une confusion qu'il eût été
bon de dissiper.


Cependant, à lire ta réaction et celle de plusieurs autres, il semblerait
que je me trompai, et que pour les informaticiens (qui à par moi doivent
constituer l'essentiel du public de ce forum) la notion de «
lexicographique » a un sens particulier, différent de celui généralement /
antérieurement accepté (et repris par le dictionnaire de l'Académie).

Absolument, oui.

Je t'encourage à lire la page 4 du document suivant :
http://www.dicosmo.org/CourseNotes/IF242/Preliminaires.pdf (ce sont des
notions mathématiques préliminaires à un cours sur "logique et circuits".
L'ordre lexicographique (au sens des informaticiens et des
mathématiciens, d'ailleurs) y est parfaitement défini. Il y a d'ailleurs
un avertissement qui indique que ce n'est pas exactement 'ordre du
dictionnaire.

Tu pourras consulter utilement aussi :
http://www.ltam.lu/Tutoriel_Ansi_C/prg-c78.htm

et ne confie pas sont interprétation à un dictionnaire littéraire

Le dictionnaire de l'Académis N'a PAS vocation à être un dictionnaire
littéraire ; si l'est, c'est que les Sages se sont fourvoyés. Pour moi, il a
l'avantage d'être doté d'un certain prestige, d'être indépendant des
querelles mercantiles liées aux éditeurs (L. contre R., etc.), et surtout
d'être lié à un signet sur mon navigateur. Je ne pense pas que les autres
dictionnaires « généraux » (c'est-à-dire ceux qui ne sont pas des
dictionnaires techniques d'informatique) aient des définitions sensiblement
différentes pour « lexicographique », mais il est vrai que je n'ai pas été
vérifié.


Antoine

Mickaël Wolff a écrit :

Wykaaa a écrit :

Sauf à faire volontairement le naïf ou être réellement ignorant, tout
informaticien sait ce qu'est l'ordre lexicographique et ne confie pas
sont interprétation à un dictionnaire littéraire :-((

Ben non, moi je ne sais pas. C'est certainement parce que je n'ai
jamais eu de cours de théorie du langage ?

Non, la notion d'ordre lexicographique est d'abord une notion
mathématique. Les mathématiciens parlent d'ordre lexicographique sur
R x R, par exemple.
Consulter : http://www.dicosmo.org/CourseNotes/IF242/Preliminaires.pdf
(page 4)
et http://www.ltam.lu/Tutoriel_Ansi_C/prg-c78.htm
Si j'en crois les

explications de Charlie, j'utilises l'anglicisme collation (miam) ou
interclassement en lieu et place de « ordre lexicographique ».

Ces termes sont inadéquats

Afin d'enfoncer le clou, en langage Cobol, il y a une directive qui
permet d'indiquer l'encodage des caractères pour le tri interne Cobol.
Cet ordre est :
collating sequence is
Derrière "is", on peut indiquer ASCII, EBCDIC, etc...

Tu vois, ça ne date pas d'hier l'ordre lexicographique et c'est, encore
une fois, le terme consacré et le seul utilisable (interclassement ne
veut strictement rien dire car il y a une infinité de manières
d'interclasser alors qu'il n'existe qu'une seule définition de l'ordre
lexicographique).
Quant à "collation", j'aime mieux ne rien dire ....

Wykaaa <wykaaa@yahoo.fr> écrivait :

Ces termes sont inadéquats

Afin d'enfoncer le clou, en langage Cobol, il y a une directive qui
permet d'indiquer l'encodage des caractères pour le tri interne Cobol.
Cet ordre est :
collating sequence is
Derrière "is", on peut indiquer ASCII, EBCDIC, etc...

ça c'est l'ordre sur les *caractères* On en déduit un autre ordre sur
les chaînes appelé "ordre lexicographique", qui est basé sur cet ordre
sur les caractères.

La notion d'ordre lexicographique est une notion *mathématiques*
permettant de définir un ordre sur les suites à partir d'un ordre sur
les éléments. C'est pus une fonction de transformation d'un ordre qu'un
ordre stricto sensu

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

Antoine Leca a écrit :

Nous sommes en désaccord ici : pour moi on a une spécification complète de
la relation d'ordre, en gros il n'est pas possible d'avoir d'ambiguité (et
je pense que la fameuse remarque dans 7.1.1 sur la valeur a été ajoutée dans
C99 justement dans l'optique d'améliorer cette spécification).

Je persiste à penser que le texte n'est pas clair. Mais il décrit une
situation tellement banale et classique que le défaut de rédaction ne
trompe pas sur l'intention.


Je relisais encore ce préambule et je me disais que le style de
rédaction de la Norme est vraiment daté, on dirait un traité de
mathématiques rédigé en latin du Moyen-Âge pour lequel on ne disposerait
d'aucun formalisme, c'est tout juste si on n'a pas la contrainte de
l'écrire en vers. Je me demande s'il ne serait pas envisageable
d'utiliser un style qui utilise davantage un formalisme de type
mathématique, ce qui donnerait lieu à des phrases moins lourdes (parfois
en tous cas).

Ainsi, pour essayer de décrire dans ce préambule la relation d'ordre sur
les objets, aucun nom d'objet n'est utilisé (à la différence par exemple
des "descriptions" ou des "returns" où les noms s1 ou s2 sont utilisés)
ce qui oblige à formuler de façon un peu rétro du genre

"... in the objects being compared".

Sans compter les imprécisions du genre : quand il est question de
"difference", c'est quoi MOINS quoi, autrement dit dans quel ordre ?
(bien sûr tout le monde pense "le caractère considéré dans la première
chaîne ou le premier objet" MOINS "le caractère considéré dans la
deuxième chaîne ou le deuxième objet"), toujours est-il que ces
formulations littéraires contiennent plein de non-dits.

Je me demande en outre si ce genre de contrainte rédactionnelle n'a pas
une conséquence sur le choix des formulations.

Ainsi, je trouve quand même curieux qu'on ramène une comparaison
d'entiers à un calcul de différence d'entiers (*). Pour savoir si -44
est plus grand que 119, je ne vais quand même pas faire une
soustraction. Ça a peut-être ses avantages mais je suis un peu perplexe
(comment fait un processeur par exemple pour comparer deux entiers ? il
calcule la différence ? je dirais que non, il fait comme un gamin au CE2).
Maintenant, si on reprend la rédaction du préambule en exprimant que le
signe dépend des valeurs comparées du plus petit caractère où cela
diffère, on est bien en peine de faire une rédaction propre car on ne
dispose pas du nom des caractères ou même des paramètres des fonctions
décrites, d'où une formulation quasiment impossible ou très
contorsionnée. Cet histoire de recours au signe de la différence
entraîne aussi une autre difficulté rédactionnelle : l'obligation de
traiter à part le cas d'un retour valant 0 ("the signe of a nonzero
value returned by ...") dont le signe est plus ou moins problématique.

Au passage, le seul cas où selon moi la Norme spécifie la fonction
strcmp correctement est le cas où le retour est nul :

The strcmp function returns an integer (...) equal to (...) zero,
according as the string pointed to by s1 is (...) equal to (...) the
string pointed to by s2 .


[quoiqu'on peut discuter du sens à donner à l'égalité de deux chaines].

En fait, si tu trouves une ambiguité dans la formulation, il te faut remplir
un rapport d'anomalie contre C99.

Ce n'est pas moi programmeur du dimanche et du mois d'août et à
l'anglais approximatif qui vais aller donner des leçons de rédaction aux
membres du comité. Si personne n'a vu ça depuis tant d'années que ça
figure ainsi, c'est qu'il n'y a aucun problème et que c'est moi qui sans
doute fais preuve de rigidité rédactionnelle (voire pire).

candide a écrit :

Ainsi, je trouve quand même curieux qu'on ramène une comparaison
d'entiers à un calcul de différence d'entiers (*). Pour savoir si -44

Omission de ma part, l'astérisque faisait référence à ce dont je parle
plus loin sur le processeur :

(comment fait un processeur par exemple pour comparer deux entiers ?

candide a écrit :

Ça a peut-être ses avantages mais je suis un peu perplexe
(comment fait un processeur par exemple pour comparer deux entiers ? il
calcule la différence ? je dirais que non, il fait comme un gamin au CE2).

Un gamin de CE2 est intelligent. Un ordinateur est stupide. Sans
compter que le gamin ne compare pas des nombres, mais des chaînes de
caractère représentant des nombres :-D

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Wykaaa a écrit :

Non, la notion d'ordre lexicographique est d'abord une notion
mathématique. Les mathématiciens parlent d'ordre lexicographique sur
R x R, par exemple.
Consulter : http://www.dicosmo.org/CourseNotes/IF242/Preliminaires.pdf
(page 4)
et http://www.ltam.lu/Tutoriel_Ansi_C/prg-c78.htm

Je n'ai jamais dépassé les cours d'algèbre linéaire :-D Merci pour
les liens.

Ces termes sont inadéquats

Pourquoi ? Quelle est la différence ? En fait j'utilises ces termes
dans MySQL, quand il est question de déterminer quel jeu de caractères
sera utilisé pour trier les chaînes de caractère.

N'est-ce pas à ce moment là un ordre lexicographique ?

Tu vois, ça ne date pas d'hier l'ordre lexicographique et c'est, encore
une fois, le terme consacré et le seul utilisable (interclassement ne
veut strictement rien dire car il y a une infinité de manières
d'interclasser alors qu'il n'existe qu'une seule définition de l'ordre
lexicographique).

Ben justement, de ce que j'en comprends, il y a plus d'un ordre
lexicographique, suivant la valeur que tu attribut à un caractère.

Quant à "collation", j'aime mieux ne rien dire ....

:-D

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org