En effet, j'ai mis un bout de temps avant d'abandonner l'idée de comprendre la première phrase et continuer de lire l'article pour voir où l'auteur voulait aller :
Dit autrement, soit x = max(a, b) si a == b, quelle est la valeur de x, a ou b ?
Par construction, si a == b alors on ne peut pas les différencier ... du coup ... on retourne a ou b c'est pareil.
J'ai fini par comprendre que l'égalité a == b ne signifiait pas l'égalité (ni au sens faible de l'égalité physique de pointeurs, ni au sens fort de l'égalité structurelle). Le problème venait donc bien du fait que la relation d'ordre n'en était pas une !
Notons que si on définit une nouvelle relation d'égalité ~ sur les structures, et que l'ordre <= est une relation d'ordre relativement à cette relation d'égalité, et bien le comportement de max et min redevient totalement déterminé : si on a x ~ y alors c'est que dans notre programme, on a voulu confondre les deux valeurs, et donc il n'y a pas de raison de choisir un représentant plutôt qu'un autre.
Ma conclusion c'est que raisonner sur la sémantique d'une fonction définie sur un ordre (total) en utilisant seulement un ordre (partiel) et se servir de l'implémentation pour la justifier c'est un peu foireux. D'ailleurs, en haskell la documentation précise clairement que Ord représente un ordre total:
The Ord class is used for totally ordered datatypes.
Et la signature de l'interface demande clairement que le type possède une certaine notion d'égalité (ce qui n'est pas nécessaire pour un préordre) :
classEqa=>Ordawhere
Néanmoins, il est intéressant de noter que ces conditions ne sont pas vérifiées statiquement, et on peut en effet écrire
[^] # Re: Mode pinaillage :-P
Posté par Aluminium95 . En réponse au journal Cohérence des fonctions de tri. Évalué à 4.
En effet, j'ai mis un bout de temps avant d'abandonner l'idée de comprendre la première phrase et continuer de lire l'article pour voir où l'auteur voulait aller :
Par construction, si
a == balors on ne peut pas les différencier ... du coup ... on retourneaoubc'est pareil.J'ai fini par comprendre que l'égalité
a == bne signifiait pas l'égalité (ni au sens faible de l'égalité physique de pointeurs, ni au sens fort de l'égalité structurelle). Le problème venait donc bien du fait que la relation d'ordre n'en était pas une !Notons que si on définit une nouvelle relation d'égalité
~sur les structures, et que l'ordre<=est une relation d'ordre relativement à cette relation d'égalité, et bien le comportement demaxetminredevient totalement déterminé : si on ax ~ yalors c'est que dans notre programme, on a voulu confondre les deux valeurs, et donc il n'y a pas de raison de choisir un représentant plutôt qu'un autre.Ma conclusion c'est que raisonner sur la sémantique d'une fonction définie sur un ordre (total) en utilisant seulement un ordre (partiel) et se servir de l'implémentation pour la justifier c'est un peu foireux. D'ailleurs, en haskell la documentation précise clairement que
Ordreprésente un ordre total:Et la signature de l'interface demande clairement que le type possède une certaine notion d'égalité (ce qui n'est pas nécessaire pour un préordre) :
Néanmoins, il est intéressant de noter que ces conditions ne sont pas vérifiées statiquement, et on peut en effet écrire