2353 shaares
Intéressant. Je garde sous le coude.
(via sebsauvage)
(via sebsauvage)
Contrôler la fréquence des CPU en ligne de commande. Pratique quand les cpus chauffent un peu trop, ou quand on veut économiser la batterie en déplacement.
Très utile. Je suis en train de passer tous mes dvd en divx. Un truc en plus: quand acidrip insiste absolument pour inclure les sous-titres, il faut cliquer sur subfile pour les inclure dans un fichier séparé.
Que l'on ne gardera pas.
Que l'on ne gardera pas.
Il est toujours bon de se souvenir d'épisodes comme celui-ci
À garder sous le coude: un site qui liste un certain nombre de corrélations entre phénomènes clairement pas liés sur un plan causal.
Marrant
Marrant
Marrant
J'aime bien l'ensemble de Mandelbrot...
Cette revue est en train de devenir un classique, elle est citée de partout... Je la garde donc sous le coude
Debating creationists on the topic of evolution is rather like trying to play chess with a pigeon — it knocks the pieces over, craps on the board, and flies back to its flock to claim victory.
Debating creationists on the topic of evolution is rather like trying to play chess with a pigeon — it knocks the pieces over, craps on the board, and flies back to its flock to claim victory.
Établir ses données. À lire
via mathieu
via mathieu
Encore un SMBC de génie.
Tout est dans le titre
J'aime bien smbc
(via mathieu) Oh les salopards. Cela dit, en Europe, pour le moment, on est protégé: http://www.numerama.com/magazine/28966-victoire-pour-la-neutralite-du-net-au-parlement-europeen.html
Maintenant, quand on soumet un package à CRAN, il faut aussi checker les fuites de mémoires:
R CMD check --as-cran --use-valgrind monpackage_1.tar.gz
Et ce, avec la dernière version de développement de R (laquelle doit nécessairement être compilée depuis les sources -- et elle change tous les deux jours -- et d'une façon particulière pour avoir les tests demandés). Avant pour soumettre une nouvelle version, il fallait une demi-heure. Maintenant, il faut une journée...
C'est de plus en plus compliqué de maintenir des packages sous R...
EDIT: Bon, en fait, il vaut mieux adapter les instructions du manuel de R à son cas perso plutôt que de récupérer des infos secondaires. Pour moi, ça donne ça:
1. Si on est sur une nouvelle machine qui a pas encore ça, créer un répertoire /home/username/.R/ et un fichier Makevars dedans contenant la ligne suivante:
CC = gcc-4.9 -std=gnu99 -fsanitize=undefined -fno-omit-frame-pointer
Bon normalement ya d'autres choses à rajouter quand on fait du fortran, du c++, etc. Moi, m'en fous, je fais que du c. Ça ça servira à compiler le code C du package que je développe (ajoute les flags adéquats à R CMD check, R CMD build, et R CMD shlib). Noter aussi que la ligne sera à adapter en fonction de la version de gcc.
2. Éditer le fichier config.site des sources de R-devel, et définir les variables suivantes:
CC="gcc-4.9 -std=gnu99 -fsanitize=undefined"
CFLAGS="-fno-omit-frame-pointer -O2 -Wall -pedantic -mtune=native"
le fsanitize=undefined définit l'usage de l'ubsan lors de la compilation et du debuggage, le fno-omit-frame-pointer n'est pas toujours obligatoire mais si on le met pas ça fait planter certaines machines. Le mtune correspond à une autodétection du CPU utilisé pour le build, et va produire du code optimisé pour ma machine. Pour le reste, rien de nouveau par rapport à une compilation classique.
Idem, gaffe ici aux versions de gcc
3. Configurer R-devel pour la compilation:
./configure --enable-R-shlib --enable-memory-profiling --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh --with-tk-config=/usr/lib/tk8.5/tkConfig.sh
Idem, gaffe aux versions de tcl et tk
4. compiler R-devel classiquement avec make et sudo make install
5. lors du check du package:
R CMD check --as-cran --use-valgrind monpackage_1.tar.gz
C'est là que cette fortune de R prends tout son sens:
I'm still confused about how to avoid the wrath of the CRAN-devel daemon, whose
appetite for new morsels of developer flesh seems ever increasing and makes
keeping even a stable package up-to-date a moving target.
-- Michael Friendly (about checking packages for CRAN)
R-devel (September 2013)
R CMD check --as-cran --use-valgrind monpackage_1.tar.gz
Et ce, avec la dernière version de développement de R (laquelle doit nécessairement être compilée depuis les sources -- et elle change tous les deux jours -- et d'une façon particulière pour avoir les tests demandés). Avant pour soumettre une nouvelle version, il fallait une demi-heure. Maintenant, il faut une journée...
C'est de plus en plus compliqué de maintenir des packages sous R...
EDIT: Bon, en fait, il vaut mieux adapter les instructions du manuel de R à son cas perso plutôt que de récupérer des infos secondaires. Pour moi, ça donne ça:
1. Si on est sur une nouvelle machine qui a pas encore ça, créer un répertoire /home/username/.R/ et un fichier Makevars dedans contenant la ligne suivante:
CC = gcc-4.9 -std=gnu99 -fsanitize=undefined -fno-omit-frame-pointer
Bon normalement ya d'autres choses à rajouter quand on fait du fortran, du c++, etc. Moi, m'en fous, je fais que du c. Ça ça servira à compiler le code C du package que je développe (ajoute les flags adéquats à R CMD check, R CMD build, et R CMD shlib). Noter aussi que la ligne sera à adapter en fonction de la version de gcc.
2. Éditer le fichier config.site des sources de R-devel, et définir les variables suivantes:
CC="gcc-4.9 -std=gnu99 -fsanitize=undefined"
CFLAGS="-fno-omit-frame-pointer -O2 -Wall -pedantic -mtune=native"
le fsanitize=undefined définit l'usage de l'ubsan lors de la compilation et du debuggage, le fno-omit-frame-pointer n'est pas toujours obligatoire mais si on le met pas ça fait planter certaines machines. Le mtune correspond à une autodétection du CPU utilisé pour le build, et va produire du code optimisé pour ma machine. Pour le reste, rien de nouveau par rapport à une compilation classique.
Idem, gaffe ici aux versions de gcc
3. Configurer R-devel pour la compilation:
./configure --enable-R-shlib --enable-memory-profiling --with-tcl-config=/usr/lib/tcl8.5/tclConfig.sh --with-tk-config=/usr/lib/tk8.5/tkConfig.sh
Idem, gaffe aux versions de tcl et tk
4. compiler R-devel classiquement avec make et sudo make install
5. lors du check du package:
R CMD check --as-cran --use-valgrind monpackage_1.tar.gz
C'est là que cette fortune de R prends tout son sens:
I'm still confused about how to avoid the wrath of the CRAN-devel daemon, whose
appetite for new morsels of developer flesh seems ever increasing and makes
keeping even a stable package up-to-date a moving target.
-- Michael Friendly (about checking packages for CRAN)
R-devel (September 2013)
Ou alors ya ça. Bon.
Localiser un numéro de téléphone juste à partir des 4 premier chiffres. Toujours utile
Juste parce que ça m'énerve et que j'en ai marre de passer des plombes à chaque fois à rechercher la ref, je la stocke ici une fois pour toutes:
Souvent, quand on fait un graphe représentant des quantités positives (pourcentages, proportion, etc.) on se reçoit de la part d'un référé un peu borné la critique que l'axe des Y doit impérativement inclure le 0, sinon "c'est de la triche". Et des fois, c'est même pire: pour des proportions, il est demandé à ce que les limites de l'axe soit 0/1.
Bon: mettons les choses au clair une fois pour toutes. Extrait de Cleveland, W.S. (1985). The Elements of graphing data, Wadworth advanced books and software.
P. 87 et suivantes, il indique:
"When the data are magnitudes, it is helpful to have zero included in the scale so we can see its value relative to the value of the data. But the need for zero is not so compelling that we should allow its inclusion to ruin the resolution of the data on the graph. (...) For graphical communication in science and technology /assume the viewer will look at the tick mark labels and understand them/. Were we not able to make this assumption, graphical communication would be far less useful. If zero can be included on a scale without wasting undue space, then it is reasonable to include it, but never at the expense of resolution."
(le slash indique l'italique)
Ça a le mérite d'être clair. Et Cleveland donne plusieurs exemples de ça. Le lecteur n'est pas un idiot: il lira les labels des axes. C'est un peu comme les diagramme en camemberts: on pourrit la représentation graphique juste pour pouvoir affirmer fièrement que les proportions somment à 1. Et on perd toutes les autres infos parce que l'œil humain est incapable de juger des surfaces.
Souvent, quand on fait un graphe représentant des quantités positives (pourcentages, proportion, etc.) on se reçoit de la part d'un référé un peu borné la critique que l'axe des Y doit impérativement inclure le 0, sinon "c'est de la triche". Et des fois, c'est même pire: pour des proportions, il est demandé à ce que les limites de l'axe soit 0/1.
Bon: mettons les choses au clair une fois pour toutes. Extrait de Cleveland, W.S. (1985). The Elements of graphing data, Wadworth advanced books and software.
P. 87 et suivantes, il indique:
"When the data are magnitudes, it is helpful to have zero included in the scale so we can see its value relative to the value of the data. But the need for zero is not so compelling that we should allow its inclusion to ruin the resolution of the data on the graph. (...) For graphical communication in science and technology /assume the viewer will look at the tick mark labels and understand them/. Were we not able to make this assumption, graphical communication would be far less useful. If zero can be included on a scale without wasting undue space, then it is reasonable to include it, but never at the expense of resolution."
(le slash indique l'italique)
Ça a le mérite d'être clair. Et Cleveland donne plusieurs exemples de ça. Le lecteur n'est pas un idiot: il lira les labels des axes. C'est un peu comme les diagramme en camemberts: on pourrit la représentation graphique juste pour pouvoir affirmer fièrement que les proportions somment à 1. Et on perd toutes les autres infos parce que l'œil humain est incapable de juger des surfaces.
Somebody is wrong on the internet. Celui-là, je me le stoque ici, j'en ai marre de le chercher à chaque fois
Un groupe de chercheur travaillant sur l'interaction maths/environnement/écologie