[Débutante]Programmation de la méthode de Jacobi

bonjour,

j'ai a réaliser la methode de JACOBI pour la résolution d'un système d'équations, que me conseillez vous d'utiliser, java ou bien c++Builder??

merci d'avance.

À chaque fois qu'on me demande "avec quel langage tu ferais ça", je réponds quasiment toujours java... Là c'est possible en Java...

Par contre, pour tout ce qui est calcul / résolution, dans ce cas je conseillerais C.

Bon souvent de tels algos sont faits en FORTRAN, mais c'est horrible, et je ne trouve aucun avantage à ce language qui date de 66 destiné à programmer avec des papiers à trous (bon le dernier date de 90, mais quelle évolution, maintenant on peut écrire sans compter le nombre d'espaces, super ! lol).

Il y a certes des différences de performances au niveau de l'exécution de Java et de C/C++ mais quand on a affaire à un code propre et bien pensé Java étale du C/C++ dégueulasse... :mouarf:

Rapidos, sur Google j'ai trouvé cet article dont la conclusion confirme que la différence de performances est de + en +, ou effectivement, insignifiante. Et il date de 2003... Et Java a évolué encore depuis.

Je répondrais bien Java, parce que c'est tellement plus clair, simple, propre et... standard.

Citation:

Il y a certes des différences de performances au niveau de l'exécution de Java et de C/C++ mais quand on a affaire à un code propre et bien pensé Java étale du C/C++ dégueulasse..

il est vrai que
Code:

1 2 3 4 5 6 7 8 int main () { int j = 0; for (int i = 0; i < 10000000; i++) { j++; } return 0; }
ca se fait eclater par
Code:

1 2 3 4 5 6 .... public static void main (String[] args) { return 0 } ...
mais ce que tu dis est plutot independant du langage : un mauvais algo ou un mauvais design sera plus lent qu'un bon algo ou un bon design. merci, mais ca se rapproche d'une tautologie ca :mrgreen:

Perso, si je dois faire un truc lié aux maths, je ne prends pas java tout simplement parce que j'adore par dessus tout avoir des lignes de code qui ressemblent aux equations que j'ai à coder, et pour ca il faut pouvoir redéfinir les operateurs....

parce que
Code:

1 2 3 4 5 6 7 8 9 10 /* tiré du code de pbrt, cf pbrt.org */ Spectrum FrCond(float cosi, const Spectrum &eta, const Spectrum &k) { Spectrum tmp = (eta*eta + k*k) * cosi*cosi; Spectrum Rparl2 = (tmp - (2.f * eta * cosi) + 1) / (tmp + (2.f * eta * cosi) + 1); Spectrum tmp_f = eta*eta + k*k; Spectrum Rperp2 = (tmp_f - (2.f * eta * cosi) + cosi*cosi) / (tmp_f + (2.f * eta * cosi) + cosi*cosi); return (Rparl2 + Rperp2) / 2.f; }
c'est quand meme mieux que :
Code:

1 2 3 4 5 6 7 8 Spectrum frCond(float cosi, Spectrum eta, Spectrum k) { Spectrum tmp = eta.multiplyWith (eta).add (k.multiplyWith(k)).multiplyScalar (cosi*cosi); Spectrum Rparl2 = (tmp.substract ((eta.multiplyScalar (2 * cosi).oppose.addScalar (1)))).divideBy((tmp.add (eta.multiplyWith (2 * cosi).addScalar (1)))); Spectrum tmp_f = eta.multiplyWith (eta).addScalar (k.multiplyWith(k)); Spectrum Rperp2 = (tmp_f.substract ((eta.multiplyWith (2 * cosi).addScalar (cosi*cosi)))).divideBy(tmp_f.add (eta.multiplyWith (2.f * cosi).addScalar (cosi*cosi))); return (Rparl2.add (Rperp2)).divideByScalar (2); }
Bon, après j'ai peut etre des gouts de m*** et peut etre que la version java est mieux hein, mais à vue de nez, je sais pas pourquoi mais je préfère la premiere :mrgreen: . Cela dit et pour etre impartial, même dans la version C++ il y a des défauts, genre le + entre un objet de type Spectrum et un scalaire. Cela dit j'utilise un langage qui permet d'éviter ce genre de cochonneries en permettant de créer de nouveaux sigles pour les opérateurs, donc j'ai et les lignes de codes qui sont lisibles et des opérateurs qui montrent bien les nuances qui pourraient nous échapper si on lit trop vite.

avis personnel :
Donc Java, c'est bien pour des applis non scientifiques et pour lesquelles on souhaite une portabilité exemplaire sans recompilation ou pour des applis pas trop grosses. Hors de ce cadre, soit je trouve ca illisible (me dites pas que le code juste au dessus, et qui est une simple traduction, est lisible, il faut 5 minutes pour voir ce que ca calcule), soit je trouve ca lent (eclipse, meme si c'est un excellent soft, est un soft qui est plutot lourd comparé à d'autres IDE de même ampleur). Le C/C++ a des défauts aussi (comme par exemple le fait de pouvoir faire du code particulièrement dégueu en jouant avec les pointeurs), mais on peut aussi ecrire des progs clean en utilisant la STL.

Perso je code en lisaac (le langage évoqué un peu au-dessus), qui est certes peu connu car très jeune, mais qui a l'immense avantage de permettre tout ce que le C++ permet et bien plus, sans pouvoir faire du code imbuvable à cause de pointeurs se baladant partout, avec une gestion memoire faite à la compilation (en fait le code est analysé puis transformé en C, avec des techniques de gestion de memoire qui , je suppose, doivent etre proche de l'allocation d'un gros bloc, un peu comme le fait le GC si on en croit l'article). En plus, rien n'est défini en dur en lisaac, ce qui permet de se créer ses propres structures de controle et autres itérateurs specialisés, au prix d'une syntaxe un peu changée de la syntaxe habituelle "C-like", mais qui ne perd en rien en lisibilité.

Après, et je pense que c'est un point essentiel qui mettrait fin aux trolls incessants, il faut trouver le langage (et plus generalement le logiciel) qui nous correspond le plus et qui permet de repondre à nos attentes le mieux possible, et accepter que les autres n'utilisent pas le meme langage que nous (et moi il vaut mieux que je le fasse, je dois etre un des seuls à des kilometres à la ronde à utiliser lisaac :mrgreen: ). Pour l'instant, ce n'est pas java pour moi, tout simplement parce que je m'oriente vers de la programmation à but plutot calculatoire. mais si je dois faire une appli de gestion ou un truc dans le genre, il est certain que je me tournerais vers lui.
Mais ce n'est pas pour autant que les débats mettant en évidence les qualités et les défauts de tel ou tel langage ou approche sont ininteressants. Ils ne le sont que si les interlocuteurs ne sont par impartials et restent campés sur leur position en faisant mine de ne pas voir les arguments des autres personnes.

Héhé, oui, si on pouvait re/définir les opérateurs en Java ça serait chouette ! :]

Sinon pour ta totologie, merci... :aie: Je disais ça car certains détracteurs de Java codent comme des pieds et ont tendance à penser que quoiqu'il advienne le C (ou autre) vaincra. Mwahaha ! :mouarf: