ORDRE DE SOMMATION DES FLOTTANTS (EXEMPLE PAR SIMULATION)
The Incredible Godzy
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008
-
1 nov. 2007 à 20:34
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
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
https://codes-sources.commentcamarche.net/source/44584-ordre-de-sommation-des-flottants-exemple-par-simulation
4 nov. 2007 à 18:43
Mon discours n'attaquait nullement les "fous" du clavier....
(j'ai preque terminé mon TPaintBox 3D !)
4 nov. 2007 à 18:40
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.
4 nov. 2007 à 16:38
C'est dans "sans précision" que l'intéret de l'objet réside, sinon, tu es forcément tributaire de sa signification...
4 nov. 2007 à 13:12
(phi=nombre d'or,e=nombre d'euler,pi=pi)
ALGORITHME avec un I
3 nov. 2007 à 23:28
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)...
3 nov. 2007 à 12:51
en tout cas la source est intéressante :p
3 nov. 2007 à 12:36
cela m'a pris en tout et pour tout 30min ...
je suis d'accord avec toi sur le cote generique ...
(faut pas oublier qu'avec les templates pour chaque type,
tu auras une copie de tes fonctions, donc apres le .exe sera
gros, plus gros... et est-ce vraiment utile ? tu travailles avec
combien de types differents ? moi par exemple mes structures de donnees
avec les arbres rouge et noir sont totalement generiques, et c'est du C, alors
qu'en C++ on aura tendance a utilise un template et donc faire 36.000 copies de mes
fonctions d'arboresence pour mes 36.000 utilisations avec des types differents, alors ca
ce n'est pas de la generaticite, c'est du bourrinnage (sauf si c'est plus rapide, ce qui je pense
est le cas !)
bref arretons-la ce (beau?) debat, et revenons au vrai sujet : l'associativite des flottants
tu as un solution dans ton TSolverObject ?? raconte-nous !
3 nov. 2007 à 12:20
remplacer le mot class par struct ne suffira pas
tout comme ton programme ne compilera pas avec un compilateur C++
je suis d'accord avec toi, tout se passe dans la tête du programmeur
mais au final, ce n'est pour moi qu'une question de point de vue
comme je te lai dit je suis un programmeur C à la base
et lorsque j'ai découvert le C++ j'y ait vu de nouvelles possibilités
non pas des choses impossibles à faire en C mais plus faciles à implémenter en C++
les templates par exemple, faire une seule fonction générique, le compilateur fera les fonctions nécessaires en fonction du type, ect...
c'est la réutilisabilité qu'apporte le C++ et qui me fait gagner du temps
sur des petits projets comme celui-ci sur lequel du as du passer à tout casser 2h ça ne te fera rien gagner, mais les projets sur lesquels je travaille qui nécessitent plus de 6 mois de développement et où je réutilise de nombreuses classes génériques qui ont été créées pour des projets précédents j'y ai gagné facile autant de temps
3 nov. 2007 à 12:12
Un autre aspect non négligeable du C++ est le code template car écrire du code générique en C est possible, oui bien sûr que c'est possibble, mais c'est simplement...moche comparé à ce qu'on peut faire en C++.
Enfin, l'apport de la STL est très intéressant dans un programme en C++ même si celui-ci n'utilise pas de structures avancé du C++ explicitemment, notamment string, vector, (priority_)queue... Et dans ce cas, le temps gagné en dévloppement peut-être sensible.
Bref, je ne dis pas que le C est obsolète ni qu'il ne faut pas développer en C mais je dis que ne jurer que par le C c'est parfois se montrer borner. De même pour le C++ bien sûr :)
3 nov. 2007 à 11:53
tu dis que le C++ permet de faire des codes plus structures...
c'est pas vrai, tout cela c'est dans la tete du programmeur,
le programme est a l'image de son createur (ou son copieur
puisque nous vivons plus dans un monde de copie que de
creation, surtout dans le monde de la programmation...bref
c'est un autre debat :-) ), donc si tu es tres clair et
ordonne dans ta tete, ton programme le sera aussi, et c'est
la seule regle, c'est vrai dans tous les langages, meme
l'assembleur !
et je tiens a preciser que ici dans ce site CPPfrance.com,
tout le monde ecrit en C++ mais tout le monde fais du C,
il suffirait de remplacer le mot "class" par le mot "structure",
et le tour sera joue... et sur ce site le seul truc C++ utilise
en majorite c'est la surcharge d'operateur, ce qui n'est pas
un avance majeur dans la rentabilite, en mettre Obj1+Obj2, moi
je mets AddObj(Obj1,Obj2) , ca marche, et j'en meurs pas...
ce qui est marrant c'est que tu vois cette source-ci ?
(on a tentance a l'oublier) tu as lance l'executable, il est
beau le prgm non ? ca bouge de partout et tout? ca fait des trucs ?
bon ben il est fait en C d'accord, il est fais pas moi d'accord ?
une seule question, a ton avis j'ai mis combien de temps a l'ecrire ?
(et en C++ tu aurais mis combien de temps?)
3 nov. 2007 à 11:48
Que ceux qui le souhaitent l'essayent et ils verront !
3 nov. 2007 à 10:18
- J. Vignes, à l'Université Pierre et Marie Curie de Paris (Paris VI)
- M. La Porte, Maître de Recherches, Institut Français du Pétrole
Ces auteurs, que j'ai bien connus, ont développé et beaucoup publié dans les années 1970 une méthode de permutation-perturbation qui permet de connaître l'espace d'incertitude d'un résultat de calcul par ordinateur du fait des imperfections de représentation des nombres flottants en machine. Quand ce calcul a un mauvais conditionnement cet espace d'incertitude est grand. Leur méthode permet de calculer la taille de cet espace.
Si leurs livres ne sont plus disponibles, on trouve très facilement sur Internet de nombreux articles qui expliquent leur méthode, tant en français qu'en anglais.
J'ai programmé avec toute satisfaction cette méthode qui exploite les imperfections de la machine pour détecter les incertitudes du résultat de calcul provenant justement de ces imperfections internes. Et cela marche très bien.
3 nov. 2007 à 01:42
Je me suis peut-être mal exprimé, mais si le battement d'aile est considéré comme la cause de l'orage, c'est que : soit il donne l'essentiel de l'énergie au système et il est alors l'élément constituant de ce système, soit il en est l'unique (ou du moins principal) élément déclencheur.
L'étincelle dans un baril de poudre déclenche l'explosion en donnant, très localement, l'énergie nécéssaire pour que la réaction chimique d'explosion s'effectue, provoquant alors une réaction en chaine. S'il fallait balancer 10^beaucoup d'étincelles, en même temps, dans un baril de poudre pour voir une explosion, il serait ridicule de pointer une étincelle en particulier et de dire : "c'est elle la cause de l'explosion".
Or c'est bien ce que l'on fait là, puisqu'à défaut d'avoir une énergie suffisante, le battement d'aile se veut LA perturbation qui a tout déchainé (pas une, LA, sinon elle n'en serait pas responsable mais tout juste complice :) ).
3 nov. 2007 à 01:28
les ordinateurs Xerox de la génération 6085 qui possèdent des facultés de calculs bien supérieures aux Intel et aux AMD possèdent des instructions dîtes 'bas niveau', dans un language proche de l'assembleur (XDE), qui se réfèrent à la recherche documentaire, et qui ressemblent à : Find the document whose name is.... !
Quand on voit cela, et que l'on sait ce qu'est une instruction assembleur, on rigole rapidement du C...
Xerox invente la souris en 1969 et le langage C apparaît en 1972, C++ en 1980... 3 normes ANSI plus tard, (a+b)+c est toujours différent de a+(b+c), sauf dans mon TSolverObject écrit en Delphi...
Mais bon, j'aime bien dBase aussi...
3 nov. 2007 à 01:18
pourquoi crois-tu que la programmation en C++ est plus répandue aujourd'hui ? simplement parcequ'elle est plus efficace en terme de temps de développement et donc plus rentable, tout comme le C#.net qui a des perfs encore pires que le C++ mais qui permet de créer une application plus rapidement
un exemple : une application développée en Win32, tu écris la même en MFC en moitié moins de temps, rien que le fait d'avoir moins de code à taper
ce qui intéresse les boites de développement c'est la rentabilité, et si ça doit passer par la perte de performances pour accélérer le développement ils évolueront vers un langage qui leur permettra de faire ces économies, et c'est actuellement le cas avec le C++
je suis un développeur C à l'origine, et j'ai trouvé dans le C++ des possibilités de développement plus larges et surtout pouvoir créer des objets réutilisables qui me permet un gain de temps non néglibeable lorsque je veux faire évoluer une application ou la réécrire
3 nov. 2007 à 01:16
3 nov. 2007 à 00:57
"le battement d'aile du papillon ne PEUT PAS être responsable de l'accumulation totale d'énergie que requiert la création d'un orage"
=> c'est quoi cette remarque ? heureusement que la cause ne doit pas systématiquement fournir l'énergie de l'effet... Aux dernières nouvelles, l'orage et le papillon ne forment pas un système fermé.
Mais l'image de l'effet du papillon sur l'ouragan, EST une image :) Les mathématiques réservent quand meme des surprises, notamment avec ces foutus éq diffs non linéaires... mais c'est clair que l'image du papillon est volontairement un peu exagéré.
Metanil:
"quantième de seconde que permets d'économiser tel ou tel code"
=> Tout a fait d'accord. Perso, je pense que je serais encore plus radical que ce que tu exprimes, c'est pourquoi je ne dis rien :)
2 nov. 2007 à 22:53
pas de grandes "choses" en plus... la preuve, toutes mes
sources sont en C...
2 nov. 2007 à 21:59
je ne rentrerai pas dans le débat C/C++ mais n'oubliez pas 2 choses :
1 - le C++ est une évolution du C dont il reprend tous les fondements y compris les pointeurs
le C est plus bas niveau, logique qu'il soit plus rapide
à condition d'utiliser un compilateur C
2 - rappelez moi sur quel site nous sommes ? cppfrance... cpp ça veux dire quoi ?
allez, un peu de tolérance, je trouve que les programmeurs qui font de l'assembleur sont des fous, mais si ça leur plait de programmer 100 fois plus lentement qu'un développeur C++ alors laissez les faire des programmes 100 fois plus rapides ;-)
ps : le système de notation est à revoir, obligé de commenter et si on oublie de noter on peux pas EDITER, si on pouvait éditer un commentaire ça arrangerai tout ;-)
2 nov. 2007 à 20:45
10/10
2 nov. 2007 à 20:43
*********************************************
PTDR pour le papillon!
Il a des ailes de 50 km ou quoi?
Donc je peux affirmer que la supernova située a 5 milliards d'AL qui a pété la veille aura une influence sur la tasse de café que je prendrai le lendemain.
Ben oui, mathématiquement ce n'est pas nul... (mais physiquement ça l'est : vitesse(information)<=c).
MDR ! Bon, faut arreter de croire tout et n'importe quoi !
2 nov. 2007 à 19:41
2 nov. 2007 à 19:37
>> JCDJCD : nous allons finir par nous entendre !
En fait, les papillons sont loin de nous prouver qu'ils savent jongler avec les octets... Moi j'ai commencé par le C++, et j'ai de ce fait acquis des notions en C, mais il est vrai que je peaufine plus ma gestion de remontée et de propagation des changements au travers de l'Univers (de mes objets) que du quantième de seconde que permets d'économiser tel ou tel code... Il fallut de tout pour faire un monde...
metanil@hotmail.com (MSN Messenger)
2 nov. 2007 à 18:32
2 nov. 2007 à 18:24
et pas aux autres papillons, pas aux autres insectes, pas aux
autres animaux, par aux hommes qui se mouchent, pas aux
cyclistes, pas aux voitures, pas aux industries, et surtout
pas a l'evaporation de l'eau dans les oceans due au soleil
qui est conditionnee par une constante : la chaleur latente
de l'eau... bref tout ca pour dire qu'il y a d'autres facteurs
veritablement significatifs !
Donc oublions pour toujours ce papillon...
On en parlera le jour ou tout sera statique SAUF ce papillon,
ce qui est loin d'etre le cas !
2 nov. 2007 à 17:57
2) Que construire sur le parfait ?
3) bof, ça détends... et puis la guerre est utile pour l'Evolution, à moins que le C ne soit stagnant ...?
lol
(de toutes façons je bosse actuellement sur du Delphi...)
2 nov. 2007 à 17:53
Chapeau, METANIL, à défaut d'avoir été vraiment constructif sur le sujet initial, tu as réussis à construire, en quelques posts, une véritable confiture de délires, toujours recommencés mais jamais tout-à-fait semblables. On dirait presque du Beckett!
Plus sérieusement, j'aimerais revenir sur ce que dit JCDjcd et qui n'a rien à voir avec l'informatique (ou presque). Affirmer que le battement d'aile du papillon provoquera un orage à NY est à la fois, mathématiquement vrai, mais physiquement faux et intellectuellement d'une stupidité incroyable. Comme l'a dit JCDjcd, en physique 10^-80=0 et le égal n'est pas un a peu près...
Ce battement d'aile déséquilibrera peut-être une portion ridicule de masse d'air, qui le fera à son tour sur une autre, le tout sur un temps très long, exploitant au maximum la théorie des systèmes chaotiques qui dit que d'un même état, selon d'infimes perturbations, on peut arriver à des systèmes radicalement divergeant. (pour la petite histoire cependant, les phénomènes statistiques du type météo ne m'apparaissent pas vraiment chaotiques mais plutôt régularisants, lissant les perturbations en permanence, mais bon, on va faire comme si...)
Mais, et alors que JCDjcd a déjà expliqué pourquoi en terme de probabilité et de sens physique c'était stupide, en terme, maintenant, d'énergie (pour que chacun comprenne où se situe l'argument physique de la chose), le battement d'aile du papillon ne PEUT PAS être responsable de l'accumulation totale d'énergie que requiert la création d'un orage, vu que celle-ci dépasse de très très très loin l'énergie de ce battement.
De plus, ça ne coûte rien de dire "Tout influence tout, il ne faut rien négliger!", mais c'est, d'un point de vue scientifique risible tant c'est naïf et improductif.
2 nov. 2007 à 17:08
2 nov. 2007 à 17:05
tu es abuse par ce que l'on te dit, et tu acceptes un peu trop
facilement les arguments d'autorite...
allons un peu de sens physique ! effectivement la correlation
entre un battement d'aile d'un papillon et des orages a NY
n'est pas rigoureusement nulle, cependant tres proche de zero,
mais en dessous d'un certain seuil (par exemple probabilite
inferieure a 10^-80=#atomes dans l'univers) on peut considerer
que les deux evenements sont independants : je te renvoie a un
illustre personnage, plus connu que James Gleick, plus savant
c'est certain, (et que j'aime plus voila tout), le fameux
Emile Borel... alors si tu veux philosopher pas de probleme...
ce pape de la notion de probabilite ecrit :
"les événements de probabilité suffisamment petite ne se produisent jamais"
bref... tu te renseigneras dessus !
le truc c'est que le lien de cause a effet n'a pas celui auquel
tu crois, car il n'y a pas seulement le papillon qui influe,
c'est vraiment un goutte dans un ocean...
l'orage aura dans tout les cas lieu, mais le papillon ne va
pas influer sur l'orage lui meme (echelle aerologique ou
mesoechelle si tu fais un peu de meteorologie...), par contre
peut etre que telle molecule n'aura pas sensiblement la meme
vitesse a cause du papillon (echelle miscroscopique)... mais rien
a voir avec l'orage lui-meme !
faut arreter de croire tout ce que l'on vous dit,
UN PEU DE BON SENS !!!
si vous soufflez sur une toupie, alors la toupie va continuer
de tourner, mais un peu differemment que si vous n'aviez pas soufflez,
mais il faut dire que globalement le souffle n'a aucune incidence,
tout comme le papillon sur l'orage...
et ca ne sert a rien de me dire que strico sensus, le papillon
a un impact sur l'orage, je suis assez grand pour comprendre le
pourquoi de cette affirmation, et que le debat n'est pas la !
2 nov. 2007 à 16:40
Malgré tous mes commentaires, je tiens quand même à te dédicacer une parole de James Gleick (fondateur de la théorie du Chaos) : "Le battement d'ail d'un papillion à Tokyo peut provoquer des orages à New York"...
2 nov. 2007 à 16:39
Non tu n'aimes pas être impoli... Purtant tu n'as pas suivi tout le débat qui commence avec une autre source, sur le même site....
Au fait, un sous-homme, ça se trouve en dessous d'un homme. Moi je n'ai que mon clavier en dessous, comme TOUS les programmeurs...
On doit à mon avis pouvoir qualifier et quantifier un language (L3G L4G), mais pas l'Homme.
S'il te plaît...
A moins que tu ne sois une femme... :-)
2 nov. 2007 à 16:37
alors faut faire attention, quand on somme, la somme courante peut alors un
moment depasse un des termes, donc il faut retrier a chaque coup les termes
(ce que je fais dans l'algorithme)
on doit commencer par sommer les petites valeurs car leur somme peut etre comparable
aux grandes valeurs, donc on aura modifier la somme suivant l'ordre de sommation,
il faut biensur faire cela dans ce sens, et non dans l'autre...logique !
j'ai eu le meme probleme dans mon "N body problem", je suis parti d'un situation
symetrique, et au bout d'un certain temps, la symetrie a ete rompue a cause de
l'instabilite numerique
2 nov. 2007 à 16:27
qui ont la plus petite valeur absolue...
Tu veux dire que la bonne méthode est de commencer par sommer les plus petites valeurs ? Cela semble logique, car cela réduit le risque de perdre des décimales lors de l'addition de 2 flottants trop différents.
J'ai été confronté à ce problème avec un simulateur de gravité ayant des symétries : les symétries doivent se compenser mais au bout d'un moment la perte de précision entraine le chaos (voir ma source Gravity).
2 nov. 2007 à 16:09
Très bonne source sinon, très instructive.
1 nov. 2007 à 22:16
no comment
...
1 nov. 2007 à 22:07
On ne va pas plus vite en C++ qu'en C, mais ce que l'on doit faire, on le fait plus facilement...
En ce qui concerne la précision, je crois que le modèle objet est plus qualifié que les langages de génération moindre comme le C ou le Pascal, tous dépendants de l'OS et/ou du microprocesseur.
Quand au rapport rapidité/qualité, le débat à déjà permis à l'ANSI d'établir plus qu'une norme, mais 2 : ce qui nous montre la précarité de l'existant...
Un tien vaut mieux que 2 tu l'auras !
1 nov. 2007 à 21:57
1 nov. 2007 à 21:53
Au fait, pour mon TPaintbox 3D, ça vient...
1 nov. 2007 à 21:50
La généricité va à l'encontre de rapidité, c'est en descendant au plus près du matériel qu'on obtient les perfs maximales. Les flottants sont justement le meilleur exemple, en ASM on atomise encore les perfs du C en employant SSE.
1 nov. 2007 à 21:49
1 nov. 2007 à 21:35
1 nov. 2007 à 21:31
elle est bonne celle la !!
mais monsieur le C est beaucoup plus rapide que le C++, il est plus
sobre et la surcharge implique inevitablement un cout temporel,
alors la je suis certain que le C explose les algorithmes C++ !!
et je ne parle meme pas de la taille des programmes .exe ...
et au passage que ca soit en C ou en C++ je suis desole mais le
probleme reste le meme, il est INTRINSEQUE a l'additionneur
de flottant de nos co-processeurs flottants !
meme en C++ : (a+b)+c n'est pas a+(b+c)
1 nov. 2007 à 21:19
On peut pas blamer les gens de jouer avec les autres chiffres... De là à en arriver aux Nombres...
Le domaine du Jeu vous doit beaucoup, à Vous, les programmeurs de l'Enfer du C et de ses pointeurs, mais nous, au service C++, on s'amuse à surclasser...
Vous ne nous devez ni la rapidité, ni la simplicité : nous vous l'apportons...
J'aime pas ne pas être constructif, alors je me permettais d'élever le débat de tout programmeur C vers l'aspect généricité du C++ (d'un intérêt primordial en Simulation) : si on doit additionner différemment 1+0 et 1.0+0, où va-t-on ?
1 nov. 2007 à 20:37
Sinon très jolie simulation encore, bravo.
1 nov. 2007 à 20:34
Ce qui est amusant c'est surtout le passage fulgurant d'un état où les calculs sont absolument équivalent, à un état ou ils diffèrent du tout au tout. Espérons que le CNES a une idée de ce que c'est que la stabilité numérique, sinon on est mal barré! :)