THE_ALF_ a écrit 531 commentaires

Personnellement, j'ai une approche assez pragmatique pour mon code: se concentrer sur du numpy propre permet en général d'avoir rapidement quelque chose de satisfaisant; quand ça bloque, j'écris en C les fonctions qui en ont besoin. Écrire de petits modules en C n'est pas forcément compliqué, mais c'est chiant (surtout pour gérer correctement les échanges entre Python et C). Je suis donc de loin ce qui se passe sur Pythran, si ça peut permettre de faciliter l'écriture de modules optimisés.

Donc ma question ici était surtout de savoir si la fonction Pythran (telle que donnée dans le journal) permet un gain notable par rapport au Python (tel que je l'ai écrit). Le tout est de savoir si la perte de lisibilité (on doit expliciter les boucles) est compensé par un gain en efficacité de calcul (travailler directement au niveau des arrays Numpy est déjà très optimisé).

Et qu'en est-il du gain de vitesse de Pythran par rapport a du pur numpy (codé correctement). L'exemple donné reviens à:

def run(xmin, xmax, ymin, ymax, step, range_, t):
    X,Y = meshgrid(linspace(xmin,xmax,step),linspace(ymin,ymax,step))
    pt = zeros((step,step,3))
    pt[:,:,0] = X*180/pi
    pt[:,:,1] = Y*180/pi
    for k in range(t.shape[0]):
        tmp = 6368.*arccos(cos(X)*cos(t[k,0])*cos(Y-t[k,1])+sin(X)*sin(t[k,1]))
        pt[:,:,2] += where(tmp < range_, t[k,2]/(1+tmp), 0)
    return pt

Je n'ai pas Pythran pour comparer. Quel gain peut-on en attendre?

A noter que cet exemple a été écrit vite-fait, il y a probablement moyen d'optimiser en faisant sauter la boucle sur k.

Je pense que la raison pour laquelle cette "prédiction" se révèle plutôt correcte se trouve probablement dans la conclusion de cet article:

"There is no major feature of Tablet which is not in some sense sitting in a laboratory today. We do not suppose a breakthrough in artificial intellingence, superconductivity, or any sexy technologies"
(Il n'y aucune caractéristique majeure de la Tablette qui n'existerait pas actuellement sous une forme ou une autre dans un laboratoire. Nous ne supposons aucune percée en intelligence artificielle, superconductivité, ou une quelconque technologie sexy)

Il s'agit plus de se demander ce qu'il serait intéressant d'avoir, du point de vu de l'utilisateur, en se basant sur des technologies certes de laboratoires, mais qui marchent. Donc si vous voulez connaître l'informatique de 2030, regardez ce qui se passe maintenant dans les labo.

Question subsidiaire: Cet article peut-il être utilisé en tant que "prior art" pour invalider la plupart des brevets sur le sujet? :-D

Il fallait bien sur lire:

class Pipe(float):
    def __or__(self, val):
        return Pipe(val(self))

En fait, pour voir les pipes comme plus pythonique, il faut comprendre le | comme un opérateur. Or a | b est équivalent à a.__or__(b). On peut donc facilement définir les pipes par:

class Pipe(float):
    def __or__(self, val):
        return Pipe(self(val))

Ce qui peut être utilisé ainsi:

def f(x):
    return x+1

def g(x):
    return x*x

print Pipe(4) | f | f | g
>>> 36

Intéressant :-)

Est-ce fondamentalement différent de faire:

data | operation1 | operation2 | operation3

plutôt que:

data.operation1().operation2().operation3()

La deuxième est plus "pythonesque", et demanderait de créer une classe de donnée possédant les différentes opérations que l'on désire piper, plutôt que de créer des fonction indépendantes qui soient "pipables".

☺

Il me semble que tu as oublié le passage le plus important. Tu parles du cycle de l'éponge, donc tu dois effectivement revenir au point de départ. Quelle est ta méthode pour recycler l'éponge de l'étape 4 vers l'étape 1?

D'après le post d'origine (http://pastebin.com/nfVT7b0Z, lignes 405-415), le fichier aurait simplement été obtenu à partir du hack d'un notebook d'un agent du FBI (Cyber Action Team, un spécialiste sécurité, j'imagines), le fichier ayant été habilement caché dans le "Desktop folder" de la cible.
Si tout ceci est vrai, cela démontre encore un fois que la plus grande source de vulnérabilité info est, et reste, située entre le chaise et le clavier…

Si je comprends bien, le sens de ta question a ton ami athée est "qu'est-ce qui t'empêche de pousser tes enfants a te droguer si tu ne croix pas en x". Ce qui laisserai entendre qui ce qui empêche un croyant en x de faire y, c'est le fait que ce soit interdit par sa foi en x.

Je ne comprends donc pas ta surprise, vu que ton ami semble avoir le même comportement que toi: faire y n'est pas bien car x me l'interdit, avec x₀="père noël" dans ton cas, et x₁="loi" dans le cas de ton ami.

Par contre, on peut effectivement comprendre que ce comportement soit immature: dans les deux cas, seul la foi en x empêche de commettre y, plutôt que de réellement comprendre la raison de ne pas commettre y (avec donc le risque de commettre y lorsque la menace de x semble faible).

Afin d'être pleinement libre de ses actes de manière responsable, il est donc nécessaire de ne pas croire en x ∀x (ce qui a pu être résumé dans la fameuse phrase "ni x₀ ni x₁").

CQFD

PS: désolé pour les accents et les symboles, j'écris avec un QWERTY ☺

Bien sur que les 25% de temps processeur n'ont aucune influence sur la réactivité de la machine. Mais si c'est récurrent, ça a un impact très important sur la puissance consommée par la machine, et donc sur son autonomie.

Le problème n'est pas que le logiciel obtiennes les ressources qu'il demande, mais qu'il fasse des demandes excessives. Et donc oui, si un logiciel s'amuse à consommer de l'énergie à tout va, il est normal de chercher des logiciels plus sobre. J'ai facilement gagné 20% d'autonomie en faisant la chasse à de tels logiciels.

Je ne penses pas que ce soit un problème lié à la gestion des news, mais plutôt un problème qu'à TB pour indexer les messages, pour peu que l'on ait une grosse quantité de messages archivés. Je n'utilise TB que pour mes mails avec quelques GB d'archives, et j'ai le même problème: l'archivage de TB s'active régulièrement en occupant un core à 100% pendant 10-30s.

Enfin bref, je ne sais pas si l'abandon de TB sera plus une mauvaise qu'une bonne nouvelle. Ça va être l'occasion de voir comment mieux gérer mes mails (reportée x fois, pour cause d'inertie d'utilisation journalière d'un soft). A moins que le projet soit mieux mené par la communauté…

????

$ less /etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

Maintenant avec grub2, pour ajouter une entrée dans le démarrage, il faut… juste éditer un fichier.

Certes, mais la différence me semble plus de l'ordre sémantique que pratique… J'utilise justement unison quotidiennement, le but étant effectivement de synchroniser rapidement les données de mon dossier de travail (plusieurs GB) entre mon laptop, ordi de bureau, et deux disques durs sur serveurs accessible en ssh. Je fais cette synchro au moins une fois par jour, en gros en fin de journée et après chaque création de donnée jugée importante (oui un peu de paranoia, issue d'un accident d'il y a quelques années, impliquant la conjonction malencontreuse entre un ordi, une tasse pleine de café, et ma propre personne pas encore assez caféinée; la perte de donnée en fut irrémédiable).

Quel est le résultat? Mes données se retrouvent identiques et accessibles dans plusieurs endroits géographiquement distincts. C'est de la synchro ou du backup? Perso, je ne vois pas la différence; les données sont synchronisées entre plusieurs endroits. La différence entre synchro et backups ne me semblent exister que dans la manière dont j'utilise les copies. C'est de la synchro entre mon laptop et desktop; je peux travailler soit sur l'un, soit sur l'autre, c'est le même jeu de données. C'est du backup entre mes ordis de travail et de stockage; les ordis distants sont là pour retrouver les données en cas de problème sur les ordis de travail. La technique pour réaliser la synchro et le backup est la même, et je ne vois pas pourquoi utiliser des outils différents pour les deux.

À vérifier, mais il me semble qu'il y a eu des rééditions des chroniques martiennes, avec notamment l'ajout de nouveaux chapitres au cours du temps.

Le problème est que cela veut dire que du fait de ces choix, on ne peut pas utiliser dfc comme un remplacement de df. En particulier cela risquerait de casser tout scripts ou autre programme faisant appel à df, ou d'empêcher l'utilisation de dfc comme une "alternatives" à df. Et ça casse les habitudes (honnêtement, la première commande que j'ai tapée pour voir ce que l'on pouvait faire à été "dfc --help"…)

Tu fais ce que tu veux, bien sur, c'est juste que ça me semble dommage de se couper d'une possibilité d'utilisation (i.e. utiliser dfc comme un ajout de couleur à df plutôt que comme une nouvelle commande similaire à df) pour vouloir d'autre options de configurations que celles l'outil standard.

Simple et efficace, j'adopte, merci :)

Un petit bémol: pour pouvoir être utilisé correctement en remplacement de df, il serait intéressant que df et dfc utilisent les mêmes options en ligne de commande. Typiquement, 'df -h' affiche le mode "human readable", alors que dfc affiche l'aide. Ce genre de différence de comportement peut poser des problèmes lorsque l'on a un alias de df vers dfc.

Raphaël

Tout a fait, mais notes que cet article se place d'emblée dans un cadre "open data" (abstract: "Although it is now accepted that data should be mad eavailable on request, the current regulations regarding the availability of software are inconsistent."). Les auteurs présentent donc bien la nécessité de l'accessibilité du code en complément de l'accessibilité des données.

Le problème de l'accès au code est effectivement très problématique, on se retrouve très souvent avec des articles présentant des résultats obtenus avec un code dont on à qu'une description succincte. Heureusement, les esprits à ce sujets sont en train d'évoluer.

Cet article en est un très bon exemple, un autre très intéressant paru il y a 2 ans écrit par N.Barnes, "Publish your computer code: it is good enough" va dans le même sens (http://www.nature.com/news/2010/101013/full/467753a.html). L'intérêt de ce dernier est de pointer en particulier les réticences que l'on a en général pour ne pas donner accès à son code scientifique. Ces raisons sont souvent assez différentes des réticences qu'on les compagnies pour libérer leur code propriétaire (notamment l'idée que le code n'est pas assez propre pour publication, et la "peur" de montrer un code quick&dirty, même si celui-ci est parfaitement fonctionnel pour ce qu'il était censé faire).

Mouais, ça reste quand même grosso-modo des tailles similaires. Un LaTeX optimisé pour une simple colonne sera bien partout (ce qui est important est le nombre moyen de mots par ligne, pas vraiment leur taille visuelle). Tout dépends des priorité. Je penses qu'un rendu typo correct est bien plus important que des fluctuations de zooms.

Avec le passage à la liseuse, je ressens vraiment une perte assez grande de qualité de lecture par rapport au livre en papier, du fait de ce choix de "typo moyenne partout"; pouvoir adapter la taille de la police ne reste qu'un gadget à mon goût.

J'en reste à la possibilité de reformater en LaTeX mes ebooks quand c'est possible.

Je ne vois pas trop ce que tu veux dire. Il est facile d'avoir un epub et un pdf/latex ayant une même dimension de page et de texte. Pas de problème, la question n'est pas là.

Avoir un rendu typo correct demandes une certaine quantité de calcul. Pour que epub reste adapté à une liseuse, les lecteurs epub se limite à un rendu assez basique (texte justifié, césure indépendantes de la langue du texte, et ligatures dans le meilleur des cas). Il me semble bien plus adapté d'avoir un texte au rendu pré-calculé pour la liseuse, plutôt qu'un html à réinterpréter. Dans tous les cas que j'ai utilisé, et une liseuse récente (Cybook Odyssey), un pdf/LaTeX reste dans tous les cas bien plus agréable à lire qu'un epub.

voire d'imprimer le pdf pour avoir un support papier pour l'annoter "à l'ancienne"

Justement, avec une liseuse avec stylet, tu peux l'annoter "à l'ancienne" sans gâcher du papier :).

Certes, mais les liseuses possédant une capacité de calcul limité (et à limiter pour conserver la charge de batterie), il est assez peu adapté de faire les calculs de typos sur la liseuse même (si tu veux un rendu correct, donc avec micro-typo, ça peux être assez coûteux en temps de calcul).

Et en pratique (ce qui est probablement lié à cette remarque), les logiciels de rendu epub sur les liseuses restent moyen en typo/césure par rapport à ce que tu obtiens avec un pdf from LaTeX.

Tout a fait, je préfère infiniment lire un pdf formaté correctement en simple colonne qu'un epub. Même en oubliant le gros problème posé par les formules mathématiques et les figures, epub reste très approximatif pour la qualité de la typo et des césures par rapport à LaTeX.

Ce que je préférerais avoir, c'est un mode de lecture double colonnes sur les liseuses. Le lecteur pdf se positionnerait en zoom en demi largeur en haut à gauche; passer à la page suivante déplacerait la vue sur la page courante de haut en bas, puis de gauche à droite, puis à la page suivante une fois arrivé en bas à droite; la possibilité de passer facilement d'un mode double colonne en simple colonne donnerait l'accès simple aux figures sur deux colonnes.

Bref, sans grande révolution, le format classique des publis en double colonnes resterait parfaitement adapté aux liseuses (qui sont logiciellement souples), tout en restant parfaitement adapté au format papier (qui est ce qu'il est). Et on continuerait ainsi à avoir un confort de lecture équivalent avec les anciennes publis (qui ne sont pas près de changer de format...)

• Aaaahh, Tintin, le Lotus Bleu, toute mon enfaaaance
• Aaaahh, Aimé, Jean Némar, le docteur Tutut de Carali, Toute mon enfaaaance

http://www.archive.org/details/hebdogiciel-french-162 p25. Je l'avais tapé ce jeu d'ailleurs :)

Parce que se servir du code source d'une appli n'est pas justement une des utilisations de l'appli ???