AccueilCodesTutorielsForumsEmploiLivresConnexion

  • C / C++ / C++.NET CodeS-SourceS
  • RSS CodeS-SourceS
  • CodyxBot, le Bot GTalk & MSN qu'il vous faut !
  • Générez des revenus avec vos codes, scripts et tutoriaux
  • Aide à la navigation du site
begin process at 2008 11 22 22:23:44
Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

ORDRE DE SOMMATION DES FLOTTANTS (EXEMPLE PAR SIMULATION)


Information sur la source

Catégorie :Maths & Algorithmes Classé sous : double, flottant, sommation, ordre, arrondis Niveau : Débutant Date de création : 01/11/2007 Vu / téléchargé: 1 612 / 71
Auteur : JCDjcd Ecrire un message privé
Ce membre participe au partage de revenus publicitaires
Note :
8,6 / 10 - par 5 personnes
8,60 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Commentaire sur cette source (45)
Ajouter un commentaire et/ou une note

Description

Cliquez pour voir la capture en taille normale
Qui a dit que l'ordre de sommation est flottant n'importait pas ??
Voici un petit simulation vous devrait vous convaincre du contraire !

La simulation est la suivante : il y a des masses dans une "arene",
delimitee par un petit cercle, la dedans les masses ne subissent
aucune force exterieures, mais interagissent entre elles suivant
des forces repulsives en 1/r^2 (types gravitationnelles) et des forces
attractives en r^1 (types elastiques), et en dehors de ce cercle
interieur, une force qui derive d'un potentiel et qui a tendance
a ramener toute particule qui sort du cercle dans celui-ci
c'est en gros un "mur" circulaire, pour plus d'information voir
ma source precedente (simulation d'un rebond sur un mur)

Bref tout ceci pour simuler une "bouillie" de forces...

La subtilite de cette source est que je presente deux simulations :
il y a plein de forces, et je dois calculer leur somme
(puisque le principe fondamental de la dynamique stipule de masse fois
acceleration egale somme des forces)
Mais la sommation ne se fait pas de la meme maniere dans les deux
simulations... certains diront que ca n'a pas d'importance... que nenni !
il y a une bonne et une mauvaise maniere de sommer des flottants, la preuve :
les deux situations pourtant initialement identiques dans leur description
divergent au bout de quelques secondes (cf capture d'ecran, les boules rouges
sont censees toujours etre exactement sous les vertes)

La bonne methode pour sommer est de toujours sommer les deux quantitees
qui ont la plus petite valeur absolue...

Ne chipotez pas !! un jour si vous voulez faire une simulation d'une galaxie,
alors vous aurez besoin de sommer des forces et vous aurez ce probleme de
stabilite numerique...

De plus la simulation en soi est tres amusante non ? elle correspond a rien du tout
mais ca fait jolie a voir evoluer...

Convaincu(e) ?
 

Source

  • //-------------------------------------------------
  • double funcSumStupid(double *p,int n)
  • {
  • double sum;
  • int k;
  • sum = 0.;
  • // algorithme stupide, on somme dans l'ordre que l'on nous a donne les valeurs
  • for(k=0;k<n;k++)
  • {
  • sum += p[k];
  • }
  • return sum;
  • }
  • //----------------------------------------------------------
  • int cmpDouble(void *key1,void *key2,void *param)
  • {
  • double a,b;
  • UNUSED_PARAMETER(param);
  • a = fabs(*(double*)key1);
  • b = fabs(*(double*)key2);
  • if(a > b) return CMP_MORE;
  • else if(a < b) return CMP_LESS;
  • else return CMP_EQUAL;
  • } // cmpDouble()
  • //-------------------------------------------------
  • double funcSumNotStupid(double *p,int n)
  • {
  • int k;
  • // on trie les nombres par ordre croissant de leur valeur absolue
  • QuickSortArray(double,p,n,cmpDouble,NULL);
  • for(k=0;k<n-1;k++)
  • {
  • int i;
  • p[k+1] += p[k]; // on somme les deux plus petits ...
  • i = k+1;
  • // ... puis on fait remonter cette somme a sa bonne place
  • // pour que les valeurs soient toujours triees selon
  • // leur valeur absolue
  • while(i < n-1 && fabs(p[i]) > fabs(p[i+1]))
  • {
  • SwapDouble(p+i,p+i+1);
  • i ++;
  • }
  • }
  • // la somme calculee telle que l'on a minimise les erreurs d'arrondis
  • return p[n-1];
  • } 
//-------------------------------------------------
double funcSumStupid(double *p,int n)
{
double  sum;
int     k;

sum = 0.;
// algorithme stupide, on somme dans l'ordre que l'on nous a donne les valeurs
for(k=0;k<n;k++)
  {
  sum += p[k];
  }

return sum;
}

//----------------------------------------------------------
int cmpDouble(void *key1,void *key2,void *param)
{
double a,b;

UNUSED_PARAMETER(param);

a = fabs(*(double*)key1);
b = fabs(*(double*)key2);

if(a > b)       return CMP_MORE;
else if(a < b)  return CMP_LESS;
else            return CMP_EQUAL;
} // cmpDouble()

//-------------------------------------------------
double funcSumNotStupid(double *p,int n)
{
int     k;

// on trie les nombres par ordre croissant de leur valeur absolue
QuickSortArray(double,p,n,cmpDouble,NULL);

for(k=0;k<n-1;k++)
  {
  int i;
  p[k+1] += p[k]; // on somme les deux plus petits ...
  i = k+1;
  // ... puis on fait remonter cette somme a sa bonne place
  // pour que les valeurs soient toujours triees selon
  // leur valeur absolue
  while(i < n-1 && fabs(p[i]) > fabs(p[i+1]))
    {
    SwapDouble(p+i,p+i+1);
    i ++;
    }
  }
// la somme calculee telle que l'on a minimise les erreurs d'arrondis
return p[n-1];
}

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip

Commentaires et avis

signaler à un administrateur
Commentaire de The Incredible Godzy le 01/11/2007 20:34:46 8/10

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é! :)

signaler à un administrateur
Commentaire de juju12 le 01/11/2007 20:37:45 9/10

The Incredible, t'inquiète, ils font que ca des calculs de stabilité :)
Sinon très jolie simulation encore, bravo.

signaler à un administrateur
Commentaire de metanil le 01/11/2007 21:19:26

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 ?

signaler à un administrateur
Commentaire de JCDjcd le 01/11/2007 21:31:53

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)

signaler à un administrateur
Commentaire de metanil le 01/11/2007 21:35:15

D'où l'utilisation de libraries spécialisées ... comme Math++

signaler à un administrateur
Commentaire de JCDjcd le 01/11/2007 21:49:08

c'est quoi Math++ ?? en quoi le probleme est resolu ?

signaler à un administrateur
Commentaire de BruNews le 01/11/2007 21:50:13 administrateur CS

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.

signaler à un administrateur
Commentaire de metanil le 01/11/2007 21:53:14

Yep

Au fait, pour mon TPaintbox 3D, ça vient...

signaler à un administrateur
Commentaire de The Incredible Godzy le 01/11/2007 21:57:30

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.

signaler à un administrateur
Commentaire de metanil le 01/11/2007 22:07:33

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 !

signaler à un administrateur
Commentaire de JCDjcd le 01/11/2007 22:16:09

...
no comment
...

signaler à un administrateur
Commentaire de Pamaury le 02/11/2007 16:09:43 8/10

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.

signaler à un administrateur
Commentaire de Patrice99 le 02/11/2007 16:27:06

> 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).

signaler à un administrateur
Commentaire de JCDjcd le 02/11/2007 16:37:27

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

signaler à un administrateur
Commentaire de metanil le 02/11/2007 16:39:10

>> 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... :-)

signaler à un administrateur
Commentaire de metanil le 02/11/2007 16:40:55

>> 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"...

signaler à un administrateur
Commentaire de JCDjcd le 02/11/2007 17:05:29

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 !

signaler à un administrateur
Commentaire de metanil le 02/11/2007 17:08:30

Je t'engagerais bien comme faiseur d'éclairs !

signaler à un administrateur
Commentaire de The Incredible Godzy le 02/11/2007 17:53:34

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.

signaler à un administrateur
Commentaire de metanil le 02/11/2007 17:57:48

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...)

signaler à un administrateur
Commentaire de JCDjcd le 02/11/2007 18:24:46

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 !

signaler à un administrateur
Commentaire de Pamaury le 02/11/2007 18:32:46

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 ?!

signaler à un administrateur
Commentaire de metanil le 02/11/2007 19:37:46

>>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)

signaler à un administrateur
Commentaire de JCDjcd le 02/11/2007 19:41:41

j'avoue que j'ai beaucoup de mal a te suivre...

signaler à un administrateur
Commentaire de algori le 02/11/2007 20:43:33

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 !

signaler à un administrateur
Commentaire de algori le 02/11/2007 20:45:18 10/10

Désolé, j'ai oublié de mettre la note !
10/10

signaler à un administrateur
Commentaire de shenron666 le 02/11/2007 21:59:55 8/10

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 ;-)

signaler à un administrateur
Commentaire de JCDjcd le 02/11/2007 22:53:52

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...

signaler à un administrateur
Commentaire de luhtor le 03/11/2007 00:57:07

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 :)

signaler à un administrateur
Commentaire de metanil le 03/11/2007 01:16:30

Conclusion : J'aime aussi les fous !

signaler à un administrateur
Commentaire de shenron666 le 03/11/2007 01:18:08

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

signaler à un administrateur
Commentaire de metanil le 03/11/2007 01:28:21

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...

signaler à un administrateur
Commentaire de The Incredible Godzy le 03/11/2007 01:42:32

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 :) ).

signaler à un administrateur
Commentaire de pgl10 le 03/11/2007 10:18:40

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.

signaler à un administrateur
Commentaire de pgl10 le 03/11/2007 11:48:09

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 !

signaler à un administrateur
Commentaire de JCDjcd le 03/11/2007 11:53:32

>>>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?)

signaler à un administrateur
Commentaire de Pamaury le 03/11/2007 12:12:21

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 :)

signaler à un administrateur
Commentaire de shenron666 le 03/11/2007 12:20:07

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

signaler à un administrateur
Commentaire de JCDjcd le 03/11/2007 12:36:55

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 !

signaler à un administrateur
Commentaire de omnia le 03/11/2007 12:51:54

ouah ^^ quel débat,

en tout cas la source est intéressante :p

signaler à un administrateur
Commentaire de metanil le 03/11/2007 23:28:43

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)...

signaler à un administrateur
Commentaire de JCDjcd le 04/11/2007 13:12:24

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

signaler à un administrateur
Commentaire de metanil le 04/11/2007 16:38:50

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...

signaler à un administrateur
Commentaire de BruNews le 04/11/2007 18:40:22 administrateur CS

"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.

signaler à un administrateur
Commentaire de metanil le 04/11/2007 18:43:11

ahahahahah !

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

(j'ai preque terminé mon TPaintBox 3D !)

Ajouter un commentaire

Discussions en rapport avec ce code source dans le forum

long double et VC++ [ par omi ] J'ai un leger probleme avec visual C++ 7.0 .N'y a t'il pas un moyen de lui faire accepter les long double car il les prend pour des double normaux cad Affichage décimal [ par couriousous ] Hello!Comment afficher une variable long double avec toutes ses décimales SANS la convertire au format double (perte de précision)???Merci!