ORDRE DE SOMMATION DES FLOTTANTS (EXEMPLE PAR SIMULATION)

Signaler
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008
-
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007
-
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

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 !)
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
20
"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.
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...
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
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
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)...
Messages postés
240
Date d'inscription
jeudi 9 janvier 2003
Statut
Membre
Dernière intervention
22 mars 2009

ouah ^^ quel débat,

en tout cas la source est intéressante :p
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
je travaille avec VisualStudioC++ ...
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 !
Messages postés
229
Date d'inscription
dimanche 14 septembre 2003
Statut
Membre
Dernière intervention
20 août 2014

les classes sont des structures avec despropriétés évoluées
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
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
2
Il me semble, quoi qu'on en dise mais c'est un avis personnel, que le C++ permet d'avoir une structure plus apparente, je ne dis pas que cela donne un code plus structuré, je dis juste que cette structure, de part sa syntaxe notamment, est souvent plus claire. Par exemple, il y a pas mal de cas où l'héritage est très utile en C++ et dans ces cas, la hiérarchie des classes apparait clairement. Si l'on veut faire le même code en C, bien sûr on va y arrivé mais ce sera moins lisible. Et on peut trouver plein d'autres exemples.

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 :)
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
>>>shenron666 :
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?)
Messages postés
313
Date d'inscription
samedi 18 décembre 2004
Statut
Membre
Dernière intervention
26 mai 2020
2
Le fonctionnement interne de l'unité arithmétique pour les nombres flottants, à l'intérieur de l'unité centrale, dont on parle ici, est bien évidemment complètement indépendant du langage de programmation utilisé. On peut donc observer ce fonctionnement, qui ne devrait pas surpendre, aussi bien en Assembleur, qu'en C, C++, Fortran, Cobol ou tout autre langage.
Que ceux qui le souhaitent l'essayent et ils verront !
Messages postés
313
Date d'inscription
samedi 18 décembre 2004
Statut
Membre
Dernière intervention
26 mai 2020
2
Je suis bien heureux de retrouver ici des informations bien connues depuis longtemps. Deux experts :
- 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.
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008

Luhtor >> je n'ai pas dit que la cause devait fournir l'énergie totale du système...
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 :) ).
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

Pour info :

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...
Messages postés
229
Date d'inscription
dimanche 14 septembre 2003
Statut
Membre
Dernière intervention
20 août 2014

JCDjcd > programmer en C++ permet de bien plus structurer son programme, c'est le côté objet apporté par le C++ qui le permet, et qui fait gagner du temps dans le processus de développement

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
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

Conclusion : J'aime aussi les fous !
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
5
The Incredible Godzy :
"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 :)
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
mais a la difference avec l'assembleur, programmer en C++ n'est pas plus rapide que programmer en C... et on ne fait
pas de grandes "choses" en plus... la preuve, toutes mes
sources sont en C...
Messages postés
229
Date d'inscription
dimanche 14 septembre 2003
Statut
Membre
Dernière intervention
20 août 2014

source intéressante, c'est une question de logique quand on sait comment est codé un réel

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 ;-)
Messages postés
868
Date d'inscription
dimanche 26 décembre 2004
Statut
Membre
Dernière intervention
26 février 2008
1
Désolé, j'ai oublié de mettre la note !
10/10
Messages postés
868
Date d'inscription
dimanche 26 décembre 2004
Statut
Membre
Dernière intervention
26 février 2008
1
Source remarquable !


*********************************************
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 !
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
j'avoue que j'ai beaucoup de mal a te suivre...
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

>>PAUMARY : le plus bête dans l'histoire, c'est que ma femme m'ennuie moins que toi ... @+

>> 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)
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
2
METANIL: visiblement tu n'a pas compris ma remarque, j'ai bien compris(je ne suis pas encore bête ou du moins je ne crois pas) que le début du débat était ailleurs mais justement le problème est que l'on fini un débat là où il commence et pas n'importe où ailleurs sans préciser où est le début, sinon imagine le bordel que cela cause à la lecture des commentaires d'un post ?!
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
tout le probleme est que l'on s'interesse trop a ce papillon,
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 !
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

1) T'inquiètes, le type est mort depuis longtemps....
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...)
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008

La cohérence de la discussion est un peu du même ordre que celle entre plusieurs personnes complètement bourrées... On est passé d'un problème de stabilité numérique, à une discussion sur kicéképluforkeki, en passant par un délire sur les grands nombre, et maintenant ça philosophe (doucement quand même) sur les probabilités infimes...

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.
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

Je t'engagerais bien comme faiseur d'éclairs !
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
c'est completement FAUX, ca c'est de la propagande...
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 !
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

>> JCDjcd

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"...
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

>> PAUMAURY

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... :-)
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
oui on commence par les plus proches de zeros, et on termine par le plus grand,
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
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018

> La bonne methode pour sommer est de toujours sommer les deux quantitees
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).
Messages postés
341
Date d'inscription
jeudi 3 avril 2003
Statut
Membre
Dernière intervention
17 juin 2008
2
METANIL, j'aime pas être ne pas être poli, alors je me permettrais d'élever le débat encore un peu plus: à quoi sert ta remarque ? Tu viens embéter le monde avec ton stupide débat C/C++ alors qu'il n'en ai pas même question et tout çà pour quoi, pour faire parler; si tu considère les programmeurs C comme sous-hommes vient pas poster ici et trouve toi un site C++-only.
Très bonne source sinon, très instructive.
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
...
no comment
...
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

On en revient à mon intervention sur le 0 et le 1 (c'est à dire le LM).

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 !
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008

METANIL > Je ne connais vraiment que le C, et pas le C++, mais je vois mal comment, en partant d'un langage plus générique, tu peux aller plus vite qu'un langage qui est justement plus chiant (et encore...) parceque plus précis dans ses opérations? Après tout le langage qui permet d'aller plus vite que tous les autres c'est le langage machine qui te permet la précision ultime. Après, on peut se simplifier la vie (et heureusement), mais on la complique souvent à l'ordinateur au passage. Enfin, ce n'est que mon avis.
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

Yep

Au fait, pour mon TPaintbox 3D, ça vient...
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
20
METANIL, je te sens fatigué...
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.
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
c'est quoi Math++ ?? en quoi le probleme est resolu ?
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

D'où l'utilisation de libraries spécialisées ... comme Math++
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
3
non mais laissez moi rire un peu la, faut que je m'en remette !
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)
Messages postés
51
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
13 novembre 2007

Faut me comprendre : tous les problèmes se traitent en informatique avec des 0 et des 1...

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 ?
Messages postés
966
Date d'inscription
samedi 3 avril 2004
Statut
Membre
Dernière intervention
4 mars 2010
4
The Incredible, t'inquiète, ils font que ca des calculs de stabilité :)
Sinon très jolie simulation encore, bravo.
Messages postés
10
Date d'inscription
mardi 8 mai 2007
Statut
Membre
Dernière intervention
29 septembre 2008

Le second calcul fait peur pour sa complexité en O(n²), mais l'exemple est édifiant!
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é! :)