Moonz a écrit 3537 commentaires

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...

> Comment expliquez-vous que l'on ait analysé de l'acier fondu, avec formation d'un eutectique Fe-S
http://fr.wikipedia.org/wiki/Image:Diagramme_phase_eutectiqu(...)
Peux tu m'expliquer ce qu'il y a d'étrange à ça ?
Dans une solidification binaire de deux liquides, le point d'équilibre se rapproche de l'eutectique quand la température diminue...
Explication simplifiée:
On se place sur un point du un domaine liquide, à gauche de l'eutectique.
Baissons ensuite la température. La température du liquide baisse jusqu'à ce l'on rencontre la courbe verte (de gauche, dans notre exemple). On a alors formation de premiers cristaux de A purs. Toutefois, du coup, la composition en A du liquide baisse, et le point de composition du liquide se déplace donc vers la droite. La température baisse à nouveau, puis des cristaux de A pur se forment, donc la composition en A du liquide baisse, le point de composition du liquide se déplace vers la droite, etc...
De même, si ton liquide était plus concentré en A, au cours de la solidification, le point de composition se dépacerait de la même manière.
Tu vois donc très bien que la composition du liquide a tendance à se rapprocher de l'eutectique.

De plus, comme je pense qu'on peut prendre comme hypothèse qu'on a beaucoup plus de fer que de souffre dans le cas du WTC, on peut donc en conclure sans trop de difficulté que dans notre cas la composition du liquide était soit du côté fer, soit très proche de l'eutectique. Donc que l'eutectique Fe-S dans ce cas n'est pas absurde...

Bon, après, il faut aussi voir que l'on était pas dans le cas d'un mélange binaire (vu que c'était de l'acier, il y a au moins le carbone qui entre en compte). Pour une conclusion générale donc, dire qu'un eutectique Fe-S est absurde est absurde, mais ce n'est pas non plus vrai de dire que c'est quelque chose d'évident (il faudrait au minimum raisonner sur un diagramme ternaire Fe-S-C - perso, je me lance pas là dedans, même si on me le fournit...)

> En chimie, c'est symétrique ce genre de chose.
Si tu ne comptes que l'énergie de liaison, effectivement
Mais l'énergie de formation dépend de beaucoup d'autres choses (température, pression, propriétés géométriques (l'énergie de formation du carbone graphite est différente de l'énergie de formation du carbone diamant, par exemple))
De plus, il y a également les lois de l'équilibre chimique dont il faut tenir compte, qui dépendent aussi de la température et de la pression (à très forte pression le graphite se transforme spontanément en diamant, mais dans les conditions normales c'est exactement l'inverse...)

Je dois avouer que j'ai la flemme de lire les specs de HTML 5, alors puisque j'ai quelqu'un qui les a lues sous la main, j'en profite ;)

Y a t'il dans HTML5 des "client-side includes", c'est à dire un truc du genre
<include src="foo.xml" />, qui remplace la balise include dans l'arbre DOM par l'arbre DOM de foo.xml (éventuellement sans la balise racine) ?
En fait, je pense que ça devrait plutôt être ajouté comme fils de include dans l'arbre DOM, pour pouvoir en plus jouer avec avec Javascript...
Je suis sûr qu'il y a moyen de faire des trucs sympas avec ça :p. C'est d'ailleurs quelque chose qu'on peut faire avec "AJAX" me semble t'il, mais on perd dans ce cas la compatibilité avec les navigateurs non javascript...

> Rendons hommage au html à la papa: un language de balisage pas propre, mais qui a fait beaucoup pour le web
Il a quand même fait la première guerre des navigateurs et est selon moi une des principale cause de ce que certains appellent "la nouvelle guerre des navigateurs". Si pour toi ça c'est faire beaucoup pour le web...

> Le coté permissif et bordélique du html 3.2 a permis son essort: l'information est toujours accessible, même mal encodée
Ce qui a permis l'essort du C, c'est son côté accessible partout: pour peu que tu fasses pas d'hypothèses trop osées, ça marche sur à peu près toutes les plateformes matérielles. Pourtant, mal encodé, le C passe pas.
Tu vas le dire, oui, mais le C, c'est un truc de bidouilleurs.
Ben oui, mais tu sait, l'époque du HTML 3.2, c'était pas Windows XPVista Noob Powered (c) ou KDE hein... Les noob de l'époque, ils faisaient du Basic aussi. Et ben figure toi que le basic n'est pas le langage le plus permissif au monde...
Aujourd'hui, les noob, c'est NVU.
Tu nous dit que parce que les noobs d'avants arrivaient facilement à faire du HTML et que les noob d'aujourd'hui n'arrivent pas à faire du XHTML, c'est la preuve que le XHTML est plus complexe. Non, c'est parce que le niveau des noobs a baissé (et avant que ça parte en troll, oui, c'est triste, et non, ce n'est pas un commentaire méprisant. J'ai moi même été un noob, et un moins bon noob que ceux qui débutaient avec les cartes perforées... Les noobs de l'époque des PDPs étaient certainement meilleurs que moi aujourd'hui...)

> tout en déplorant parfois son coté plus exigeant.
Et moi, je déplore le côté laxiste du HTML. Quand tu passes deux heures à débugger ton code javascript (pas un truc de 5000 lignes de code hein) alors que le problème se situait dans une malheureuse faute de frappe dans le code HTML (alors qu'en XHTML, le navigateur m'aurait tout de suite signalé l'erreur), c'est clairement qu'il y a un problème avec le HTML, non ?

> Parfois je me prendrai presque à regretter le bon vieux temps où le monde était dominé par Netscape 3...
Réactionnaire ;)

Vas tu arrêter de te répondre à toi-même ? C'est horripilant :)
Bon restons constructif: j'ai honte, mais à t'entendre, je crois que je me suis laissé berner par les "on dit"... (on fait, non, ce qui m'a fait fuir en courant de ségolène, c'est son délire sur le drapeau français). Je crois que je vais aller voir son programme à la loupe...
Ce qui m'attirait (et m'attire toujours d'ailleurs) chez Bayrou, c'est sa proposition de réforme des institutions (et je ne pense pas être le seul), et je croyais sincèrement qu'il était le seul à être sur ce créneau. Mais si Ségo le propose aussi, ça va donner un vrai choix très intéressant (manquerait plus que quelqu'un vienne me dire que Sarko le propose aussi tiens). Dommage qu'on en parle aussi peu du côté des sympatisants du PS... (dès que j'entends les sympatisants du PS défendre Ségo, c'est dans 80% des cas pour rattraper ses bourdes du genre le drapeau français et les faire passer pour des traits de génie incompris en les déformants (ne pas reconnaitre ses erreurs, ses doutes et ses faiblesses est quelque chose qui m'horipille et que je prendrais en compte lors de mon vote, soi dit en passant...), 15% pour son programme social contre le maichant Kapital (la preuve, ça commence par un K -->[]), et 5% pour la défendre contre le soi disant sexisme ambiant - ou pour sa vie privée)
Par contre, si tu as dit n'importe quoi, je te moinsse à vue ><

> les partis déciderons pour les consignes de vote
Comment décidera le PS ? (pas un troll, une vraie question)
Ségo décidera unilatéralement ? Les militants feront un vote rapide ?

> Bref, le système "explose" (c'est une image).
Je vois pas tellement de différence avec la cohabitation...

> Il convient de distinguer les consignes de votes et les ralliements.
Là par contre, ça me semble tiré par les cheveux
-> Soit le PS appelle à voter Sarko. Ça me semble plutôt absurde, sans être politologue
-> Soit le PS appelle pas à voter ("je veux pas avoir à choisir entre la peste et le choléra"). Tout aussi absurde à mon sens (ils n'ont pas dit ça en 2002 mais ont bien appelés à voter Chirac)
-> Donc, en cas de second tour UMP/UDF, admettons que le PS appelle à voter Bayrou. C'est ce qui me semble le plus logique (soyons matheux: si tu n'acceptes pas cette hypothèse, pas la peine de lire plus loin)

Donc, vois tu franchement le PS soutenir Bayrou d'un côté, et de l'autre le plomber complètement en criant haut et fort "non, nous ne participerons pas à son gouvernement !" ? C'est toi même qui a dit (ne me demande pas de te citer ce post, tu as trop posté ces derniers temps ;). Si tu déments, très bien, j'accepte ce démenti même s'il me semble de mauvaise foi) que l'autre en face ne se priverait pas d'utiliser une telle arme - et que sa victoire est assurée, avec cette arme. Puisqu'il me paraît absurde que d'un coté le PS soutiendra Bayrou et que de l'autre le PS fournisse la victoire à Sarkozy, presque personne au PS ne refusera haut et fort la proposition de faire partie du gouvernement Bayrou.
Allons plus loin dans ce raisonnement. Il est certain que du côté de l'UMP, on criera haut et fort "non, nous n'iront pas chez Bayrou" (d'autant plus que ça permettra d'utiliser l'argument "voter Bayrou, c'est donc voter un gouvernement de gauche avec un président centriste mou"). Donc, du côté du PS, autant promettre le plus de "oui, nous viendrons dans votre gouvernement", justement pour que la gauche soit effectivement le plus représenté possible (tu peux me traiter de naïf sans que je proteste, mais je vois très mal Bayrou dire: ce ministère ira à xxx du PS pour finalement y mettre quelqu'un de l'UMP). Si effectivement (ce qui est très probable) personne de droite n'acceptera (pendant la campagne au moins) et que Sarkozy met la pression sur Bayrou pour qu'il présente un gouvernement (ce qui est aussi fort probable), Bayrou sera bien forcé d'aller chercher là où il y a du monde: à gauche.
Donc, oui, soutien implique ralliement.

Pour finir, avant de monter sur tes grands chevaux:
- Je ne dit absolument pas "pour voter à gauche, votez Bayrou". Je suis à 200% d'accord avec toi quand tu dis que pour un gauchiste, le vote utile Bayrou est une imposture (par contre, le Bayrou est une énorme imposture tout court, si tu pouvais éviter s'il te plait...). Si vous être gauchistes, votez à gauche.
- Je suis parfaitement conscient que ce raisonnement est à peu près logique et rationnel, et que ces deux mots ne sont pas du tout présents en politique ;). Toutefois, je pense que c'est une bonne première approximation (ceci n'engage que moi, et ceux qui me plusseront. Oups, -10)

Donc, les libéraux essayent de s'approcher le plus possible de cette anarchie, tandis que les anarchistes ne veulent que 100% d'anarchie sans compromis.
Comme la différence entre la gauche et l'extrème gauche quoi (même si on voit la LCR se présenter aux élections :-/)
Donc, les anarchistes, c'est l'extrème droite.

--->[]