ORDRE DE SOMMATION DES FLOTTANTS (EXEMPLE PAR SIMULATION)

Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008
- - Dernière réponse : metanil
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007
- 4 nov. 2007 à 18:43
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/44584-ordre-de-sommation-des-flottants-exemple-par-simulation

metanil
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007
-
ahahahahah !

Mon discours n'attaquait nullement les "fous" du clavier....

(j'ai preque terminé mon TPaintBox 3D !)
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
13 -
"quantième de seconde que permet d'économiser tel ou tel code"
il convient d'en parler, au contraire.
Il y a donc du monde pour croire que code optimisé ne sert à rien, qu'aucune boite n'investit plus dedans et qu'il n'y a plus d'application à ce genre de code ?
Je connais pourtant du monde qui en vit (devinez qui) et qui n'a pas l'impression que son carnet de commandes est rempli par des entrepreneurs délirants.
metanil
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007
-
Disons que le terme même de "précision" signifie bien ce qu'il veut dire !

C'est dans "sans précision" que l'intéret de l'objet réside, sinon, tu es forcément tributaire de sa signification...
cs_JCDjcd
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
2 -
oui mais tu ne resouds pas le probleme de (pi+e)+phi different de pi+(e+phi) quelque soit la precision voulue
(phi=nombre d'or,e=nombre d'euler,pi=pi)

ALGORITHME avec un I
metanil
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007
-
En fait, ce TSolverObjet travaille par réduction d'expression...
Il est écrit en Delphi, ce qui ne nous avance guère pour la surcharge, et nous rabaisse donc au niveau du C, mais son plus réside dans l'interprétation des variables... Elles sont codées sous forme de AnsiString (par définition : type ouvert) et non sous forme de float, integer ou autres extended (types fermés)...

Pour vous embrouiller un peu plus, 1/3 et PI doivent-ils être exclus de tout algorythme de somme ?

Ainsi A "devient "1/3', alors que 1/3 "devient" 0,33333[3]... (avec la précision voulue, et non celle imposée pour le codage des floats...); cette précision, elle n'est indiquée que lors de la "sortie", par l'opérande qui reçoit le résultat... Durant tout le transport de l'information A, A reste 1/3, et conserve ainsi son intégrité textuelle, permettant la réduction ou non des fractions...

En C++, A + B, c'est +(A,B), mais c'est surtout dépendant du type du résultat ! si tu veux un float en sortie, tu auras la précision annoncée d'un float en sortie... Si tu veux un BigFloat, et bien, c'est cette précision que tu auras...

Il nous faut, dans le corps du template operator+(A,B), définir, pour la précision voulue, la bonne de sommation de deux objets.

Dans le cadre de math++, c'est bien la sommation de deux objets "Grands Nombres" qui serait invoquée... Ainsi tout dépendra de son implémentation... En C, je ne vous garantis pas la possibilité de surcharger pour obtenir la sommation de deux AnsiString... Quand à revoir tout un programme après le changement de tous "float" par "bigfloat"...et le linkage de la nouvelle librarie...Heureusement que MSC 2.0 n'est plus en lice...

En fait, en C++, ce qui importe ce sont les objets vivants après le C (utile dans l'implémentation des fonctions)...