Discussion :

[KOUADIO SEVERIN]

BONJOUR CHERS AMIS,

J'ai un vrai soucis. Au fait je suis entrain de développer une application de finance et je me trouve confronter à une erreur dont je ne comprends pas la cause. En effet j'ai des tableau de calcul d'amortissement de crédit dont les calculs marchent parfaitement. Je décide donc de faire ma gestion sous Windev 14 et il se trouve que le résultat de calcul de mon annuité n'est plus correct.
J'ai capital emprunté : 4 000 000 000
taux annuel : 8%
nombre d’échéances : 28
sous Excel ou Access, j'ai ramené le taux annuel à un taux semestriel en procédant comme suit :
txint1 = (SAI_Taux1 + 1) ^ (6 / 12) - 1

Ensuite l'annuité est obtenue en faisant :
annuité = Cptal1 * (txint1 / (1 - (1 + txint1) ^ -Nbre_Période))

annuité = 237926 715

par contre les mêmes formules sous Windev 14 me donnent :
annuité = 237 928 000

Quel est le problème s'il vous plait?

Merci pour votre soutien.

[goomazio]

Bonjour,

N'est-ce pas là un problème courant en programmation, qui est l'utilisation de types "trop petits" pour faire des "gros" calculs ?

Si oui, voir du côté du type numérique Monétaire pour Windev.

Un monétaire est un réel codé sur 10 octets.Un monétaire peut avoir jusqu'à 23 chiffres significatifs (17 maximum pour la partie entière, 6 maximum pour la partie décimale) et peut prendre une valeur entre -604 462 909 807 314 587,353 087 et +604 462 909 807 314 587,353 087.

Le type monétaire est conseillé pour éviter les erreurs d'arrondi dues au codage binaire des réels.

[dsr57]

Bonjour

+1 pour le type monétaire, une piste aussi avec le type numérique

Bon dev

[KOUADIO SEVERIN]

Apparemment ça doit être effectivement un problème de type. Mais comment avoir la meilleure précision.
J'ai changé le type des champs comme demandé par les internautes en lieu et place du monétaire précedemment donnant la valeur Annuité = 237 928 000 en numérique haute précision.

Cette fois avec les types de champs numérique j'ai la valeur Annuité = 237 925 380

Or Excel et Access donnent Annuité = 237 926 715 ce qui est juste.

Je suis planté là au risque de revenir à mon fichier excel.

[Hemgé]

Bonjour,

Il y a peut-être une perte de précision dans les calculs intermédiaires ou avec les variables intermédiaires, voire des arrondis (in)volontaires.

A ce stade, pour vous répondre en connaissance de cause, au-delà de la méthode générale que vous nous avez exposée, il nous faudrait voir le code réel, en ce compris les définitions de toutes les variables utilisées.

Or Excel et Access donnent Annuité = 237 926 715 ce qui est juste.

"ce qui est juste" :

• cela signifie-t-il que vous avez d'autres confirmations (extérieures) de la valisité de ces résultats ?
  Ou bien que vous avez mis une première méthode au point sous Access ou Excel, puis fait le nécessaire pour que la seconde fournisse un résultat concordant, et que vous considérez ensuite le résultat issu de votre méthode habituelle comme la norme, sans pour autant l'avoir validée ?
• vous utilisez peut-être la même bibliothèque de fonctions.

Donc, êtes-vous objectivement certain que votre réponse "MS" est plus valable que la réponse "WD" et que c'est bien WD qui in fine laisserait une imprécision (ceci, après élimination des des scories liées à la précision des types etc) ?



Hemgé

[dsr57]

Bonjour


D'après l'aide en ligne sur le type de variable Numérique :

• Lors de l'affectation d'un numérique par une valeur (valeur directement saisie, fournie par une fonction, ...), cette valeur est automatiquement convertie en réel par le compilateur
• Pour forcer l'affectation d'un numérique, utilisez 0n devant la valeur.

Peut être une piste sur l'erreur de résultat, sinon il faut vérifier le résultat étape par étape

Bon dev

[Nicolas_Jeanneau]

Bonjour,

pour ce genre de calculs, j'essaye toujours de passer par une formule la plus complète possible sans calcul intermédiaire. Ensuite, le type est très significatif dans le résultat car il va y avoir un arrondi dans beaucoup de cas.

le formule à reprendre serait en une fois :

annuité = Cptal1 * (((SAI_Taux1 + 1) ^ (6 / 12) - 1) / (1 - (1 + ((SAI_Taux1 + 1) ^ (6 / 12) - 1)) ^ -Nbre_Période))

Pour être également persuadé que ce n'est pas WinDev qui serait bon et non pas Excel, il faudrait changer le type des cellules de calcul pour afficher les décimales ...

bon courage,

Nicolas

[KOUADIO SEVERIN]

Ok, J'essaie vos propositions et je vous informe de la suite.

Merci beaucoup pour votre appui.

[KOUADIO SEVERIN]

Merci Beaucoup chers amis.
Effectivement le problème se trouvait au niveau des arrondis.
J'ai juste copier collé la formule proposé par Nicolas_Jeanneau. Ca merveilleusement marché.
Une fois de plus merci à la grande famille des développeurs de developpez.net.
Merci chers amis