Shuba a écrit 439 commentaires

Un article du monde analyse plus en profondeur ce débat:
https://www.lemonde.fr/les-decodeurs/article/2022/01/04/covid-19-la-majorite-des-patients-en-reanimation-sont-bien-non-vaccines_6108190_4355770.html

Un autre plugin vim qui sait faire LSP est YouCompleteMe. Je l'aime bien pour son interface de complétion très puissante même sur du simple texte.

Mais std::vector<std::vector<int>> n'est pas du tout équivalent à une matrice, car la longueur de chaque "ligne" peut changer. Tu peux probablement montrer que pour toute structure de donnnées qui permet une longueur de "ligne" variable, il existe une structure à longueur de "ligne" fixe plus efficace.

Du coup je ne vois pas ça comme une différence entre maths et info, mais plutôt comme une structure de donnée trop flexible par rapport à la représentation mathématique cherchée.

Ça peut se contourner en n'obtenant qu'un chiffre du secret à la fois. Mais c'est pénible vu que du coup ça demande 64 interactions manuelles.

Tu serais surpris, j'ai déjà eu un collègue malvoyant qui faisait de la vision par ordinateur avec succès.

Je précise: la liste des unités est vue avec une restriction dans une zone rectangulaire reproduisant la zone qu'un joueur humain peut voir. Cet ajout est très important par rapport à la version d'AlphaStar de janvier dernier (celle qui battait les joueurs pro), qui pouvait voir toutes les unités de la carte simultanément.

l’intelligence artificielle regarde la partie sur un écran avec sa caméra, comme un humain avec ses yeux ;

C'est incorrect, la figure 1a de l'article de DeepMind explique

AlphaStar observes the game through an overview map and list of units.

L'overview map correspond à la minicarte, la liste des unités c'est le type et la position de chaque unité, on est très loin de voir comme un humain. Ce n'était pas le but, le problème est déjà assez dur comme ça.

Dans mes souvenirs debian avait choisi de mettre par défaut une option qui permettait de ne pas tuer les screens et autres tmux des utilisateurs, pour ne pas perturber la communauté habituée à fonctionner avec screen.

Je viens d'aller sur https://www.trainline.fr et j'ai toujours la même interface.

Ok c'est peut-être pas bien intégré dans la 18.04 que j'ai au boulot. Merci du retour.

Je me suis mal exprimé, le paquet est présent et installé sur ma machine, mais le service dbus n'est pas lancé, il faut que je cherche ce qui est censé le lancer…

J'ai vu le changement, j'ai installé awesome rss, plus de problème.

À noter que d'après ce commentaire sur hacker news, cette version de firefox inclut la possibilité d'utiliser un autre sélecteur de fichier que celui de GTK3, une bonne nouvelle pour les utilisateurs de KDE.

Il s'agit de lancer firefox avec la variable d'environnement GTK_USE_PORTAL=1. Ceci ne marche a priori que si l'on a le service dbus xdg-desktop-portal-kde lancé, ce qui n'est pas le cas sous la Kubuntu 18.04 sur laquelle j'ai testé, mais peut-être que vous aurez plus de chance sur une autre distribution.

Est-ce qu'en pratique la limitation

risque de présenter un état indéfini (pas de résultat électoral)

n'est pas extrèmement improbable? J'ai déjà entendu parler de
systèmes de vote où on organise un vote par Condorcet, et s'il n'y a pas de vainqueur de Condorcet on choisit aléatoirement entre
les mieux classés par le vote de Condorcet, l'idée étant que cette situation n'arrive pas en pratique.

Il me semble que "Most popular platforms" parle des plateformes cibles pour le code développé. La forte présence de linux peut ainsi s'expliquer par les codes serveurs.

Un article récent a montré que si on assignait des classes aléatoires aux images dans un problème de reconnaissance d'images, les architectures actuelles arrivaient à apprendre parfaitement l'ensemble d'apprentissage (mais évidemment, ça ne marche plus ensuite sur d'autres jeux de données). Donc les réseaux de neurones actuels ont en fait un souvenir assez précis de leurs données d'entrée.

J'utilise Mattermost au boulot, c'est pas du tout la même visée que Matrix.org. Mattermost cherche uniquement à faire un chat interne pour une boite (ce qui le rapproche plus de Slack si j'ai bien compris), alors que Matrix.org essaie de s'attaquer à un peu tous les cas d'utilisation, du salon public style IRC au groupe privé.

Du coup d'un point de vue technique la plus grosse différence c'est que Mattermost c'est juste un serveur, alors que Matrix.org c'est un réseau avec de la fédération.

Sinon pour un retour sur Mattermost au boulot, on en est plutôt content, mais le fait qu'il n'y ait qu'un client electron n'est pas toujours marrant quand on est habitué à des interfaces un peu plus réactives…

Bon je précise, je ne l'ai pas pris comme une insule :)

PS: je ne pense pas être une grosse quiche en stats, mais j'avoue que la phrase m'avait fait sourire parce que je n'ai aucune idée de ce qu'elle voulait dire.

Et c'est un peu ma faute, j'ai voulu condenser au maximum. J'ai essayé d'être plus clair plus bas.

Oui ce n'est pas facile de faire clair, mais on peut essayer.

En gros Alpha Zero utilise un réseau de neurone pour évaluer deux choses:

• l'issue probable de la partie à partir d'une certaine position
• les probabilités de chaque coup qui donnent le meilleur résultat

L'idée de la recherche arborescente de monte-carlo est d'explorer l'arbre des coups possibles de manière randomisée, en explorant avant tout les coups les plus probables. L'algorithme permet de progressivement raffiner les probabilités des coups. Idéalement avec un temps de calcul infini il donne un coup très bon à jouer, mais c'est beaucoup trop cher.

L'idée dans Alpha Zero c'est de faire en sorte que le réseau de neurones apprenne les probabilités qui seraient émises par la recherche arborescente de monte-carlo, et d'utiliser le réseau de neurone pour accélérer l'évaluation de la recherche de monte-carlo.

C'est un peu la poule et l'oeuf ce problème, mais du coup la façon dont ils s'en sortent c'est de considérer que la recherche arborescente de monte-carlo est un opérateur d'amélioration du réseau de neurone, et ils cherchent une version du réseau qui soit un optimum de cet opérateur d'amélioration, donc un point fixe.

Schématiquement on peut dire que si f est l'opérateur d'amélioration, et x les paramètres du réseau de neurones, ils cherchent un point tel que x = f(x). Pour faire ça ils utilisent une itération au point fixe, avec la suite x_n = f(x_{n-1}).

Seuls sont implémentées les règles des jeux, le deep learning et les ajustements automatiques des réseaux neuronaux faisant le reste.

Ce serait dommage de réduire Alpha(Go) Zéro au côté deep learning, l'idée d'apprendre une fonction de probabilité des coups par itération au point fixe sur la recherche arborescente de monte-carlo est quand même très très jolie. Surtout que si on en croit les auteurs, c'est ça qui permet de faire un apprentissage de zéro, par rapport à un apprentissage par renforcement qui n'est pas stable.

Par contre, les bounds-check risquent de compliquer l'analyse du programme et de gêner significativement d'autres optimisations.

Tout à fait, en particulier si les bounds-check ne sont pas pas prouvés redondants ça empêche le compilateur de produire du code vectorisé.

OpenBLAS ( C )

OpenBLAS c'est essentiellement des kernels de calcul en assembleur, optimisés pour chaque micro-architecture des processeurs Intel.

Attention à ne pas confondre la super-résolution, qui permet de fournir des détails plausibles, avec la capacité à effectivement retrouver les détails intéressants en zoomant énormément dans une image, comme on le voit dans les séries. Le deuxième n'est évidemment pas possible si l'info n'est pas présente initialement (par exemple on ne pourra jamais reproduire le numéro de plaque d'immatriculation exact si la plaque mesure en fait 2 pixels dans l'image). Ce qui n'empêche pas de reconstruire un numéro de plaque parfaitement raisonnable avec un algorithme de super-résolution. Au passage je me dis que ça pourrait être le point de départ d'un sujet de SF: fausse accusation d'une personne parce que de la super-résolution a été utilisée sans y réfléchir correctement.

Avec un rustc plus récent:

fn main() {
    println!("{}", 1 + "3a");
}

$ rustc --version
rustc 1.15.1 (021bd294c 2017-02-08)

error[E0277]: the trait bound `{integer}: std::ops::Add<&str>` is not satisfied
 --> main.rs:2:20
  |
2 |     println!("{}", 1 + "3a");
  |                    ^^^^^^^^ the trait `std::ops::Add<&str>` is not implemented for `{integer}`
  |
  = help: the following implementations were found:
  = help:   <u32 as std::ops::Add>
  = help:   <&'a u32 as std::ops::Add<u32>>
  = help:   <u32 as std::ops::Add<&'a u32>>
  = help:   <&'b u32 as std::ops::Add<&'a u32>>
  = help: and 90 others

error: aborting due to previous error

Et le message d"erreur vient avec des couleurs qui rendent la lecture très agréable.

En effet le couple callgrind + kcachegrind est assez sympa, mais ça reste très long de faire tourner le code sous callgrind.

Souvent je trouve qu'un bon usage de perf avec flamegraph est un bon compromis.