"The acos functions return arccos x in the interval [0, pi] radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique
(i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans
[0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que
les modes d'arrondi vers le haut soit possible). Mais la norme ne
devrait-elle pas le préciser?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Leca
En news:20070726125504$, Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi] radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique (i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans [0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que les modes d'arrondi vers le haut soit possible). Mais la norme ne devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers le bas dans le modèle de nombres flottants, et où une implémentation de l'arc cosinus donnerait un résultat supérieur d'un epsilon du fait des choix en cours de mode d'arrondi (tous les cas sont sans intérêt à première vue).
Est-ce possible réellement de rencontrer ce cas avec un algorithme de calcul de l'arc cosinus non stupide, et si oui est-il possible de préciser l'algorithme en question, et donc de « prouver » qu'il y a effectivement un problème ?
Par ailleurs, est-ce que les latitudes laissées à l'implémentation au niveau des arrondis (en particulier celui à utiliser pour interpréter « pi » dans la formule de la norme) ne couvrent pas ce cas-là ?
Enfin, comme d'habitude, il faudrait poser la question sur comp.std.c ou la liste de WG14 ou encore directement à Fred Tydeman...
Antoine
En news:20070726125504$22ff@prunille.vinc17.org,
Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi]
radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique
(i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans
[0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que
les modes d'arrondi vers le haut soit possible). Mais la norme ne
devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers le bas
dans le modèle de nombres flottants, et où une implémentation de l'arc
cosinus donnerait un résultat supérieur d'un epsilon du fait des choix en
cours de mode d'arrondi (tous les cas sont sans intérêt à première vue).
Est-ce possible réellement de rencontrer ce cas avec un algorithme de calcul
de l'arc cosinus non stupide, et si oui est-il possible de préciser
l'algorithme en question, et donc de « prouver » qu'il y a effectivement un
problème ?
Par ailleurs, est-ce que les latitudes laissées à l'implémentation au niveau
des arrondis (en particulier celui à utiliser pour interpréter « pi » dans
la formule de la norme) ne couvrent pas ce cas-là ?
Enfin, comme d'habitude, il faudrait poser la question sur comp.std.c ou la
liste de WG14 ou encore directement à Fred Tydeman...
En news:20070726125504$, Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi] radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique (i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans [0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que les modes d'arrondi vers le haut soit possible). Mais la norme ne devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers le bas dans le modèle de nombres flottants, et où une implémentation de l'arc cosinus donnerait un résultat supérieur d'un epsilon du fait des choix en cours de mode d'arrondi (tous les cas sont sans intérêt à première vue).
Est-ce possible réellement de rencontrer ce cas avec un algorithme de calcul de l'arc cosinus non stupide, et si oui est-il possible de préciser l'algorithme en question, et donc de « prouver » qu'il y a effectivement un problème ?
Par ailleurs, est-ce que les latitudes laissées à l'implémentation au niveau des arrondis (en particulier celui à utiliser pour interpréter « pi » dans la formule de la norme) ne couvrent pas ce cas-là ?
Enfin, comme d'habitude, il faudrait poser la question sur comp.std.c ou la liste de WG14 ou encore directement à Fred Tydeman...
Antoine
Vincent Lefevre
Dans l'article <f8a86p$8s0$, Antoine Leca écrit:
En news:20070726125504$, Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi] radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique (i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans [0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que les modes d'arrondi vers le haut soit possible). Mais la norme ne devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers le bas dans le modèle de nombres flottants, et où une implémentation de l'arc cosinus donnerait un résultat supérieur d'un epsilon du fait des choix en cours de mode d'arrondi (tous les cas sont sans intérêt à première vue).
Je pensais que pour la norme, l'intervalle [0, pi] était à considérer au sens mathématique, d'autant plus que la norme ne donne aucune information sur le type de pi ou sur le mode d'arrondi, e.g. pi arrondi dans le mode d'arrondi courant (ce qui n'est même pas évident puisque pi est une constante).
Est-ce possible réellement de rencontrer ce cas avec un algorithme de calcul de l'arc cosinus non stupide, et si oui est-il possible de préciser l'algorithme en question, et donc de « prouver » qu'il y a effectivement un problème ?
Même si on considère ce que tu dis ci-dessus, dans la réalité, il existe des algorithmes "stupides" (avec des résultats surprenants).
Par ailleurs, est-ce que les latitudes laissées à l'implémentation au niveau des arrondis (en particulier celui à utiliser pour interpréter « pi » dans la formule de la norme) ne couvrent pas ce cas-là ?
Une implémentation est-elle libre d'interpréter la norme comme elle l'entend?
Enfin, comme d'habitude, il faudrait poser la question sur comp.std.c ou la liste de WG14 ou encore directement à Fred Tydeman...
Dans l'article <f8a86p$8s0$2@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
En news:20070726125504$22ff@prunille.vinc17.org,
Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi]
radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique
(i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans
[0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que
les modes d'arrondi vers le haut soit possible). Mais la norme ne
devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers
le bas dans le modèle de nombres flottants, et où une implémentation
de l'arc cosinus donnerait un résultat supérieur d'un epsilon du
fait des choix en cours de mode d'arrondi (tous les cas sont sans
intérêt à première vue).
Je pensais que pour la norme, l'intervalle [0, pi] était à considérer
au sens mathématique, d'autant plus que la norme ne donne aucune
information sur le type de pi ou sur le mode d'arrondi, e.g. pi
arrondi dans le mode d'arrondi courant (ce qui n'est même pas
évident puisque pi est une constante).
Est-ce possible réellement de rencontrer ce cas avec un algorithme
de calcul de l'arc cosinus non stupide, et si oui est-il possible de
préciser l'algorithme en question, et donc de « prouver » qu'il y a
effectivement un problème ?
Même si on considère ce que tu dis ci-dessus, dans la réalité, il
existe des algorithmes "stupides" (avec des résultats surprenants).
Par ailleurs, est-ce que les latitudes laissées à l'implémentation
au niveau des arrondis (en particulier celui à utiliser pour
interpréter « pi » dans la formule de la norme) ne couvrent pas ce
cas-là ?
Une implémentation est-elle libre d'interpréter la norme comme elle
l'entend?
Enfin, comme d'habitude, il faudrait poser la question sur
comp.std.c ou la liste de WG14 ou encore directement à Fred
Tydeman...
En news:20070726125504$, Vincent Lefevre va escriure:
Dans la norme, il est dit:
"The acos functions return arccos x in the interval [0, pi] radians."
Il n'est pas dit explicitement s'il s'agit de la valeur mathématique (i.e. avant arrondi) ou de la valeur après arrondi qui doit être dans [0, pi]. Je suppose qu'il s'agit de la valeur mathématique (pour que les modes d'arrondi vers le haut soit possible). Mais la norme ne devrait-elle pas le préciser?
Si je te lis bien, tu te places dans le cas où PI sera arrondi vers le bas dans le modèle de nombres flottants, et où une implémentation de l'arc cosinus donnerait un résultat supérieur d'un epsilon du fait des choix en cours de mode d'arrondi (tous les cas sont sans intérêt à première vue).
Je pensais que pour la norme, l'intervalle [0, pi] était à considérer au sens mathématique, d'autant plus que la norme ne donne aucune information sur le type de pi ou sur le mode d'arrondi, e.g. pi arrondi dans le mode d'arrondi courant (ce qui n'est même pas évident puisque pi est une constante).
Est-ce possible réellement de rencontrer ce cas avec un algorithme de calcul de l'arc cosinus non stupide, et si oui est-il possible de préciser l'algorithme en question, et donc de « prouver » qu'il y a effectivement un problème ?
Même si on considère ce que tu dis ci-dessus, dans la réalité, il existe des algorithmes "stupides" (avec des résultats surprenants).
Par ailleurs, est-ce que les latitudes laissées à l'implémentation au niveau des arrondis (en particulier celui à utiliser pour interpréter « pi » dans la formule de la norme) ne couvrent pas ce cas-là ?
Une implémentation est-elle libre d'interpréter la norme comme elle l'entend?
Enfin, comme d'habitude, il faudrait poser la question sur comp.std.c ou la liste de WG14 ou encore directement à Fred Tydeman...
