Cacul impossible, Delphi limité

Bonjour,

Je souhaite faire faire un calcul à Delphi et je m'étonne de ses limites !

Je suppose que c'est moi qui doit mal m'y prendre car sinon, cela voudrait dire que Delphi ne peut gérer les calculs évolué (style scientifiques).

Mon problème est le suivant:

J'ai une variable

Code:

---

resultReal: real (donc, elle doit contenir de 5.0 x 10^-324 .. 1.7 x 10^308)

---

Je pose le calcul suivant:

Code:

---

resultReal := 180 * 12103014 ;

---

et j'obtiens l'erreur suivante:

Code:

---

Débordement dans opération de conversion ou arithmétique !

---

Alors que 180 * 12103014 est bien compris entre 5.0 x 10^-324 .. 1.7 x 10^308.

Je ne comprends pas pourquoi...

Quelqu'un sait-il d'où mon erreur vient ? Et comment faire en sorte que Delphi prenne bien en compte le "vrai" intervalle de Real ? Car j'ai du mal à croire que Delphi soit limité par ce "petit" calcul...

Par avance, merci.

PS: j'ai aussi essayé avec le type Extended mais j'obtiens le même résultat :cry:

Julien.

amusant ! testé en D5 Pro :

Code:

---

1 2 3 4 5 6 7

var a,b,c: Real; begin a:=180; b:=12103014; c:=a*b; // sans pb c:=180*12103014; // overflow

---

voci au moins comment s'en sortir !!

Bonjour,

Le problème est que si tu écris

Code:

---

1 2 3

resultReal: real; ... resultReal := 180 * 12103014 ;

---

Les 2 valeurs que tu multiplies étant des entiers, avant de mettre la valeur dans resultReal, le compilateur fait le calcul 180 * 12103014 dans un entier, or ce calcul dépasse la valeur possible pour un entier (2^31 -1)
la solution est de faire

Code:

---

1 2	resultReal := 180; resultReal := resultReal * 12103014 ;

---

Ou bien, puisque tu connaît la valeur à mettre:

Code:

---

resultReal := 2178542520; // = 180 * 12103014 ;

---

Plus simple :

Code:

---

resultReal := 180.0 * 12103014 ;

---

Oui, c'est seulement un problème de typage.
Comme l'écris Graffito, écrire 180.0 désigne un double, 180 seul désigne un entier.

Le mieux c'est de tout typer, au moins, tu ne laisses pas d'interprétation implicite au pré-processeur :

Code:

---

resultReal := 180.0 * 12103014.0

---

C'est un "hic" que Borland doit resoudre dans les prochaines versions, non? S'il faut necessairement savoir ce qui se passe en interne avant de faire une telle operation, c'est pas pour demain, la programmation ouverte au "grand public"...

Bonjour,

Citation:

---

Envoyé par mayloshi

C'est un "hic" que Borland doit resoudre dans les prochaines versions, non? S'il faut necessairement savoir ce qui se passe en interne avant de faire une telle operation, c'est pas pour demain, la programmation ouverte au "grand public"...

---

Non, je ne pense pas.
C'est là un comportement parfaitement clair et logique: le compilateur voit la multiplication de 2 entiers, il les multiplie en mettant le résultat dans un entier, et ne se préoccupe qu'ensuite de ce qu'il faut en faire. Je ne vois pas ce qu'il y a de difficile à comprendre là-dedans.
Un compilateur C/C++ fait la même chose, et je suppose que c'est vrai pour la plupart des langages du même genre.

Bonjour,

Citation:

---

Envoyé par thewho

Un compilateur C/C++ fait la même chose, et je suppose que c'est vrai pour la plupart des langages du même genre.

---

Je pense aussi...Parceque si quelqu'un avait trouvé un compilateur capable d'utiliser des variables et de les transtypé à volonter au fur et à mesure d'une execution sans gaspiller trop de mémoire(c.a.d qu'on aurait plus alors à se soucier de déclarés leur type au début, par exemple...), je crois qu'il serait riche et célèbre...

@+.

En effet, je suis assez d'accord avec Thewho.

Bien que ceci peut être piegeux (ca existe ? :aie:), si le compilateur s'amusait systématiquement à caster dans le type du résultat, je pense qu'il y aurait encore plus de problèmes sur des expressions plus compliquées (avec des div, des xor, des /... dans la même expression), et au final l'utilisateur ne controlerait plus son expression et serait de toute manière obligé de caster.

Là, c'est au programmeurs de contrôler ce qu'il fait et de maitriser son résultat, quitte à caster certains membres.

Donc plutot que de laisser au compilo, des cast qui peuvent être aléatoires, il prends le type par défaut, et sinon les cast utilisateurs.

Enfin, c'est mon avis, mais je concois qu'il peut se discuter ;)

:Edit: Mayloshi... PHP ? :)

Bonjour,

Tout d'abord, merci à vous tous pour vos réponses.

Ca fonctionne.

J'avoue que je trouve que ça peu pieger le développeur (en herbe que je suis).

car pour faire l'opération suivante:

Code:

---

1 2 3 4 5 6 7

a := (round((b*c)/d)) ;   a: integer; b: integer; c: integer; d: integer;

---

Si je place ma souris en mode déboggage sur les différentes variables, j'obtiens ces résultats:

Code:

---

1 2 3 4

a=-2301 b=180 c=12103014 d=919660

---

et pour obtenir le bon résultat, il me faut faire comme ça:

Code:

---

1 2 3 4 5 6

valTemp: real ; valTemp := b ; valTemp := valTemp*c ; valTemp := valTemp / d ; a := round(valTemp) ;

---

Ce qui est moins clair d'un point de vue programmation, à mon avis... mais ça fonctionne, c'est l'essentiel !! :D

Encore merci à vous tous...

Julien.

Un cast explicite vaut mieux qu'un cast implicite !

Code:

---

a := (round(real(b*c)/real(d))) ;

---

Bonjour,

Citation:

---

Envoyé par trident_job

Un cast explicite vaut mieux qu'un cast implicite !

Code:

---

a := (round(real(b*c)/real(d))) ;

---

---

Je n'ai pas Delhi sous la main, mais je ne pense pas que ce soit bon : tu tombes dans le même problème, à savoir que le compilateur voit 2 entiers (b et c) à multiplier, il les multiplie dans un entier, etc...

Il faudrait faire plutôt

Code:

---

a := (round(real(b)*c/d)) ;

---

Pas la peine de refaire un cast pour d : du moment qu'une des valeurs est un real, tous les autres calculs s'enchaînent dans ce format.

Mais je crois me souvenir que Delphi n'aime pas qu'on fasse un cast de type

Code:

---

1 2 3 4 5

a : integer; b: real; ... b = real(a);

---

Ce qui n'es pas génant dans le cas ci-dessus, mais qui l'est pour l'expression de julien.d

Si c'est bien le cas, on peut quand même simplifier le code écrit par julien.d qui était:

Code:

---

1 2 3 4 5

valTemp: real ; valTemp := b ; valTemp := valTemp*c ; valTemp := valTemp / d ; a := round(valTemp) ;

---

en faisant

Code:

---

1 2 3

valTemp: real ; valTemp := b ; a := round( (valTemp*c)/d) ;

---

Les parenthèses en rouge étant normalement inutiles, mais j'ai l'habitude d'en mettre pour préciser, ne serait-ce que pour lever toute ambiguïté pour le lecteur.

Mon exemple fonctionne thewho :mrgreen:

En tout cas, ce thread fait couler de l'encre ... enfin, tapotter du clavier !

Le vrai probleme ici c'est que l'on ne doit jamais affecter à une variable une expression qui n'est pas de son type. Alors oui dans un langage normal y'a du cast implicite qui marche correctement... Mais bon. :D

Mais ici, le plus simple est d'avoir a, b, c et d en real, non ?
Ou alors, la rigueur serait de caster explicitement TOUTES les variables.

De plus je vois pas pourquoi il fait un round() sur une division entiere. 8O

Bonjour,

Citation:

---

Envoyé par themei

Alors oui dans un langage normal y'a du cast implicite qui marche correctement...

---

Delphi fonctionne de manière tout à fait normale, tu devrais avoir compris ça si tu as effectivement lu et compris la succession des interventions.

Citation:

---

Envoyé par themei

Mais ici, le plus simple est d'avoir a, b, c et d en real, non ?
Ou alors, la rigueur serait de caster explicitement TOUTES les variables.

---

Inutile, une fois qu'on a commencé le calcul dans une variable du type final.

Citation:

---

Envoyé par themei

De plus je vois pas pourquoi il fait un round() sur une division entiere

---

Eh non, en Delphi, une division de 2 entiers donne un réel. La division entière est div