fmaz fmaz a écrit 494 commentaires

Quand on voit le code LaTeX que certains pondent, il me semble illusoir de vouloir écrire un analyseur syntaxique LaTeX -> autre chose.

Je ne mets pas en doute le fait que la grande distribution n'est pas philanthrope.

Ce que je dis, c'est qu'organiser la pénurie n'apporte rien. Le fait d'avoir 23 items suffit à être sur que (presque) personne ne finira la collection.

Tu n'es pas le premier à sortir cet argument qui fleure bon le « la grande distrib, c'est que des rapaces qui cherche rien qu'a nous entuber ». C'est peut-être bien le cas, je ne sais pas mais pour le coup, s'ils organisent volontairement la pénurie, ce sont des cons.

Du temps où j'allais régulièrement faire mes courses dans la grande distribution, je ne le faisais qu'une, voir deux fois par semaines.

Donc même en rapportant 3 aimants à chaque fois, il m'aurait quand même fallu en moyenne 29 semaines soit un peu plus de 6 mois pour être à la moyenne. Je ne me suis pas amusé à calculer l'écart type de ce genre de chose mais pour avoir une probabilité assez forte d'avoir la collec complète, il faut passer encore plus.

Dans 6 mois, il y aura eu la rentrée, Halloween, des soldes et noël arrivera à grand pas.

Après, à coup de paradox des anniversaires, à partir du moment où on a 5 aimants (répartis uniformément), on a plus d'une chance sur deux d'avoir deux cartes identiques. Donc bon...

:)))

Je suis drole des fois.

Je me suis arêté à « icosaedre tronqué » en me disant que ça serait marrant 20 magnets hexagonaux et 12 magnets pentagonaux à recoller ensemble pour faire un ocisaedre tronqué.

Donc oui, n=23. Enfin, bon, j'apprend quelque chose. Pour moi, ils auraient pu être 42 ou 18 que ça aurait été pareil.


Donc, je suis d'accord avec les 86

Si on reprend ce que j'ai écrit,

E(i)=1*P(i,1)+2*P(i,2)+3*P(i,3)+...
et
P(i,p)=(i/n)^(p-1)*(n-i)/n

donc
E(i)=(n-i)/n*\sum_{p=1}^\infty p.(i/n)^{p-1}

Si on pose f(x)=\sum_{p=1}^\infty p x^{p-1}, E(i)=(n-i)/n*f(i/n).

Reste à calculer f(x).

Attention, il faut justifier des trucs mais en agitant suffisamment les mains.
On pose F(x)=\sum_{p=1}^\infty x^p, On remarque que la dérivée de F(x) est f(x). Or F(x) est la somme d'une série géométrique et F(X)=x/(1-x). Donc f(x)=1/(1-x)².

Si on remplace, on trouve E(i)=(n-i)/n*f(i/n)=(1-i/n)*1/(1-i/n)²=1/(1-i/n)=n/(n-i).

Il est étrange ton icosaedre tronqué (anciennement appelé balon de foot).

Chez moi, un icosaedre a
- 20 faces pentagonales
- 12 sommets
(- 30 aretes)

Si on tronque chacun des sommets, on crée une face au niveau de chaque sommets.

On obtient donc 32 faces.
- 20 faces hexagonales;
- 12 faces pentagonales.

Ceci dit, je n'ai pas vu le truc que tu cherches à construire.

Bonjour,

Réponse courte: 130

Réponse longue.

Notons n le nombre de cartes a obtenir (ici n=32).

Si tu as i cartes, la probabilité que tu obtiennes une nouvelle carte en exactement p coup est: P(i,p)=(i/n)^(p-1)*(n-i)/n. En effet, au premier coup, pas de bol (avec proba i/n). Au second coup, pareil. Au troisième, pareil. Ainsi de suite jusqu'au p-ième coup ou enfin, on trouve la carte avec proba (n-i)/n.


Le nombre moyen de coup pour avoir une nouvelle carte est donc E(i)=1*P(i,1)+2*P(i,2)+3*P(i,3)+... On montre que dans le cas qui nous concerne, E(i)=n/(n-i). Ce résultat n'est pas choquant. Si on a aucune carte, il faut en moyenne attendre 1 coup. Plus on a de carte, plus il faut attendre longtemps et si on en a n, il faut attendre n/0= très beaucoup.

Le nombre de coup moyen pour obtenir toutes les cartes est donc E(0)+E(1)+E(2)+...E(n-1)=n(1/n+1/(n-1)+1/(n-2)+...+1/3+1/2+1).

Si n est très grand, on prouve que ça tends vers n.log(n).

Attention, je vais peut-être raconter des conneries ou tout du moins être dangereusement imprécis.

Le "rationnel" vient des fractions rationnelles.

En gros, si tu prends une fraction rationnelle que tu développes, tu obtiens un mot infini qui se reconnait très facilement avec un automate fini. Par exemple, 123/13=9.(461538)*.

Pour les fractions d'entier, ça reste quand même très simple mais si on considère des trucs plus évolué à base de fraction polynomiales, on obtient des mots qui correspondent bien aux automates finis.

Pour ce qui est des financements de post-doc, je ne peux pas t'aider mais une remarque en passant.

Les bourses de thèse du ministère sont des bourses d'études. D'un certain point de vue, faire une thèse, c'est encore étudier. Donc pas de cotisation. Sauf que ces bourses permettent quand même de toucher des allocations chômage.

De ce que j'avais lu, il y a une jurisprudence. En gros, un type a voulu toucher des allocations chômage. On lui a répondu: pas de cotisation pas d'allocation. (De toute façon, l'état ne cotise jamais.) Il a porté plainte et il a gagné. Le problème, c'est qu'il n'y a bien évidemment pas de ligne budgétaire pour ça. Donc, les allocations chômage sont prisent sur le budget des allocations de thèse. En gros, si un docteur d'un labo X demande des allocations chômage, le labo X a une bourse de moins l'année d'après.

Les labos et les facs n'ont donc absolument pas intérêt à ce que ça se sache mais cça existe.

L'un des argument de T'so est le suivant:
Si on écrit 300To de données sur le disque, il faut bien s'attendre à un moment à ce que le disque écrive ces 300To. Ça, ça prend du temps. Si fsync prend du temps, c'est qu'il y avait beaucoup à écrire, c'est tout.

Je trouve cet argument plein de bon sens.

La license globale, elle va de toute façon être proposée, à terme, par les fournisseurs de contenus.

Souvenez-vous,
- l'abonnement internet ;
- le téléphone portable ;
- le téléphone fixe.

Il fut un temps où personne n'aurait imaginé qu'on puisse avoir un forfait illimité.

À partir d'une certaine masse critique, il devient rentable de proposer de l'illimité. Ça sera pareil pour les fournisseurs de contenus. Ils vont juste s'arranger pour que l'offre illimité couvre la somme de tout ce que les gens utilisent. C'est tout.

Il n'existe pas de vrai prouveur automatique utilisable. Donc si on veut prouver des choses à l'aide de logiciels, on a deux choix:
- faire un prouveur automatique de trucs très simple ;
- faire un logiciel intéractif qui permet, avec le cerveau de l'utilisateur, de prouver des trucs compliqués.

Un assistant de preuve, c'est la seconde approche. Si tu veux montrer « A et B », il va te demander de prouver « A » puis de prouver « B ». Je connais des personnes qui font de la preuve d'algorithmes pour l'arithmétique flottante et avoir un logiciel qui « n'oublie pas » de cas, c'est précieux. Par ailleurs, un assistant de preuve permet de démontrer automatiquement des morceaux de preuves, ce qui rend la vie de l'utilisateur (un peu) plus facile.

Ton cadeau à toi, ça sera un peu de tolérance.

Je ne sais pas comment va le prendre l'auteur du journal mais de mon côté, j'ai pretiquement arrêté d'écrire dans des forums de discussion à cause de remarques de ce genre. J'ai longtemps été complexé par mon orthographe. Je faisais beaucoup d'efforts et dans ce contexte, ce genre de remarques me faisait mal. Au bout du compte, pour me protéger, j'ai arêté d'écrire.

Son texte n'est certe pas parfait mais vu sa, longueur il ne l'a clairement pas écrit en 30 secondes. Il n'y a pas de !!!!!!!!!!!!!!!!!!!!!!!!!!! et autres ;-))))))))))) partout. Le texte est aéré et globalement assez agréable à lire.

Ce genre de remarques à sa place ans le cas d'une dépèche ou d'un journal bâclé, pas dans le cas présent.

Après, certains se plaindront que le site n'est plus assez vivant, que c'était mieux avant, que gna gna gna. Mais franchement, ça ne donne pas envie d'écrire.

Prout

Si tu m'avais sorti un truc à coup de fold, map et autres
itérateurs, j'aurais pu comprendre mais là, c'est
franchement que de la syntaxe. Je ne nie pas que la
syntaxe, c'est important mais ce n'est plus du champ
fonctionnel/impératif.

Que le programme soit choisi pour mettre en valeur les qualités de llvm, c'est de bonne guerre. En revanche, l'argument « ho et la, machine virtuelle, tricher... », je ne suis pas d'accord. Pour l'utilisateur, entre taper ./toto et ./titi, c'est du pareil au même. Ensuite, que toto soit une machine virtuelle qui interprete un programme bytecode ou un script python ou un binaire, c'est du pareil au même. Donc si avec des machines virtuelles, on peut toujours avoir de meilleur performances, pourquoi gcc ne s'y met pas ?

Si j'ai bien suivit, c'est lié au bip des machines. Quand quelqu'un vote, la machine fait un bip. Ça sert pour savoir si on a voté et ça permet au gens autour de vérifier que quelqu'un ne vote pas 15 fois. Ce bip, c'est un peu le « a voté » classique. Si on juge ce signal important, il est clair qu'il ne faut qu'une machine par bureau car sinon, on ne sait vite plus quelle machine bip et cela invalide l'utilisé du bip.

Ce n'est pas parce que le système ne permet pas d'interdire vraiment l'accès en écriture à des sous répertoires que cette approche est mauvaise.

À coup de SE-Linux, on doit pouvoir s'arranger pour que le programme foo de puisse écrire que dans
/program/foo
voir dans
/program/foo/config

D'après ce que j'ai compris en lisant des trucs à droite et à gauche, le problème viens du fait que comme ils ont tout réécrit, avant de pouvoir afficher quelque chose, il faut que les bibliothèques soient déjà écrite et qu'elles ne soient pas trop buggée. Donc effectivement, plasma est loin d'être fini et est plus en version alpha qu'autre chose. En revanche, toutes les bibliothèques en dessous sont sont beaucoup plus stable. C'est pour cela que plasma avance vite (comme mentionné ci-dessus).

Si on peut vraiment passer de l'un à l'autre sans perte d'information, pourquoi ne pas utiliser directement le même forma de stockage ?

Il y a deux types de sécurité mentionné ici:
1. les aspects « visible » côté utilisateurs (SE-linux) ;
2. les aspects « invisibles ».

Il est clair que l'aspect SE-linux demande à l'utilisateur de s'y plonger et je comprend que les distributions ne l'activement pas par défaut.

En revanche, pour ce qui est des aspects invisibles, (chroot renforcé, protection de la pile, cacher les process...) je ne vois pas en quoi cela peut géner les utilisateurs ou même les distributions. Il est cependant évident que cette sécurité à un coût en terme de performance et les développeurs noyaux semblent considérer que perdre 5% en vitesse est inacceptable même si la sécurité du noyau s'en trouve nettement renforcée. C'est question de politique.

> Là tu as tout à fait raison, particulièrement sur le fait que
> je passe sous silence des jeux formidables (comme un
> dont je ne me rappelle plus le nom, mais dans lequel on
> faisait "combattre" deux fluides, et qui était tout
> bonnement génial).


Au hasard Tu penses à liquidwar (http://www.ufoot.org/liquidwar/v5) ?

Au début, on parlait du fait que certains langages détectaient les récursions terminales et les optimisaient.

L'exemple de la factorielle est justement un exemple de récursion terminale et certains compilos optimisent automatiquement. C'est donc joli ET efficace.

Maintenant, certains programmes récursifs ne sont pas récursifs terminal. Le compilo ne va pas optimiser mais de toute façon, ça serait dur de le faire.
Un bon exemple de ça, c'est les tours de Hanoï.

La procédure récursive, c'est

déplacer la pile de taille n-1 du pilier 1 sur le pilier 2
déplacer le cercle n du pilier 1 sur le pilier 3
déplacer la pille de tailler n-1 du pilier 2 sur le pilier 3

C'est pas récursif terminal mais c'est joli.

Traduire ça en impératif, c'est pas beau et même si on peut le faire, on obtient un truc aussi lent que la version récursive.




Oui, je sais, si on étudie le mouvement du cercle de taille 1, on peut ausi le faire impérativement mais là, on change complètement d'algorithme.

Tu écris un interpréteur pour ton langage (que tu écris de façon impérative) et tu lui passe en argument le code de ton truc.

Je n'ai pas dis que c'était efficace, j'ai dit que c'était toujours possible.

Pour donner un exemple d'école trop simple.

Si tu codes la factorielle par

fact(n)=
si n=0 then 1
else n*fact(n-1)

On se rend vite compte qu'en fait, on peut la coder

fact(n)=
res=1
for i=1 to n: res=res*i
return(res)

L'avantage de la première version, c'est que c'est plus proche de la définition mathématique. L'inconvéniant, c'est le nombre d'appel récursif qui peut exploser la pile. L'avantage de la second, c'est la pile. L'inconvéniant, c'est que c'est moins proche de la fonction mathématique.

En fait, de façon générale, on peut toujours transformer un code recursif en un code impératif. Il suffit de manipuler une pile et de faire un while qui englobe le tout. Fait sous cette forme, ce n'est pas intéressant. En revanche, certain type de récursion (les récursion terminales) peuvent se coder avec une bête boucle for. De plus, cette procédure de dé-recursifier s'automatise. Certains langages le détectent et optimisent tout seuls.

Les gens utilisent quicksort car c'est un tri en place avec une faible constante.

Heapsort est en place mais fait de gros déplacement dans la mémoire ce qui cause des problèmes dès qu'on veut trier de gros volumes de données.

Merge-sort n'est, par défault, pas en place. Il utilise deux fois plus de mémoire et ça pose des problèmes. On peut en faire un tri en place mais c'est beaucoup plus compliqué.

Dans la vraie vie, quicksort est effectivement plus rapide.


Dans un autre genre. L'algo de multiplication de polynômes qui a la meilleur complexité passe pas de la FFT et tourne en n.log(n). En pratique, à part pour des polynômes vraiment grands (plusieurs milliers de coefs), les gens utilisent l'algorithme de Kartsuba (en n^{3/2}) et des généralisations.