THE_ALF_ a écrit 531 commentaires

Est-ce que gcc aurait rencontré les mêmes limites que le compilateur utilisé (MSVC)?

C'est surtout un paradoxe pour les personnes qui ne sont pas au fait des technologies actuelles utilisant le charbon…

Les médias focalisent surtout sur l'énergie, qui est certes encore la première utilisation, mais oublient souvent leur utilisation chimique (autre que brûler le charbon donc, c'est à dire comme agent réducteur). Donc oui, derrière les centrales à charbon, il y a une très grande partie de la métallurgie et des ciments, et pour ces domaines la transition est plus compliquée (mais pas impossible).

Merci, l'article est assez clair et facile à lire :). Spoiler: le papier d'origine de Dunning-Kruger s'appuie sur un artefact statistique grossier, et cela a déjà été démonté dans des papiers plus sérieux (mais personne n'en parle).

J'aime bien la conclusion :

the paper’s title may still be appropriate. It’s just that it was the authors (not the test subjects) who were ‘unskilled and unaware of it’.

(Le titre de l'article serait encore correct. Cependant, ce sont les auteurs (et non les personnes testées) qui seraient "incompétents et inconscientes de l'être".)

Ben non, dans l'article référencé, ça parle explicitement d'un logiciel :
- permettant la reconnaissance faciale "à porté de click",
- de "détecter et d’extraire des personnes et objets d’intérêts a posteriori",
- que l'on demande aux agents d'utiliser en toute discrétion car il n'a pas été déclaré à la CNIL

C'est surtout un principe exactement opposé. Le but de l'impôt est de redistribuer une partie du capital au profit de l'ensemble de la société (santé, éducation, infrastructures, aides sociales…), celui de l'actionnariat et de le redistribuer 1) au profit d'une minorité d'investisseur (et non de tous), 2) pour des gains personnels (et non collectifs).

Un point agréable pour systemctl en mode desktop est l'utilisation en mode user. Cela permet simplement de gérer les démons "user". D'autant que l'on a des scripts tout faits dans /usr/lib/systemd/user sans avoir a inventer grand chose. On active ce que l'on veut avec 'systemctl --user enable trucmuche', on le lance la première fois avec 'systemctl --user start trucmuche'. Et puis c'est tout, on a activé nos démons pour utilisateurs.

Typiquement, je l'utilise pour deux choses: emacs (qui permet d'avoir le emacs tournant en mode démon à tout moment (auquel on se connecte instantanément par emacsclient) et jupyter-notebook (pour lancer automatiquement les notebooks accessibles via browser en localhost)

Simple, et homogène avec la gestion des démons "system"

La révolution proposée est juste de remplacer les packages par des exécutables statiques… En avant vers le passé?

Est-il seulement possible d'envisager ceci pour des exécutables GUI, sans dépendances aux toolkits correspondants (GTK, QT, etc.) ???

Je n'avais pas même donné plus d'attention que ça à ces NFT, y voyant essentiellement un énième avatar de système de Ponzi, bitcoin-style saupoudré d'une pincée art numérique.

Mais l'arnaque est encore plus grossière et débile que ce que j'aurais imaginé, avec cette notion de "propriété". J'avais naïvement pensé qu'il y avait un véritable fichier échangé dans tout ça, du genre protégée avec une clé privée pour le "propriétaire" et une clé publique pour la montrer aux autres (et donc pouvoir se vanter devant tout le montre que oui, on possède la chose, mais allez-y regardez-la). Ben non, juste une promesse du genre "si si c'est à vous, promis juré, allez voir votre œuvre sur ce lien qui m'appartient"…

Il ne s'agit pas d'interdire une publicité qui se destinent à un certain profil (liés aux orientations sexuelles et à la religion), mais d'interdire l'utilisation de certaines données privées pour cibler directement les gens ayant ce profil.

Bref, tu à le droit de faire de la publicité pour ton appli de gays cathos, mais tu n'as pas le droit d'utiliser une base de donnée donnant les orientations sexuelles et religions de plusieurs personnes pour envoyer spécifiquement ta pub aux gays cathos (défense de la vie privée).

Article assez hallucinant. Il explique assez bien en quoi les algos d'apprentissages sont inefficaces (ça permet de reproduire ce sur quoi ils sont entraînés, mais sans chercher à comprendre pourquoi ils marchent, et du coup ce n'est pas généralisable)… et en déduit qu'on n'as plus besoin de comprendre vu que ça marche.

Belle philosophie :-/

Je pense qu'il y a aussi un aspect fondamentalement différent entre les utilisateurs Linux et les utilisateurs de systèmes propriétaires.

Quand on est sous Windows/MacOS/Android/etc., on est avant tout habitué à être un consommateur. On a acquis (gratuitement ou non) le logiciel-produit xy auprès du fournisseur XY. Si celui-ci ne fonctionne pas correctement, on se plaint auprès du service client pour qu'ils règlent le problème.

Quand on est sous Linux/xxxBSD/etc., on est avant tout habitués à être des utilisateurs au sein d'une communauté. On utilise le logiciel-libre xy fournis par des développeurs-mainteneurs-empaqueteurs XY. Si celui-ci ne fonctionne pas correctement, on fait remonter à la communauté les infos concernant le problème pour qu'il puisse être corrigé.

Indépendamment des compétences respectives (il y a des non-développeurs dans le monde Linux, et des développeurs dans le monde Windows…), il y a une philosophie fondamentalement différente sur la position que l'on a par rapport aux logiciels utilisés.

Attention, l'article cité dans ce journal fait surtout apparaître que le gros problème statistique touche surtout les études non-randomisées, car c'est justement cette randomisation qui permet de limiter le fameux "facteur de confusion" qui mène à l'observation d'autant de faux-positifs. Mais effectivement, ce qui semble apparaître, c'est que la "randomisation" est nécessaire, mais pas suffisante.

À partir de quand un traitement de données devient-il "un peu sérieux"?

Facile. À partir du moment où tu commences à te maudire de ne pas avoir utilisé Python, justement ☺

L'idéal serait de toujours supposer qu'un traitement de de donné risque de devenir sérieux à un moment où à un autre,et donc de toujours utiliser l'outil adéquat, juste au cas où, même si cela semble overkill sur le moment. Malheureusement, il est difficile d'avoir ce genre de réflexe, je le reconnais…

Tout à fait. Il s'agit surtout de la conversion automatique de ce que tu rentre en un format donné. Du genre tu tapes "1", il reconnait que c'est un nombre, si tu tape "un", il reconnait que c'est du texte, et dans chaque situation, le type de la cellule est automatiquement choisi.

Et effectivement, c'est très pénible dans un certain nombre de cas, et je ne suis pas sur que ce soit désactivable (mais je serais heureux d'avoir tord…). Le pire de la détection est justement celle qui reconnait (ou croit reconnaître) une date. Dans un des problèmes rencontré, tu veux le texte "MARCH-1", tu te retrouve avec la date du premier mars.

J'ai testé avec libreoffice (la seule chose que j'utilise, mais j'imagine que c'est pareil avec excel), tu as beau désactiver la correction automatique, la détection automatique du type n'est pas désactivable globalement, elle. La seule solution est de régler le type de la cellule avant d'y écrire. C'est un point à savoir, qui n'est pas forcément évident, et je ne suis pas sur que grand monde ne le sache.

L'exemple donné dans l'article montre bien le problème. Si on ne force pas le type de la cellule en avance, la seule manière que j'ai trouvé de rentrer le texte "MARCH-1", c'est de taper 'MARCH-1 (avec un ' avant le texte). Mais il y a une subtilité: si on tape 'MARCH1, on se retrouve avec le texte "'MARCH1"… le ' est conservé dans le texte! Ici, MARCH1 n'est pas vu comme une date, donc la logique retenue est que l'on voulait conserver le ' devant le MARCH1. Bref, si on veut entrer "MARCH1", il faut l'entrer tel quel, sans le '… simple non? Et bien entendu, je pense que tout cela dépends de la localisation du tableur (que je force en anglais, sinon c'est trop le merdier pour faire reconnaître correctement les nombres, à cause de la différence entre l'utilisation du point ou de la virgule décimales en fonction des situations).

Question subsidiaire: comment rentrer le texte "'MARCH-1" dans une cellule, sans forcer au préalable le format de la cellule en "texte"? (personnellement, je n'ai pas trouvé).

Est-ce que cela pourrait être intéressant pour la compression de données scientifique ça?
Je pense notamment à la compression de donnée dans des formats de type hdf5. On peut se retrouver avec des gros blocs de données de dimension variable, et si ce n'est pas trop random ou bruité, on doit pouvoir se retrouver avec quelque chose de proche de données vidéos.

Ce type de compressions vidéo a-t-il été envisagé pour compresser des données (hdf5 fait du classique, de type gzip)? Serait-ce adapté (il faut pouvoir compresser, mais surtout décompresser rapidement, et pouvoir accéder rapidement à des données à un endroit particulier).

Cela n'a pas l'air très convaincant… À part quelques arguments très enflammés sur le "freedom", aucune info technique.

Au mieux, j'ai trouvé ça comme info. Quelques avis (tweeter) rapportés:

• “3 Signs Your Money Is About To Get Stolen By #FreedomPhone #Grifter 1)The website provides no phone specs or details 2)Its being sold on a basic Shopify store – whose known for banning conservatives. 3)All parts are from China with software developed from unknown companies”

• So you're telling me a "Freedom Phone" is basically a generic Android Device, with Parler, Telegram, Rumble, OAN, Newsroom, Duck Duck Go and a VPN preloaded? Wow.

… et j'avoue avoir pensé le même genre de chose en voyant ce site.

Oui c'est possible, mais c'est vraiment pas l'outil adapté.

Au minimum, il faut entrer une première colonne avec tous tes x, puis entrer une deuxième colonne avec ta formule. Rien que là, on est avec des manip de l'ordre de la minute pour avoir une courbe, là ou une calculatrice demande des manip de l'ordre de la seconde.

Oui, mais là on parle du "passe sanitaire" que l'on peut être mené à montrer pour un oui ou pour un non, à n'importe qui, et qui a donc été vendu comme "0% données privées diffusées".

Rien n'empêche d'avoir un vrai passe sanitaire respectueux des données personnelles, qui se contente de lier un nom à "OK/KO" pour rentrer dans un lieu de spectacle ou autre, tout en continuant à devoir montrer un certificat médical dans les cas plus stricts, et à des personnes assermentées (cas où l'on doit de toute manière délivrer d'autres infos personnelles et officielles, via un passeport par exemple).

A mais pas du tout, il en parle justement. Il indique le fait que l'on ait la possibilité de relier un nom aux modalités de vaccinations (date, marque du vaccin, nombre de rappels) donne plusieurs informations médicale (pas eu besoin de rappel ⇒ a déjà contracté le covid, a eu besoin de 3 doses ⇒ est immunodéprimé, a eu droit à son vaccin très tôt ⇒ citoyen "prioritaire").

Il y a bien un accès donné un certain nombre d'infos clairement médicales.

Effectivement, ça marche très bien. Quelle magie opère qtcreator sur ce fichier, et que n'arrives pas à gérer qmake?

Il manque les infos pour compiler le package à partir de github, mais c'est simple. Sous Debian SID:
1. installation de libqt5opengl5-dev et qt5-qmake (et toute la ribambelle qui vient avec; il y a peut-être besoin d'autre chose, mais qui était déjà installé chez moi)
2. qmake (si toutes les lib sont là, ça devrait passer)
3. make

Par contre il doit falloir des librairies assez à jour. La compil échoue avec Ubuntu focal.

Le but n'étais pas de faire simple :-p

Par contre je suis surpris. J'avais sorti numpy en pensant que ce serait forcément tordu vu qu'adapté pour les tableaux numériques et pas pour le texte… je ne connaissais pas les chararray.

Effectivement, passer par une boucle for explicite ou une compréhension de liste ne vas pas vraiment impacter la performance. Par contre, l'intérêt de la compréhension de liste est que l'on peut facilement basculer dans le monde des générateurs: il suffit de remplacer les [..] par des (..).

Tu risque vite de te retrouver avec des scripts inutilisables car trop lents ou trop en gourmand en mémoire si tu ne fais pas attention et fait n'importe quoi. Ceci-dit, utiliser les méthodes très "pythoniques" telles que les compréhension de listes ou les générateurs plutôt que faire de grosses boucles sur les itérables doivent te permettre de gagner sur tous les tableau: ce sont des écritures assez intuitives à lire et écrire (mais différentes de ce qu'on fait en C, donc il faut s'habituer), mais qui ont été /a priori/ optimisées.

Écrire du code "pythonique" n'est pas du snobisme, c'est utiliser python tel qu'il a été pensé, et donc de manière /a priori/ optimisée. C'est dans ce sens là qu'il faut prendre l'écriture "la plus claire".

Ah, mais si tu veux de l'alambiqué, il y a toujours moyen de s'arranger:

import numpy as N

@N.vectorize 
def starts_with(x, val): 
    return x[0] == val

liste_a = list(N.array(some_list)[N.where(starts_with(some_list,"a"))])
liste_b = list(N.array(some_list)[N.where(starts_with(some_list,"b"))])