Cherche un peu sur le net mais ça doit exister un générateur de courbe.
Cherche un peu sur le net mais ça doit exister un générateur de courbe.
On m’appelle ? Doom³ en JS ?
une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
Canard lecture
RDJ:
Au début j'avais ça. Notez les multiples appels à population.get_members().at(k)
"Mais pourquoi quand je double la taille de members le temps que prend distribute charge part à l'infini ???Code:void Pic::distribute_charge(bool export_charge){ dealii::MappingQ1<2,2> mapping ; std::vector<dealii::types::global_dof_index> local_dof_indices (fe.dofs_per_cell); for (unsigned int k=0; k!= population.get_members().size(); ++k){ std::vector< dealii::Point< 2 > > par_loc; if((e_o_i==true && population.get_members().at(k)->get_name()=='e') ||population.get_members().at(k)->get_name()=='i'){ par_loc.push_back(population.get_members().at(k)->get_pos()); dealii::Point <2> projection (mapping.transform_real_to_unit_cell(population.get_members().at(k)->get_current_cell(),population.get_members().at(k)->get_pos())); dealii::Quadrature<2> quad (projection); dealii::FEValues<2> fval(mapping,fe,quad,dealii::update_values); fval.reinit(population.get_members().at(k)->get_current_cell()); std::vector<dealii::types::global_dof_index> local_dof_indices (fe.dofs_per_cell); population.get_members().at(k)->get_current_cell()->get_dof_indices (local_dof_indices); for(unsigned int j=0; j<fe.dofs_per_cell;++j){ for(unsigned int q=0;q<quad.size();++q){ charge_distribution[local_dof_indices[j]] += population.get_members().at(k)->get_charge()/(population.get_members().at(k)->get_current_cell()->measure())*fval.shape_value(j,q); if((e_o_i==true && population.get_members().at(k)->get_name()=='e' && export_charge==true)){ electron_contribution[local_dof_indices[j]] += population.get_members().at(k)->get_charge()/(population.get_members().at(k)->get_current_cell()->measure())*fval.shape_value(j,q); } } } } } if(e_o_i==false){ for(unsigned int i=0; i!=charge_distribution.size(); ++i){ charge_distribution[i]+=electron_contribution[i]; } } }
...
Oh wait. essayons ça:"
"Ah oui c'est mieux tout d'un coup!"Code:void Pic::distribute_charge(bool export_charge){ dealii::MappingQ1<2,2> mapping ; std::vector<dealii::types::global_dof_index> local_dof_indices (fe.dofs_per_cell); for (unsigned int k=0; k!= population.get_members().size(); ++k){ std::vector< dealii::Point< 2 > > par_loc; std::cout << "k = " << k << std::endl; auto temp=population.get_members().at(k); if((e_o_i==true && temp->get_name()=='e') ||temp->get_name()=='i'){ par_loc.push_back(temp->get_pos()); dealii::Point <2> projection (mapping.transform_real_to_unit_cell(temp->get_current_cell(),temp->get_pos())); dealii::Quadrature<2> quad (projection); dealii::FEValues<2> fval(mapping,fe,quad,dealii::update_values); fval.reinit(temp->get_current_cell()); std::vector<dealii::types::global_dof_index> local_dof_indices (fe.dofs_per_cell); temp->get_current_cell()->get_dof_indices (local_dof_indices); for(unsigned int j=0; j<fe.dofs_per_cell;++j){ for(unsigned int q=0;q<quad.size();++q){ charge_distribution[local_dof_indices[j]] += temp->get_charge()/(temp->get_current_cell()->measure())*fval.shape_value(j,q); if((e_o_i==true && temp->get_name()=='e' && export_charge==true)){ electron_contribution[local_dof_indices[j]] += temp->get_charge()/(temp->get_current_cell()->measure())*fval.shape_value(j,q); } } } } } if(e_o_i==false){ for(unsigned int i=0; i!=charge_distribution.size(); ++i){ charge_distribution[i]+=electron_contribution[i]; } } }
Code dégueu: Check
Tentative de résumé plus clair plus bas
J'ai pas compris. Que le code soit un peu moins illisible OK, mais ça ne devrait pas changer sensiblement les perfs. Tu es sûr de tes options de compil ? Tu es en mode debug ?
Au passage pour ta prochaine RDJ : l'opérateur []. Tu n'es pas obligé d'écrire t.at(42), tu peux aussi l'écrire t[42]. Tu peux même définir un opérateur [] surchargé dans la classe Pop, si l'indexation est naturelle. Ça permettra d'écrire juste population[k].
Java c'est la porte à côté, Monsieur.
Pourquoi tant de haine
Situation dans le premier snippet
Situation dans le deuxième snippetCode:for ( i=0; i<N; ++i){ a=pop.members(i).attribut1; b=pop.members(i).attribut2; c=pop.members(i).attribut3; d=pop.members(i).attribut4; ... [dans ce qui suit on fait des trucs avec a, b, c , d] }
Dans le premier cas, j'ai l'impression qu'il y a quatre accès "inutiles" à pop.members qu'il faut parcourir jusqu'au ième élément quatre fois à chaque itération de la boucle.Code:for ( i=0; i<N; ++i){ temp=pop.members(i); a=temp.attribut1; b=temp.attribut2; c=temp.attribut3; d=temp.attribut4; ... [dans ce qui suit on fait toujours des trucs avec a, b, c , d] }
Alors que dans le deuxième snippet, on ne parcoure pop.members jusqu'à son ième élément qu'une fois à chaque itération.
Il est aussi possible que j'ai une conception erronée du parcours d'un vecteur avec .at().
Pour en revenir aux options de compilation: je crois ne pas être en débug.
Sautes des lignes avant et après les blocs conditionnels, boucles et éventuellement mets des espaces autour des opérateurs, c'est que des conventions mais là faut avouer que ça pique.
Après pour le code lui-même, je fais pas de C++ et je pense pas avoir le niveau pour comprendre ce que tu fais avec tes électrons
Ben en effet, le pseudo-code #2 est mieux. Pour plusieurs raisons à mon avis.
1. c'est plus lisible. Surtout que le code en vrai est bien plus hardcore.
2. ca évite les appels à at(), qui est un accesseur checké (cad qu'il va vérifier que k n'est pas en dehors des clous). Même si ce n'est pas grand chose, c'est toujours des instructions en moins. Si tu te fous des checks, [] est mieux comme dit Mogluglu.
3. il y a des chances pour que le compilateur ne puisse pas garantir que ton élément dans ton vecteur n'a pas été modifié entre deux appels à at. Alors qu'en le mettant dans une variable locale, tu indiques bien que l'élément doit être lu une seule fois. Si la copie n'est pas trop couteuse, je ferais même carrément une copie const dans temp. Ou au moins comme dans le snippet, lire les attributs une seule fois plutôt que d'appeler les getter tout le temps.
Dans le même style, l'appel à size() dans la condition de fin de boucle c'est pas génial non plus si le vecteur est pas censé grossir. Les meilleurs for sont du style:
Sinon comme dit Nattefrost, les saut de lignes ça coute pas plus cher.Code:for(auto e : v) { ... } for(auto it = v.begin(), end = v.end(); it != end; ++it) { ... } for(size_t i = 0, s = v.size(); i != s; ++i) { ... }
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Et met des commentaires. Et utilise plus souvent auto.
---------- Post added at 07h53 ---------- Previous post was at 06h58 ----------
Des types se sont amusés à écrire un compilateur Brainfuck vers Java en Brainfuck : https://code.google.com/p/awib/sourc...java/backend.b
Personnellement je trouve ça trop mainstream. Il faudrait interdire les commentaires et les sauts de ligne.
Rust fanboy
Les commentaires, si c'est pour mettre "// si la condition vaut vrai" devant un if, c'est pas franchement utile. C'est mieux que le code parle de lui même.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Not too bad
http://binaire.blog.lemonde.fr/2014/...queur-de-bugs/
Gérard Berry, traqueur de bugs
Un informaticien médaille d’or du CNRS 2014
Et cerise sur le gâteau: j'ai appris la programmation avec l'un des auteurs du blog
Serge Abiteboul (Inria)
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
La programmation la plus Classe du monde
(désolé pour le mauvais jeu de mots, mais c'est pas lui).
Dernière modification par vectra ; 27/09/2014 à 15h36.
Yop, suite à mon post de la dernière fois, faut que je me renseigne un peu plus sur l'écriture binaire de mes fichiers (idéalement que je fasse une petite doc de comment le fortran90 va écrire les résultats).
Dans mon rapport/doc je vais évoquer le fait qu'utiliser les libraires NetCDF ou HDF5 peut être pratique (surtout pour leur compatibilité avec MatLab et IDL), du coup si vous avez des tutos à conseiller/recommander pour ces librairies ça peut m'être utile (en plus de me faire gagner un temps de recherche ). Mais je me posais aussi des questions sur les endians.
L'ordinateur sur lequel tourne mon code actuellement est doté d'ubuntu 13.10, 64bit et d'un processeur Intel® Core™ i3-3220 , du coup j'écris en little ou en big endian ? (J'aurais tendance à dire little mais je préfère être certain, j'aurais justifié ça par la nature de mon système d’exploitation, est-ce la bonne réponse ?)
Pour les petits indiens, tu peux tester empiriquement avec ta routine d'extraction en matlab en déclarant l'endian explicitement dans les options: tu regardes lequel te donne les bonnes sorties et voila... Quand à savoir le lien exact avec l'os et le cpu, j'en ai aucune idée .
J'ai jamais utilisé netcdf ni hdf5 (c'est pas faute de vouloir, mais en recherche on a jamais le temps de faire tout ce qu'on voudrait...). Mes copains qui utilisent netcdf y ont été formé en même temps qu'aux gros modèles qu'ils utilisent. Donc à moins de vouloir te mettre aux modèles de chimie-transport...
A vue de pif la doc de netcdf a l'air bien faite . Ya même un tutorial.
Les CPU x86 sont toujours little-endian.
D'autres laissent le choix à l'OS (ARM, Power). Mais à part les irréductibles d'IBM, ils sont toujours configurés en little-endian, de nos jours, non ?
Si.
Sleeping all day, sitting up all night
Poncing fags that's all right
We're on the dole and we're proud of it
We're ready for 5 More Years
Incoming problem with Windows 10:
Code:String os = get_os_name(); if (os < "windows 7") { message_box("votre O/S est trop vieux"); exit(1); }
Rust fanboy
Avec l'explication c'est mieux :
http://www.developpez.com/actu/75925...-la-version-9/
Hello,
Je suis confronté au problème suivant: jusque ici, je rapatriais les résultats d'une simulation via Github ( en commit/push les résultats sur le serveur puis en faisant git pull chez moi). Le problème, c'est que je suis maintenant à même de traiter mon problème avec un plus grand degré de précision.
En quoi c'est un problème? Et bien, les fichiers txt stockant les résultats ont bien enflé et font autour de 200 Mo. Donc git push echoue.
Je n'ai besoin des fichiers de 200 mo que une tâche precise: ce fichier contient les coordonnees 2D (vitesse/position) de chaque particule à chaque pas de temps ( soit 10000*500=0.5*10^7 lignes de 4 doubles ). J'ai ecrit un petit programme SFML qui trace la position des particules à chaque instant à partir du fichier texte( en utilisant une commande clavier pour passer au pas de temps suivant), et je crée une capture gif de la fenêtre de ce programme.
Pour surmonter cette nouvelle difficulté, j'envisageais plusieurs choses:
- Bricoler un script bash générant le .gif sans necessiter d'action de ma part que je pourrais ensuite récupérer via git ( Donc pas besoin de trimballer les fichiers de 200 mo via git)
- Ne garder que la position dans les fichiers de résultats pour les rendre moins lourds ( je n'ai pas besoin de la vitesse pour le moment mais ça pourrait changer, donc je suis pas fan de cette solution)
- Stocker les résultats sous une forme plus "light" ( binaire? .tar plutôt que raw .txt files ? ...)
Laquelle vous paraît la moins farfelue?
Merci!
Une fois compressé, tu gagnes beaucoup ? Un facteur 10 ?
Ya vraiment besoin que ce fichier de données soit dans GitHub ?
Les gros fichiers tu peux pas les garder seulement sur ton git local et ne pas avoir à les push/pull sur github ?
Ben tu peux toujours faire un scp si tu as un accès ssh au serveur. Ou bien par http si tu as un serveur web sur le serveur. Ou faire un git push / pull directement entre ton pc et le serveur si tu as un accès direct au serveur.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."