Moonz a écrit 3619 commentaires

De toute façon, tout le monde sait que l'homosexualité est génétique...

> Le jour où un pirate réussira à violer une propriété intellectuelle, je veux bien que celui vienne me raconté si c'était bon et si ça lui a pas trop abîmé sa bite et quelques autres histoires de pirates, parce que, vous l'auez compris, j'aime bien les histoires de pirates.

J'adore :D
Cette phrase, elle est copyleftée ? :)

Oui mais non.
Personnellement, je n'ai jamais vu l'animé, mais pour le manga, c'est exactement comme tu décris, et pourtant... tu ne lis PAS le manga pour le côté shonen. Chez nous, au club manga, quelq'un qui lit One Piece se fait repérer de loin: c'est celui qui est pris d'une subite crise de fou rire. Vraiment, le côté comique de One Piece est très réussi je trouve. Le réduire à du shonen, c'est avoir un humour plus que déplorable :)

+1 pour Fumoffu. Vraiment, pendant les partielles, je m'en regardait un épisode après chaque épreuve, et ça me rendait le sourire (voire même le rire ;))

Azumanga Daioh et Jungle wa itsumo hare nochi guu méritent aussi un détour. J'ai regardé à l'époque où y avait pas de fansub FR (ne parlons pas des DVD officiels), en VOSTA, et le seul moyen pour m'arrêter était: être trop fatigué pour traduire les sous titres qui défilaient (vers 1h du matin en général :p)
Toutefois, sans vouloir faire mon méchant tipiak, je vous conseille pas DU TOUT la traduction "officielle" d'Azumanga Daioh, vraiment loupée AMHA...
Dans le genre plus sérieux mais vraiment très sympa, il y a Mushishi (et tous les films du studio Ghibli à voir et à revoir).
Dans le même genre que FMP aussi (la première saison), il y a Samourai Champloo, vachement sympa.
Enfin, dans un registre plus "action" (mais pas shonen de base non plus), Death Note est LE truc du moment à voir. (coup de pub: les trads de addict-subs très agréables). Personnellement, j'ai aussi beaucoup apprécié Jyo Oh Sei...

D'autant plus que ça se fait au commissariat, et que si un quelqu'un te fait pression pour ça, tu as juste à lui répondre "d'accord, viens juste signer les papiers avec moi..." :p

> Il est seulement constant avec son discours de campagne.
Bon, tu admets donc au moins qu'il a une certaine cohérence :)

Donc, pas le droit de faire une dépèche là dessus ?
http://candidats.fr/index.php/2007/04/20/71-reponses-de-nico(...)

J'ai aussi calculé en Python le 25!~15511210043330985984000000, mais 2000! ne passe pas (stack overflow, d'où l'idée de passer par une récursion terminale - ou une boucle, à la limite)
De toutes manières, ya des erreurs de calcul à partir de 20! (les à la fin 4000000 de 25! ne sont pas normals)

Aucune chance que ce code fonctionne :)
- Tu vas probablement faire un stack overflow, tu devrais faire ton algo avec une récurrence terminale afin que GCC fasse les optimistions kivontbien
- Utilise gmp, ça tiendra jamais sur 64 bits: 2^64=18446744073709551616, 25~15511210043330985984000000

Et quand l'admin ferme les ports 6881 à 6999, on fait comment ? :p

>print for 5...10
>et on peut même encore faire plus court (et finalement plus lisible):
>print 5..10

Tu veux dire, même le for est implicite ?
À ce train là, en Perl, mêne un programme vide fera quelque chose...
--->[]

Et ya moyen d'avoir ça avec une syntaxe potable ? (désolé, ignorez ça, c'est un réflexe, un instinct de survie qui me pousse à réagir violemment à la simple vue de := )

Plus sérieusement, Lisaac, j'aime bien le concept, mais la syntaxe me fait fuir. C'est volontaire ou ça vient de moi ? (du genre INTEGER_32, tout en majuscule, je trouve ça moche - et pas pratique à taper surtout. L'opérateur d'affection de deux lettres, je trouve ça chiant au possible aussi).

Questions vraiment sérieuses (promis cette fois):
- LIST[INTEGER_32]: le [ ], il est défini comment (et où, surtout): dans le langage, comme en C++ avec un operator[] ou en python __getitem__ ?
- pour le .when_alone { foo }, comment on sait que ça s'applique sur lst ? C'est du sucre syntaxique du langage ou un truc astucieux de COLLECTION (du genre when_empty renvoie la liste donc le truc équivaut vaguement à lst.when_empty(bloc_1).when_alone(bloc_2))

> Il serait sans doute utile que tu revois ton cours d'algo quand même parce que dans une table de hachage, les éléments sont bien contigüs aussi en mémoire
Au temps pour moi, je cours me cacher tout de suite, j'arrête pas de sortir des conneries énormes en ce moment..
C'est à cause de la chaleur, ça empèche mon cerveau de travailler de manière optimale


Pour ce qui est du troll tableau/table de hachage:
en ruby, je sais pas (même si ça fait 3 mois que je dit que j'allais m'y mettre, avec le Lisp et l'Objective-C ;)), mais en Python tu as effectivement des tables de hachage dans le langage, et c'est "à peu près" de même utilisation (s'entend: c'est pas la même classe, mais à l'utilisation c'est vaguement la même chose: la notation foo[key])
Il faut voir aussi qu'en python qu'avec un tableau tu as un ordre garanti, tandis qu'avec la table de hachage, puisque la fonction de hachage est un machin interne succeptible de changer, tu peux pas garanit que les clefs seront ordonnées comme tu le penses. Les tableaux sont donc fortement utilisés également pour des trucs genre piles et files, et pas seulement parce que c'est "un peu plus" rapide.

> Je vois pas comment tu peux implémenter la mémoization au niveau de l'OS mais c'est relativement simple à mettre en place au niveau du runtime d'un langage pas trop mal foutu (même gcc peut le faire pour du C si j'en crois certains attributs de fonctions non standards).
Commence pas à tout confondre hein :)
J'ai pas réussi à trouver les attributs dont tu parles, mais de ce que j'ai compris de l'article de Wikipedia, c'est simplement du sucre syntaxique pour quelque chose que tout le monde a déjà fait (exemple avec la STL, j'ai la flemme de faire le tableau en C):

typedef std::map<int,int> fmap;
using std::make_pair;

int factorielle(int n) {
int f; static fmap res;
if(res.find(n) != res.end()) return res[n];
if(n == 0 || n == 1) return 1;
f = n * factorielle(n-1);
res.insert(make_pair(n, f));
return f;
}


C'est donc bien le programmeur qui décide quand il faut mémoriser, pas le langage qui devine tout seul

> Ha bon pourtant xrange(y)[x]=x, ou j'ai pas suivit quelque chose...
cf:
> (bon, ça, c'est la théorie, en pratique, xrange peut te calculer immédiatement un élément quelconque, mais c'est une optimisation spécifique à xrange)

Bon, d'accord, pour le reste, je me suis royalement embrouillé, j'admets: j'ai joyeusement mélangé xrange et son itérateur...

Il fallait donc lire:
>>> x = iter(xrange(5))
>>> print x
<rangeiterator object at 0xb7c213e0> # C'est mieux, effectivement ;)
>>> x.next()
0
>>> x.next()
1
>>> for i in x:
... print i
2
3
4
>>>

> le xrange que tu decrit serait plutot une liste chainée...
Alors là pas du tout:
- xrange n'est qu'une fonction qui génère des nombres et qui peut fournir un itérateur
- le xrange que je décrivait était un itérateur, qui n'a rien à voir avec une liste chainée.
En gros: une liste chainée, c'est grosso modo comme un tableau: tu la construits, puis tu l'utilises
L'objectif de l'itérateur est de construire les éléments "à la demande" et de ne rien garder en mémoire (histoire de ménager la mémoire, justement). L'intérêt par rapport à la liste chainée est de ne pas avoir à construire des éléments dont on a pas besoin et de garder une empreinte mémoire faible.

Pour être imagé, tu peux voir une liste chainée comme une matrice ligne à N éléments, et un itérateur comme une suite récurrente. D'ailleurs, voilà ce que je peux faire avec les itérateurs, qui est impossible avec les tableaux:
class naturels:
def __init__(self): self._i = 0
def __iter__(self): return self
def next(self): i = self._i ; self._i += 1 ; return i

for i in naturels():
if est_premier(i): print i

En gros, je viens de faire une sorte de range(0, infinity). Tu remarqueras que l'appel construction de naturels() ne prend ni un temps infini ni un espace mémoire infini.
Avec un tableau (ou une liste chainée), tu aurais été obligé de construire un tableau contenant tous les naturels (ça t'aurait pris un temps infini, mais bien heureusement, ta mémoire sera saturée bien avant) avant de pouvoir itérer dessus.

Tiens, un exemple amusant qui me vient à l'esprit: c'est équivalent à:
class premiers(naturels):
def next(self):
i = naturels.next(self)
if est_premier(i): return i
else: return self.next()

for i in premiers():
print i

> D'ailleurs il semble que on ne peut rien affecter dans un xrange :
Avec une liste chainée, tu pourrais...

> C'est un travail pour une table de hachage ça (ou même un arbre, qui peut être implémenté par des listes).
Pas forcément. Si tes éléments sont indexés par les premiers entiers (comme un tableau, quoi), il peut être intéressant de tout classer séquentiellement en mémoire (ensuite, tab[i], est équivalent à une simple addition de pointeurs, ce qui est plus intéressant qu'une fonction de hachage, tu en conviendras)
oui, je sais, ça convient pas dans tous les cas Pas la peine de me refaire un cours d'algo, là c'est itérateur vs tableau, pas liste vs table de hachage (tableau != liste, de toute manière, et toc ! ;)).

> Et pourquoi le langage ne pourrait-il pas mémoizer (sic) les résultats tout seul ?
Comment le langage pourrait il savoir ce qui est pertinent de mémoriser ou pas ? (oui, on pourrait s'inspirer des algos de gestion de la mémoire des OS, mais franchement, si tu veux recoder les caractéristiques de ton OS dans le langage, fais du Java ;))

J'oubliais: les tableaux aussi ont leur utilité (parce que si les itérateurs étaient si merveilleux, on utiliserait plus que ça ;)): avec un tableau, on accède très rapidement à un élément quelconque. range(5000)[4999] te répondra immédiatement, xrange(5000)[4999] nécessite de calculer les 4999 éléments précédents. Tu vas me dire, range aussi, pour construire la tableau. Bien entendu, mais si juste après tu as besoin du 4998 ème élément, ce sera quasi-instantanné pour range. Pour xrange, il devra à nouveau recalculer tous les éléme,nts précédents
(bon, ça, c'est la théorie, en pratique, xrange peut te calculer immédiatement un élément quelconque, mais c'est une optimisation spécifique à xrange)

De plus, avec un tableau, un résultat est calculé une fois pour toutes. Si tu fais 10 itérations sur une séquence, un tableau te calcule 1 fois le résultat puis le met en mémoire. Un itérateur te calculera 10 fois chaque résultat.

Je viens de le dire: la première version va te bourrer la mémoire et mettre à genou ton CPU, parce qu'elle va créer un tableau de 20000000 entiers pour ensuite le parcourir
La deuxième version va simplement créer un itérateur, qui ne mémorise que l'état courant et qui ne sait rien faire d'autre qu'aller à l'état suivant. C'est plus économique en mémoire et en temps CPU.
En gros:
>>> x = range(5)
>>> print x
[1, 2, 3, 4]
>>> x = xrange(5)
>>> print x
xrange(5)
>>> print x.next()
0
>>> print x.next()
1
>>> print x.next()
2
...
Remplace 5 par 2000000. Tu vois tout de suite que ton range va sacrément bourrer à la fois ta mémoire et ton CPU, tandis que le xrange ne coutera rien en plus.

C'est quelque chose de bien plus général qu'un simple intervalle. S'il est évident qu'un programmeur d'écrira JAMAIS range(2000000), on peut par contre voir par exemple:
data = [line.split(',') for line in open('data.csv').read().splitlines()]
qui fonctionnera pour des tests basiques, mais qui est plutôt inefficace:
- ton fichier est entièrement gardé en mémoire (read())
- il est gardé une deuxième fois en mémoire (chaque ligne comme un élément d'un tableau: splitlines())
- enfin, il est gardé une troisième fois en mémoire (chque ligne séparée en champ)
Tu auras aussi du utiliser 3 fois le contenu de ton fichier pour simplement afficher tous les premiers champs par exemple:
- d'abord en lisant entièrement le fichier (le read())
- ensuite en itérant sur les données pour les traiter ligne par ligne (le splitline)
- ensuite en itérant sur data

Avec un itérateur:
data = (line.split(',') for line in open('data.cvs').xreadlines())
ton fichier n'est lu qu'une fois en mémoire, les données ne dont itérées que si nécessaire: cout mémoire virtuellement nul et efficacité optimale. Si ton fichier fait 300 Mo et que tu ne veux que les trois premiers enregistrements, la première version nacéssitera de parse et de garder en mémoire les 300 Mo. La deuxième ne prendra pas plus de mémoire que si ton fichier faisait 5 Go ou 5 octets, et ne prendra que le temps nécessaire à lire les trois premiers enregistrements

La différence, c'est que le premier est un tableau. Le deuxième est un itérateur (plus précisement, un générateur). C'est la même différence qu'entre un range et un tableau. Vois tu l'intérêt de les différencier, maintenant ? :p

Comme en python je suppose: quelle est la différence entre:
for i in range(2000000000): print i
et
for i in xrange(2000000000): print i

La première version va essayer de te créer un tableau de 2000000000 entiers, puis de le parcourir. À mon avis, ça a peu de chances de fonctionner de manière optimale :)
Si tu n'es pas convaincu, essaye ces deux versions dans une console python :p

Pour ajouter de l'eau au moulin: en Python, on dirait
print " ".join(( str(x) for x in xrange(5,11) ))
Ou plus efficacement:
print " ".join(map(str, xrange(5,11)))

Un Firefox avec noscript ?
Et puis si HTML 5 n'est qu'une évolution d'HTML 4, qu'est-ce qui empèchent links, lynx, ou dillo de l'implémenter ?

Bienvenue dans le monde des non geeks...

> Les tours se sont effondrées sur lui, mais il a survécu
Je suis le seul à tilter là dessus ? :p
Remarque, ça expliquerait pourquoi les chinois du FBI n'ont pas réussis à le faire taire par la force, si c'est invincible man... :)

C'est que tu es vraiment un cancre en chimie, et je pèse mes mots ;)

Les anarchistes sur DLFP, c'était mieux à vent...

Et même la petite souris, qui, rappelons le, est le véritable créateur de Linux
Ce qui peut aussi expliquer la manière dont on a fait taire Reiser...