Débutant sous Python 2.4 je ne comprends pas pourquoi quand je lui
demande de calculer 54.3/3 il me donne comme résulat 18.0999...
Il ne s'agit même pas 'un arrondi puisque le résultat est simple et avec
une seule décimale.
N'étant pas fluent je ne suis pas sûr d'avoir tout coompris si ce n'est qu'un irrationnel ne se limite pas à son expression avec quelques décimales derrière la virgule.
MAIS comment se fait-il que Python ne sache pas faire sans erreur une opération aussi simple que 54.3/3 qui fait 18.1 et c'est tout ;-)
Python n'y est pour rien. C'est la représentation des [pseudo-]réels en informatique qui pose problème. Et ce n'est pas une nouveauté.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Eric Grambier wrote:
Bonjour,
N'étant pas fluent je ne suis pas sûr d'avoir tout coompris si ce n'est
qu'un irrationnel ne se limite pas à son expression avec quelques
décimales derrière la virgule.
MAIS comment se fait-il que Python ne sache pas faire sans erreur une
opération aussi simple que 54.3/3 qui fait 18.1 et c'est tout ;-)
Python n'y est pour rien. C'est la représentation des [pseudo-]réels en
informatique qui pose problème. Et ce n'est pas une nouveauté.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
N'étant pas fluent je ne suis pas sûr d'avoir tout coompris si ce n'est qu'un irrationnel ne se limite pas à son expression avec quelques décimales derrière la virgule.
MAIS comment se fait-il que Python ne sache pas faire sans erreur une opération aussi simple que 54.3/3 qui fait 18.1 et c'est tout ;-)
Python n'y est pour rien. C'est la représentation des [pseudo-]réels en informatique qui pose problème. Et ce n'est pas une nouveauté.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
R12y
On Tue, 13 Sep 2005 17:26:35 +0200, bruno modulix wrote:
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
Do Re Mi chel La Si Do
Bonsoir !
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter les nombres flottants. Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques, maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc, Python respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour les franglais). C'était inclus dans les processeurs, bien avant les coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce chemin n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD en Python, ils restent confidentiels.
Comme l'a signalé Bruno Modulix, il y a aussi la voie "decimal", qui suit une démarche plus algorithmique.
Je rappelle également que, pour les entiers, Python travaille différemment. Et, comme les entiers, en Python, n'ont pas de limites, on peut faire pas mal de choses.
Mais le respect de l'IEEE-754 n'a pas que des inconvénients. Par exemple, lorsqu'on dialogue (pilote) Excel depuis Python, on peut échanger directement les valeurs, sans se poser de questions. Et c'est pareil, pour communiquer avec la plupart des langages ou logiciels. Pas (plus) besoin de convertir, ou transcrire, les valeurs.
@-salutations
Michel Claveau
Bonsoir !
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter
les nombres flottants.
Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques,
maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc, Python
respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour les
franglais). C'était inclus dans les processeurs, bien avant les
coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce chemin
n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD en
Python, ils restent confidentiels.
Comme l'a signalé Bruno Modulix, il y a aussi la voie "decimal", qui suit
une démarche plus algorithmique.
Je rappelle également que, pour les entiers, Python travaille différemment.
Et, comme les entiers, en Python, n'ont pas de limites, on peut faire pas
mal de choses.
Mais le respect de l'IEEE-754 n'a pas que des inconvénients. Par exemple,
lorsqu'on dialogue (pilote) Excel depuis Python, on peut échanger
directement les valeurs, sans se poser de questions. Et c'est pareil, pour
communiquer avec la plupart des langages ou logiciels. Pas (plus) besoin de
convertir, ou transcrire, les valeurs.
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter les nombres flottants. Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques, maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc, Python respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour les franglais). C'était inclus dans les processeurs, bien avant les coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce chemin n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD en Python, ils restent confidentiels.
Comme l'a signalé Bruno Modulix, il y a aussi la voie "decimal", qui suit une démarche plus algorithmique.
Je rappelle également que, pour les entiers, Python travaille différemment. Et, comme les entiers, en Python, n'ont pas de limites, on peut faire pas mal de choses.
Mais le respect de l'IEEE-754 n'a pas que des inconvénients. Par exemple, lorsqu'on dialogue (pilote) Excel depuis Python, on peut échanger directement les valeurs, sans se poser de questions. Et c'est pareil, pour communiquer avec la plupart des langages ou logiciels. Pas (plus) besoin de convertir, ou transcrire, les valeurs.
@-salutations
Michel Claveau
Christophe Cavalaria
Do Re Mi chel La Si Do wrote:
Bonsoir !
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter les nombres flottants. Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques, maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc, Python respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour les franglais). C'était inclus dans les processeurs, bien avant les coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce chemin n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD en Python, ils restent confidentiels.
Bof, la norme BCD n'a aucun avantage sur la norme IEEE-754 si ce n'est le fait de paraître plus juste aux gens qui ont l'habitude du système à base 10. Dans un système à base 10, seuls les nombres rationnels de dénominateur multiples de la forme 2^n*5^m ont une écriture fini explicite. La norme IEEE-754 utilise la base 2 pour cela et donc seuls les nombres rationnels dont le dénominateur est une puissance de 2 à une écriture finie explicite. Lors de la convertion base 2 vers base 10, si le nombre avait une écriture infinie, il en aura une aussi en base 10. Il reste donc que la norme BCD n'apporte au final comme seul avantage sur la norme IEEE-754 pour la représentation visuelle de certains nombres alors qu'elle gaspille de la précision !
Au final, les résultats pour l'utilisateur sont un peu troublants mais pour les gens qui s'y connaissent, ils savent qu'il faut soit faire avec, soit utiliser un vrai système de précision infinie comme le module Decimal.
Do Re Mi chel La Si Do wrote:
Bonsoir !
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter
les nombres flottants.
Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques,
maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc,
Python respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour
les franglais). C'était inclus dans les processeurs, bien avant les
coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce
chemin n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD
en Python, ils restent confidentiels.
Bof, la norme BCD n'a aucun avantage sur la norme IEEE-754 si ce n'est le
fait de paraître plus juste aux gens qui ont l'habitude du système à base
10. Dans un système à base 10, seuls les nombres rationnels de dénominateur
multiples de la forme 2^n*5^m ont une écriture fini explicite. La norme
IEEE-754 utilise la base 2 pour cela et donc seuls les nombres rationnels
dont le dénominateur est une puissance de 2 à une écriture finie explicite.
Lors de la convertion base 2 vers base 10, si le nombre avait une écriture
infinie, il en aura une aussi en base 10. Il reste donc que la norme BCD
n'apporte au final comme seul avantage sur la norme IEEE-754 pour la
représentation visuelle de certains nombres alors qu'elle gaspille de la
précision !
Au final, les résultats pour l'utilisateur sont un peu troublants mais pour
les gens qui s'y connaissent, ils savent qu'il faut soit faire avec, soit
utiliser un vrai système de précision infinie comme le module Decimal.
Comme beaucoup de langages, Python suit la norme IEEE-754 pour représenter les nombres flottants. Cette norme est d'ailleurs gérée par les coprocesseurs mathématiques, maintenant inclus en standard dans la plupart des processeurs.
La norme est précise, jusque dans son imprécision (si ! si !). Donc, Python respecte aussi ces points là.
Donc, ce qu'il faut critiquer, c'est la norme. Pas Python.
Les processeur offrent bien une autre possibilité : le BCD (ou DCB pour les franglais). C'était inclus dans les processeurs, bien avant les coprocesseurs mathématiques. Même le 8080 savait gérer le BCD.
Malheureusement, pour des raisons essentiellement universitaires, ce chemin n'a jamais vraiment été suivi. Et, s'il existe quelques modules BCD en Python, ils restent confidentiels.
Bof, la norme BCD n'a aucun avantage sur la norme IEEE-754 si ce n'est le fait de paraître plus juste aux gens qui ont l'habitude du système à base 10. Dans un système à base 10, seuls les nombres rationnels de dénominateur multiples de la forme 2^n*5^m ont une écriture fini explicite. La norme IEEE-754 utilise la base 2 pour cela et donc seuls les nombres rationnels dont le dénominateur est une puissance de 2 à une écriture finie explicite. Lors de la convertion base 2 vers base 10, si le nombre avait une écriture infinie, il en aura une aussi en base 10. Il reste donc que la norme BCD n'apporte au final comme seul avantage sur la norme IEEE-754 pour la représentation visuelle de certains nombres alors qu'elle gaspille de la précision !
Au final, les résultats pour l'utilisateur sont un peu troublants mais pour les gens qui s'y connaissent, ils savent qu'il faut soit faire avec, soit utiliser un vrai système de précision infinie comme le module Decimal.
Do Re Mi chel La Si Do
Re
Tout dépend du besoin. Lorsqu'on travaille en gestion (comptabilité, paye, production, facturation, commercial, etc.) on travaille en base 10. De plus, on n'a pas besoin d'une grande précision (très souvent, seulement en monnaie et centimes). Dans ce genre de cas, très fréquent, le BCD apparaîtrait particulièrement intéressant, ...sauf qu'il est trop peu répandu.
@-salutations
Michel Claveau
Re
Tout dépend du besoin. Lorsqu'on travaille en gestion (comptabilité, paye,
production, facturation, commercial, etc.) on travaille en base 10. De plus,
on n'a pas besoin d'une grande précision (très souvent, seulement en monnaie
et centimes).
Dans ce genre de cas, très fréquent, le BCD apparaîtrait particulièrement
intéressant, ...sauf qu'il est trop peu répandu.
Tout dépend du besoin. Lorsqu'on travaille en gestion (comptabilité, paye, production, facturation, commercial, etc.) on travaille en base 10. De plus, on n'a pas besoin d'une grande précision (très souvent, seulement en monnaie et centimes). Dans ce genre de cas, très fréquent, le BCD apparaîtrait particulièrement intéressant, ...sauf qu'il est trop peu répandu.
