Problème avec la fonction Trunc

Version imprimable

02/08/2006, 11h20
yulken

Problème avec la fonction Trunc

Pour des valeurs entieres multiples de 13, TRUNC me renvoie la valeur inférieure.

Ex:

TRUNC(0.65/0.05) = 12

TRUNC(5.2/0.1) = 51

TRUNC(1.3/0.1) = 12

alors que

TRUNC(13) = 13...

superstition???? ou magie
02/08/2006, 13h17
Loceka
C'est certainement un problème dû à la division (multiplication) réelle. Tu travaille avec des réels donc le calcul n'est qu'une succession d'arrondis. Le résultat obtenu pour 5.2 / 0.1 est peut-être 5.1999...e1. Donc quand tu tronques, tu retombes sur 51.

Pour bien faire, il faudrait peut-être faire un test sur la valeur obtenue, par exemple :
Code:

1 2 3 4 5 6 7 const limite = 0.001; ... res := 5.2 / 0.1; tronc := TRUNC(res); if TRUNC(res + limite) > tronc then tronc := tronc+1;
Donc tu introduis un nombre "limite" que tu considères comme négligeable dans tes calculs et si ton résultat + cette limite dépasse la dizaine alors c'est qu'il y'a eu une erreur d'arrondi. Normalement il devrait être de l'ordre de la précision de la mantisse, ce qui dépend de la plateforme, mais 1e-15 devrait être convenable.
02/08/2006, 21h51
denokan

sur mon Turbo Pascal 7.01 téléchargé sur DVP, WriteLn(Trunc(5.2 / 0.1)) m'affiche bien 52 à l'écran .... sur quel compilateur travailles-tu ?
02/08/2006, 22h45
Alcatîz

Bonjour !

Par contre, Free Pascal 2.0.2 et Virtual Pascal 2.1 renvoient tous deux 51.
03/08/2006, 10h45
JoseF

idem Free pascal 1.0.6 ça donne du 12 au lieu de 13 ! :(

je pense que c'est vraiment un bug et même que c'est grave comme problème !

j'ai essayé avec Freepascal de mettre l option compatible avec TP 7.0 mais ça ne change rien : le resultat reste faux !:(

sinon ce n'est pas trop une fonction que j'utilise (je prefère quand cela est possible) utiliser INT mais quand même ça fait désordre !
03/08/2006, 11h32
yulken

Merci de vos réponses,

Citation:

C'est certainement un problème dû à la division (multiplication) réelle. Tu travaille avec des réels donc le calcul n'est qu'une succession d'arrondis. Le résultat obtenu pour 5.2 / 0.1 est peut-être 5.1999...e1. Donc quand tu tronques, tu retombes sur 51.

Le plus étonnant est que cela intervient seulement pour les multiples de 13. Donc le type REAL n y est pour rien ...

Quant à moi, j utilises le compilateur de VAX VMS.
03/08/2006, 16h12
Blue_Strike

salut,
ce qui est sûr est que les ordinateurs font le calcul avec une telle certitude variant en fonction de l'espace mémoire utilisé pour sauvegarder une valeure (le nbre des bits representant la valeur ) d'où une division comme celle ci 5.2/0.1 donne 51.9999999999... qui est pratiquement = 52. Dans ce niveau, le compilateur fait intervenir en appelant la fonction Trunc, y en a des compilaeteurs qui te donne 52 et d'autre qui donne 51 comme résultat.
Pour la remarque du l'entier 13 et ses multiple, bah je c pas exactement le truc, mais j'aimerai bien le savoir... ;)
++
03/08/2006, 19h18
thewho

Bonjour,

Citation:

Envoyé par Blue_Strike

salut,
ce qui est sûr est que les ordinateurs font le calcul avec une telle certitude variant en fonction de l'espace mémoire utilisé pour sauvegarder une valeure (le nbre des bits representant la valeur ) d'où une division comme celle ci 5.2/0.1 donne 51.9999999999... qui est pratiquement = 52. Dans ce niveau, le compilateur fait intervenir en appelant la fonction Trunc, y en a des compilaeteurs qui te donne 52 et d'autre qui donne 51 comme résultat.
Pour la remarque du l'entier 13 et ses multiple, bah je c pas exactement le truc, mais j'aimerai bien le savoir... ;)
++

Alors ceux qui donnent 52 font une erreur : TRUNC, c'est la partie entière d'un nombre, donc = 51 pour 51.9999999999

Et les calculs sur des réels sont toujours approximatifs, le problème étant effectivement dû à la représentation de la valeur (qui change, en particulier avec les REAL des compilateurs.
03/08/2006, 19h31
Alcatîz
Il n'y a pas que la valeur 13 qui soit concernée ! :lol:

N'oublions pas qu'il y a une différence fondamentale entre :
Code:

1 2 3 Begin WriteLn(Trunc(4.0/0.4)); End.
et
Code:

1 2 3 4 5 6 Var a, b : Real; // Ou tout autre type de réel Begin a := 4.0; b := 0.4; WriteLn(Trunc(a/b)); End.
Dans le premier cas, c'est le compilateur qui effectue le calcul (troncature comprise) et qui code le résultat en dur dans l'exécutable; dans le second cas, la fonction Trunc de la RTL est réellement appelée lors de l'exécution. Vérifié dans les outputs Assembleur générés lors de la compilation.

J'ai fait une petite expérience avec Virtual Pascal 2.1 :
- Dans le 1er cas : résultat = 10
- Dans le 2ème cas avec le type Real : résultat = 9
- Dans le 2ème cas avec le type Double : résultat = 9
- Dans le 2ème cas avec le type Extended : résultat = 10.
03/08/2006, 19h50
Loceka

Donc c'est bien une erreur d'approximation dûe à la taille de la mantisse ?

La solution que je proposait est donc valide il me semble, même si c'est plus ou moins du bidouillage...
03/08/2006, 20h49
thewho

Bonjour,

Oui, c'es du bidouillage, mais on n'y échappe pas, quel que soit le langage utilisé.

Une alternative serait d'utiliser des réels de précision quelconque, mais de toute manière ce ne serait que décaler le problème, vu que, bien entendu, on ne peut utiliser une précision infinie, qui serait nécessaire pour représenter exactement n'importe quelle valeur.

Et le prix serait le temps de calcul, puisque cela interdirait d'utiliser l'unité de calculs flottants du processeur. De quoi avoir besoin d'une cafetière en attendant la fin d'un calcul.
08/08/2006, 13h57
JoseF

Citation:

Oui, c'es du bidouillage, mais on n'y échappe pas, quel que soit le langage utilisé.

personnellemnent ça me gêne quand même..:roll:
en fonction du compilateur on a 12 ou 13
en fonction de déclaré en variable ou directement en calcul dans le write
je pense que le systeme d exploitation doit aussi jouer si on est sur 16 32 ou 64 bits ?

donc je m'imagine je fais un programme et si j'ai 13 ma barriière se baisse quand le train passe sinon je la laisse ouverte.

je change de compilateur ou si je recompile pour une raison ou pour une autre et ma barriere ne se baisse plus... parce que j'ai 12. :cry:

programmer n'est pas bidouiller tout de même... ??

sur un code de 100 lignes on peut s'en apercevoir mais si mon programme fait 20000 lignes ... et si en interne j'ai de temps en temps 12.000000001 ou 11.999999999 difficile quand même à deceler...
08/08/2006, 14h33
thewho

Bonjour,

Citation:

Envoyé par JoseF

personnellemnent ça me gêne quand même..:roll:
en fonction du compilateur on a 12 ou 13
en fonction de déclaré en variable ou directement en calcul dans le write
je pense que le systeme d exploitation doit aussi jouer si on est sur 16 32 ou 64 bits ?

donc je m'imagine je fais un programme et si j'ai 13 ma barriière se baisse quand le train passe sinon je la laisse ouverte.

je change de compilateur ou si je recompile pour une raison ou pour une autre et ma barriere ne se baisse plus... parce que j'ai 12. :cry:

programmer n'est pas bidouiller tout de même... ??

sur un code de 100 lignes on peut s'en apercevoir mais si mon programme fait 20000 lignes ... et si en interne j'ai de temps en temps 12.000000001 ou 11.999999999 difficile quand même à deceler...

Quand on travaille avec les réels, il faut fraire très attention, et le résultat des calculs dépend de la représentation en mémoire, soit en natif du processeur, soit autre.

Et ce que tu obtiens avec write est une approximation de plus par rapport à la valeur effectivement stockée (arrondi dû aux nombres de chiffres que tu demandes en affichage).

Le seul moyen de "contourner" ce problème, est d'accepter le test pour vrai si si les valeurs testées sont suffisamment proches ("suffisamment proche" reste à définir pour chacun, sachant que ça va dépendre de l'ordre de grandeur de la valeur, dû à la précision limitée des réels).

Si tout ça te pose problème, n'utilise que des entiers (pas toujours possible, n'est-ce pas ?), ou fait toi une librairie de calcul des réels en très haute précision (ce qui n'est que reculer pour mieux sauter, la précision ne pouvant évidemment pas être infinie), ou arrête de programmer : c'est un problème incontournable sans bricoler un peu.