Pour moi, elle ne devrait rien être, mais elle est ce que l'implémenteur a décidé qu'elle serait.
Le modèle mémoire que l'on manipule, quand on joue au shifting avec des entiers machine, de façon standard, dans tous les cours d'info de la planète, c'est: "liste finie indexée par des entiers naturels (de 0 à taille_entier_machine-1)".
L'opérateur shift_right est, sur ce type de structure, défini de façon parfaitement standard également, que ce soit mathématiquement, comme informatiquement. Aucun cours d'info ne stipule une quelconque modularité sur la variable de décalage. Je n'ai jamais rencontré non plus une structure de ce type dans mes longues années de pratique mathématique (elle modéliserait quoi d'ailleurs cette structure ?).
D'où ma question "quel intérêt, celui qui implémente, dans un langage de haut niveau, un tel opérateur, a t-il de lui donner ce comportement qui ne respecte ni le modèle de données ni n'apporte un quelconque service arithmétique ?" Pire encore, "pourquoi rompre un standard et générer, au mieux des comportements indéfinis, au pire des bugs ou des incompréhensions comme les ont vécues mes étudiants et comme nous les échangeons tous les deux ?".
Au sujet de ces deux questions, voilà ce que raconte Wikipedia:
"For example, shift-left-word in PowerPC chooses the more-intuitive behavior where shifting by the bit width or above gives zero,[1] whereas SHL in x86 chooses to mask the shift amount to the lower bits to reduce the maximum execution time of the instructions, and as such a shift by the bit width doesn't change the value."
On aurait donc enfin l'explication ! X86 a choisi ce comportement indépendamment de toute considération arithmétique uniquement pour des raisons techniques de performance. C'est à dire pour des considérations de bas niveau. Il n'y a là ni vision torique, ni cylindrique justifiée par des considérations d'arithmétique modulaire, non, c'est juste un pauvre masque sur les 6 derniers bits de la variable de décalage pour augmenter, au sein du CPU, la performance de l'opérateur shr au mépris de toute cohérence arithmétique.
Cette cohérence est déléguée aux langages au-dessus. Mais voilà, certains ne font rien pour corriger cette absence de cohérence arithmétique (parfois ne la documentent même pas). Voilà plus simplement ce qui est arrivé à mes étudiants.
PS
Concernant la doc Ada, je la trouve parfaitement claire, à condition que l'utilisateur sache ce qu'est un shit en mathématique sur des suites finies indexées par des entiers. Tout est là.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par snowball (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Le modèle mémoire que l'on manipule, quand on joue au shifting avec des entiers machine, de façon standard, dans tous les cours d'info de la planète, c'est: "liste finie indexée par des entiers naturels (de 0 à taille_entier_machine-1)".
L'opérateur shift_right est, sur ce type de structure, défini de façon parfaitement standard également, que ce soit mathématiquement, comme informatiquement. Aucun cours d'info ne stipule une quelconque modularité sur la variable de décalage. Je n'ai jamais rencontré non plus une structure de ce type dans mes longues années de pratique mathématique (elle modéliserait quoi d'ailleurs cette structure ?).
D'où ma question "quel intérêt, celui qui implémente, dans un langage de haut niveau, un tel opérateur, a t-il de lui donner ce comportement qui ne respecte ni le modèle de données ni n'apporte un quelconque service arithmétique ?" Pire encore, "pourquoi rompre un standard et générer, au mieux des comportements indéfinis, au pire des bugs ou des incompréhensions comme les ont vécues mes étudiants et comme nous les échangeons tous les deux ?".
Au sujet de ces deux questions, voilà ce que raconte Wikipedia:
On aurait donc enfin l'explication ! X86 a choisi ce comportement indépendamment de toute considération arithmétique uniquement pour des raisons techniques de performance. C'est à dire pour des considérations de bas niveau. Il n'y a là ni vision torique, ni cylindrique justifiée par des considérations d'arithmétique modulaire, non, c'est juste un pauvre masque sur les 6 derniers bits de la variable de décalage pour augmenter, au sein du CPU, la performance de l'opérateur shr au mépris de toute cohérence arithmétique.
Cette cohérence est déléguée aux langages au-dessus. Mais voilà, certains ne font rien pour corriger cette absence de cohérence arithmétique (parfois ne la documentent même pas). Voilà plus simplement ce qui est arrivé à mes étudiants.
PS
Concernant la doc Ada, je la trouve parfaitement claire, à condition que l'utilisateur sache ce qu'est un shit en mathématique sur des suites finies indexées par des entiers. Tout est là.