Applications utilisant Decimal versus double. .

Question

Je voulais voir si les gens utilisaient la décimale pour les applications financières au lieu de doubler. J'ai vu beaucoup de gens utiliser le double partout avec des conséquences inattendues. .

Voyez-vous d'autres personnes faire cette erreur? . .

Answer 1

Nous l’avons malheureusement fait et nous le regrettons. Nous avons dû changer tous les doubles en décimales. Les décimales sont bonnes pour les applications financières. Vous pouvez regarder cet article Un type Money pour le CLR :

  

Un argent pratique et performant   structure pour le CLR qui gère   opérations arithmétiques, types de devise,   mise en forme et distribution soignée   et arrondir sans perte.

Answer 2

Oui, l’utilisation de float ou de double pour les états financiers est une erreur courante, source de beaucoup de difficultés. décimal est le choix le plus évident dans ce scénario.

En règle générale, ici (en anglais) constitue une bonne discussion. / double) et ici (décimal).

Answer 3

Ce n’est pas aussi évident que vous pouvez le penser. Récemment, le contrôleur d'une grande entreprise m'a dit qu'il souhaitait que ses rapports financiers correspondent à ceux générés par Excel: maintenir les résultats calculés en interne avec une précision maximale et ne les arrondir qu'à la dernière minute aux fins d'affichage. Cela signifie que vous ne pouvez pas toujours faire correspondre les réponses Excel par des calculs manuels en utilisant uniquement les valeurs affichées. Son explication était qu'il y avait plusieurs algorithmes pour générer les résultats, chacun effectuant l'arrondi à un endroit différent en utilisant des valeurs décimales, générant ainsi potentiellement des réponses contradictoires, mais la méthode Excel générant toujours la même réponse.

Personnellement, je pense qu'il a tort, mais avec un si grand nombre de financiers qui utilisent Excel sans comprendre comment l'utiliser correctement pour des calculs financiers, je parie que beaucoup de gens sont d'accord avec ce contrôleur.

Je ne veux pas commencer une guerre de religion, mais j'aimerais entendre d'autres opinions à ce sujet.

Answer 4

Si c'est "scientifique" les mesures (je veux dire poids, longueur, surface, etc.) utilisent deux fois.

S'il s'agit d'un problème financier ou s'il a un lien quelconque avec la loi (par exemple, la superficie d'une propriété), utilisez le format décimal.

La partie la plus difficile est l’arrondissement.

Si la taxe est de 2,4%, arrondissez-vous dans les détails ou après la somme?

La plupart du temps, vous devez faire les deux (ET réparer les difs)

Answer 5

Je l'ai rencontré à quelques reprises. Beaucoup de langues n'ont rien de tel, et pour quelqu'un qui ne comprend pas le problème, cela ressemble à un autre problème, surtout s'il semble que cela fonctionne comme prévu sans lui.

Answer 6

J'ai toujours utilisé Decimal. Au moins quand j'avais un langage qui le supporte. Sinon, les erreurs d'arrondi vous tueront.

Answer 7

Je suis tout à fait d’accord sur les problèmes de correction de virgule flottante et décimale mentionnés ci-dessus, mais de nombreuses applications financières sont essentielles à la performance.

Dans de tels cas, vous envisagerez d'utiliser float / double car la décimale a un impact important sur les performances des systèmes où les types décimaux ne sont pas pris en charge dans le matériel. Et il est toujours possible d’envelopper des types à virgule flottante dans des classes de niveau supérieur (par exemple, Taxe, Commission, Solde, Dividende, Citation, Tick, etc.) qui représentent un modèle de domaine et encapsulent toute la logique d’arrondi ainsi que des opérateurs valides. et leurs interactions. Et oui, dans certains projets, j’ai implémenté des fonctions d’arrondi personnalisées pour réduire jusqu’à 20% de calculs en plus par rapport aux méthodes .NET ou win32.

Une autre chose à considérer est de savoir si vous passez vos objets en dehors du processus, car la sérialisation des nombres décimaux qui sont généralement 4 entiers et leur transmission sur le réseau nécessitent beaucoup plus de temps processeur (en particulier si non pris en charge) et se traduisent par une bande passante nettement plus importante empreinte mémoire.