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 !

166 commentaire(s) de Pistol_Pete sur des sources sur tout CodeS-SourceS

Le : 10/07/2009 11:50:02
Source : CONVERSION ENTIER-CHIFFRE ROMAIN; CHIFFRE ROMAIN-ENTIER
C'est sur, mais j'ai jamais dit que le VB était du beau code...


Le : 10/07/2009 10:03:34
Source : CONVERSION ENTIER-CHIFFRE ROMAIN; CHIFFRE ROMAIN-ENTIER
D'après ce que j'ai compris de la msdn, Str = Str1 + 50; marcherai en VB. En interne, (fonction de la surcharge de +), le 50 sera convertie en char* avec un itoa avant d'être concaténé à Str1.
A+


Le : 10/07/2009 09:40:44
Source : CONVERSION ENTIER-CHIFFRE ROMAIN; CHIFFRE ROMAIN-ENTIER
Merci Adeon, je ne connais rien en VB mais je viens de regarder sur la msdn, le & ne sert qu'à concaténer 2 strings, alors que le + peu concaténer des nombres. Donc effectivement en VB, il aurait mieux fallu le &.
En C++, je ne pense pas que l'opérateur & soit surchargé.
A+


Le : 10/07/2009 08:55:46
Source : CONVERSION ENTIER-CHIFFRE ROMAIN; CHIFFRE ROMAIN-ENTIER
Tout a fait d'accord avec toi Adeon, autant travailler directement avec des char*.

>>Ghuysman, j'ai pas compris ta remarque; En c++ c'est autorisé aussi de faire un '+'. Et c'est quoi le rapport avec le &? Tu l'utilises comment pour concaténer deux chaines?


Le : 10/07/2009 08:36:24
Source : CONVERSION ENTIER-CHIFFRE ROMAIN; CHIFFRE ROMAIN-ENTIER
>>Adeon
s étant un string et comme le + est surchargé pour la classe String, tu as tout à fait le droit de faire un s=s+"M".
A+


Le : 01/07/2009 11:11:03
Source : ALGORITHMES D'OPTIMISATION NON LINÉAIRE: DESCENTE DE GRADIENT, LM, BFGS, SIMPLEXE...
>PGL10 Effectivement au niveau de la stabilité la méthode Fletcher-Reeves avec relance périodique est très bonne.
Pour Shenron666, ces fonctions sont largement utilisé en chimie, en mécanique, en mathématique... en fait, presque toutes les disciplines.

Pour être concret, voici ma problématique; On sait que des particules d'un matériaux sont des parallélogrammes 3D. La problématique est de trouver la largeur, la longueur et l'épaisseur de ces particules: (L, l et e).
Ce sont donc mes trois paramètres que je vais optimiser par ces méthodes en minimisant une fonction "résidu" bien déterminé. Une fois la convergence atteinte, je connaitrais les paramètres optimaux (L*, l* et e*) de mes particules.





Le : 30/06/2009 11:32:05
Source : ALGORITHMES D'OPTIMISATION NON LINÉAIRE: DESCENTE DE GRADIENT, LM, BFGS, SIMPLEXE...
Après une petite recherche bibliographique, j'ai ajouté deux fonctions d'optimisation à mon programme :
La méthode de Fletcher-Reeves avec relance périodique (toutes les 2 itérations! ) et celle de Polack-Robière.(qui est juste une variante de Fletcher-Reeves).

Voici mes commentaires :
Ce sont deux méthodes très correctes, mais pas aussi bien que la méthode BFGS. D'ailleurs Fletcher-Reeves date de 1964 et la méthode BFGS de 1970. Le F de BFGS est pour ... Fletcher!

La méthode BFGS est donc une amélioration de la méthode de Fletcher-Reeves.


Le : 30/06/2009 08:19:48
Source : ALGORITHMES D'OPTIMISATION NON LINÉAIRE: DESCENTE DE GRADIENT, LM, BFGS, SIMPLEXE...
Bonjour PGL10
Merci de ton commentaire. Effectivement, je voulais faire une navigation sur les courbes la plus intuitif possible. Je pense y être arrivé avec une IHM style google Maps.

Pour la méthode de Fletcher et Reeves, je ne connaissais pas, mais je vais la regarder et surement faire une petite update de cette source...


Le : 26/06/2009 14:37:05
Source : CLASSE GRAPH: GESTION DES GRAPHIQUES DANS LES APPLICATIONS WIN32
Merci Shorzy!


Le : 03/06/2009 09:07:36
Source : CLASSE GRAPH: GESTION DES GRAPHIQUES DANS LES APPLICATIONS WIN32
Salut
Merci de ton message. Oui effectivement je vois de ce que tu parles pour le trait verticale. Je corrigerai cela à l'occasion.

Pour le double buffering, je procède comme tu l'as évoqué. Je le crée une unique fois dans le WM_CREATE. C'est effectivement bien plus rapide que de le créer à chaque WM_PAINT. Cependant, la contre partie est de créer un double buffer qui est de taille fixe. Aussi pour certaine configuration d'écran (forte résolution), il est possible que le double buffer ne soit pas assez grand.
Je pense qu'une solution serait de récréer le double buffer de la taille de la fenêtre dans le WM_SIZE mais après quelques tests où je redimensionne beaucoup la fenêtre , il s'avère que la création du buffer échoue... Je ne sais pas encore à quoi cela est du.

A+



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Comparez les prix Nouvelle version

Photothèque Nouveau !



Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,203 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.