J’ajouterai perso que la théorie sur la sémantique d’un langage, ça devrait largement aider à construire un outillage puissant pour l’écosystème du langage.
L’exemple de l’inférence de type est un cas d’école, je pense : c’est une fonctionnalité très bien comprise théoriquement, qui permet d’aider le programmeur à faire moins d’erreur. La coloration syntaxique, c’est quand même utile d’avoir une grammaire formelle pour l’implémenter, et ces objets sont très bien connus théoriquement. Ça fait partie du baggage de base d’un informaticien. Peut être d’ailleurs qu’un des boulot du chercheur en langage c’est d’essayer de penser à des outils que la formalisation des langages peut aider à concevoir … après tout si c’est plus régulier et plus compréhensible pour les humains, c’est aussi très utile pour les machines pour raisonner sur le programme …
Ah oui pardon, j’ai dû être trompé par « Dans cette partie du texte, quand je parle de "voir un programme comme un objet mathématique", je parle plutôt du code source ». Toujours cette satanée confusion … c’est absolument pas naturel pour moi de considérer le code simplement comme un programme.
On est pas aidé par des expressions comme langage formel. En fait un langage de programmation (ou sa formalisation) est du côté des système formels, un langage formel en fait simplement partie. Le système formel est constitué du couple (langage formel, sémantique), et on est d’accord que la grammaire définit la partie « langage formel ».
Alors la façon dont je définis "un programme" c'est en donnant, par exemple, une syntaxe BNF qui, on est d'accord, correspond bien au choix d'un certain langage de programmation. Mais ce n'est pas à ce moment qu'on définit le langage, c'est seulement ensuite, une fois qu'on a défini ses programmes.
Ça se discute. Tu notes une relation de temporalité (voire de causalité) qui n’existe pas forcément dans le monde mathématiques. On ne définit pas les entiers en donnant tous les exemples d’entiers, et une fois qu’on l’a fait, on définit les entiers. On donne des axiomes qui permettent de décider si un objet du formalisme est ou pas un entier. Par l’axiome d’extensionnalité, à tout prédicat correspond une extension : « Étant donné un ensemble A et une propriété P exprimée dans le langage de la théorie des ensembles, il affirme l'existence de l'ensemble B des éléments de A vérifiant la propriété P »https://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27axiomes_de_compr%C3%A9hension . Mais à chaque propriété sur un ensemble correspond une seule extension … que tu définis « en même temps » que tu donnes la propriété. En complexité, on définit même un problème de décision comme l’appartenance ou pas d’une chaîne à un ensemble. Le prédicat associé à l’ensemble n’est même pas évoqué … En gros dans mon esprit la BNF (le prédicat) définit l’ensemble (le langage). Sauf si tu assimiles l’écriture de la BNF à la définition d’«un» programme, mais c’est pas du tout ma vision des choses. Enfin cette manière de décrire les choses correspond peut être à une vision constructiviste des choses ;).
Sinon je suis entièrement d’accord pour ce que tu dis sur la formalisation, avoir un accord parfait entre la théorie et l’expérience est un acte inaccessible. Cela dit, je pense avoir identifié un truc qui manque dans ton texte : il est considéré comme implicite que le programme est destiné à être exécuté. Du coup la métaphore du « parler » tombe un peu à plat. Quand je fais une requête google, je « parle » à la machine, pourtant je ne la programme pas. Un programme est destiné à être exécuté, et peut être exécuté pleins de fois. ça ne transparaît dans ton texte que quand tu parles de comportement du programme. Ce qui pourrait lever ton ambiguïté d’ailleurs.
(et je poste en l’état parce que j’y ai déjà passé trop de temps)
Je dirai que « les informaticiens ont inventé de nombreuses manières de décrire les programmes qui sont exécutés par un ordinateur » conviendrai dans un premier temps. Tu peux rajouter « souvent ils sont écris sous forme de texte, parfois d’autres formes, ou d’autres formes symboliques (« graphiques » par ex. https://scratch.mit.edu/) ». Dans tous les cas, le formalisme qui permet de les décrire constitue ce qu’on appelle un « langage de programmation ». »
L'idée c'est qu'on peut représenter un programme (dans un langage donné) comme un objet mathématique, et à partir de cela définir le langage.
Je comprend pas. Un programme écrit dans un langage donné est quelque part déjà un objet mathématique. « et à partir de cela définir le langage » euh, on commence pas par définir le langage avant d’écrire des programmes ??? Peut être qu’il faut que tu parles de sémantique (en général) d’un langage de programmation, sinon pareil je pense que ça peut ne pas être clair pour un débutant.
Je propose :
«Les informaticiens apprennent souvent par l’exemple et la pratique (et un prof et ses explications) ce qu’est supposé faire un programme et se forgent une intuition de la signification du code qu’ils écrivent, Ensuite, on essaye de le faire tourner pour voir si « ça marche » … et parfois, « ça marche ».
Les approches formelles s’appuient sur autre choses que l’essai et l’erreur et s’appuient sur la logique et les mathématiques pour décrire le comportement attendu d’un programme (indépendamment de ce qui se passe vraiment quand on le teste). La sémantique formelle (cette fois) d’un langage permet de faire le lien entre chaque programme écrit dans ce langage et ce comportement attendu. Votre boulot est en partie de l’écrire et de l’imaginer.»
Du coup vous vous nourrissez de la rigueur des maths pour détecter d’éventuels problèmes, et le point de vue différent offert peut donner de nouvelles idées et définir des choses précises là ou les langages de programmation « défini par l’implémentation ou la doc » sont moins précis et solides, peuvent avoir des trous et des points non documentés ou on est vraiment obligé de tester pour savoir ce que ça fait « en vrai ». Non ?
Intuitivement on pense à le définir comme un ensemble de programmes, mais en fait il faut aussi donner leur sémantique, c'est-à-dire donner le lien entre le programme (le texte) et le comportement quand on le lance (aussi représenté comme un objet mathématique.
« Intuitivement on pense à le définir comme un ensemble de programmes » Mmm certainement pas l’intuition d’un débutant … En fait ce que tu entend par « programme » n’est pas forcément clair. Et cette intuition de programme en tant que composition de programme interroge sur une notion de « programme primitif » qui est un peu HS et pas du tout intuitive pour quelqu’un qui ne connait pas la programmation. C’est un peu une impasse, je pense.
J’imagine que par « mathématiquement » tu veux dire « dans un formalisme logique ».
Attention, on peut aussi représenter mathématiquement un algorithme, mais l'objet mathématique qui correspond à un programme C par exemple n'est pas le même que celui qui correspond à l'algorithme implémenté
Il faut que tu utilises soit un langage algorithmique basique, qu’on peu facilement assimiler à un langage de programmation, soit des formules déclaratives (dans une logique) pour décrire des propriétés du résultats. La preuve visera à démontrer que les opérations décrites par l’algo réalisent bien les propriétés attendues. Ton utilisation de « mathématique » me gène en fait, en tant que personne qui connait un peu le domaine.
Autre remarque :
La sémantique d'un langage est alors donnée par une relation (mathématique) entre les programmes et leur comportement.
Je pense que c’est clair uniquement pour ceux qui savent ce qu’est une relation mathématique.
Ça n’absorbe pas grand chose si le papier finit cramé. Le CO2 est relargué relativement rapidement. Au mieux le bilan carbone de la filière est neutre si ces bois produisent suffisamment de matière pour l’industrie du papier, et en ignorant les énergies nécessaires au transport et à la fabrication du papier.
En plus pour des bouquins qui seront lus souvent une fois ou resteront invendus et termineront direct au pilon et au recyclage … voire prendront de la place et de la poussière dans une bibliothèque.
Cela dit j’aime bien le support papier, mais c’est pas ces forets d’exploitation qui vont le sauver. Le bilan d’une liseuse est probablement désastreux aussi, mais c’est sans doute mieux pour la forêt et la biodiversité en général. Petite pensée opur tous les auteurs qui ne sont pas Amélie Nothomb et qui peinent à se faire éditer aussi.
Je trouve ça dans l’ensemble très clair et très intéressant, même en étant pas la cible. Après je pense que la première phrase est un peu sèche pour un béotien (« représentation symbolique », ça peut faire peur, ce serait dommage). Et tu ne reparles pas de symbole dans la suite, donc l’utilité est sans doute discutable.
Quelques remarques :
Je pense aussi que tu peux intervertir « formalisation mathématique d'un langage de programmation » et « sémantique formelle ». Le second est plus technique, utiliser la première expression en définissant la seconde.
on lui donne une sémantique formelle (ou plusieurs) en définissant les programmes comme des objets mathématiques
Un peu ambigu je trouve, mais c’est pas très grave, et peut être un peu confusant : le programme peut être considéré comme la spécification d’un algorithme dans un langage, alors que la sémantique formelle peut être considérée comme la spec du langage lui même. Ou alors tu veux dire que si le langage n’a pas de sémantique formelle, on ne peut pas considérer le programme comme un objet mathématique ? Mais je pinaille peut être un peu beaucoup pour ce que tu cherches à faire.
L’idée c’est de débattre et de supprimer les silos, donc c’est fort possible. C’est presque le but. Mais l’idée ça a aussi l’air de pas refaire 43 milles fois le match, genre comme c’est possible en relançant un thread sur linuxfr ou tu vas dupliquer la même discussion.
Donc les farfelus, tout l’enjeu technique est de fournir des moyens de leur faire comprendre que le match à déjà eu lieux et que les arguments on déjà été donnés.
Je sais que ce n'est pas du tout ton objectif principal, mais si tu arrétais de personnaloser les débats àtpjt bout de champ ce serait quand même une bonne chose pour l'ambiance.
Il ne suffit pas de ne pas permettre des commentaires de résumé ?
Dans le papier il notent le fait qu’on note un début de «culture» du résumé avec les pratiques des participants qui s’alignent sur les pratiques des premier contributeurs du résumé, ça note que la communauté adopte une position pragmatique. Je pense que cette «culture» peut se bonifier avec l’expérience, et je pense aussi qu’elle se baserai sur l’intérêt communautaire bien compris (faire un résumé utile), et pas sur une volonté de discuter chaque virgule. En particulier, sur ce que tu dis, je pense qu’il s’agit de dépersonnaliser les arguments (ne pas évoquer « machin »), et mentionner le problème en question et ne pas le qualifier
Dans cette approche, j’ai l’impression que l’utilité est aussi de servir de « poteau indicateur » et de jouer le rôle de « sommaire » de la discussion.
We design a workflow to create a summary tree using the idea of recursive summarization of a discussion, where users build summaries of small sections of the discussion, small sets of those summaries are then aggregated and summarized, and so on until the entire discussion is incorporated into the layered summary tree.
Editors can then continue to create new summaries that can distill both previously-written summaries and unsummarized comments, until we are left with a summary of the entire discussion.
Even before the summary tree is complete, the summaries that people write in Wikum are embedded in the original discussion and contribute towards making the discussion easier to read. In threaded discussions, the summary of a subtree lives "Between" the comment and its parent.
Building the Summary Tree For readers of a discussion, Wikum lets them see a visual overview, differentiate between summaries and comments, explore into summaries, and jump between conversations.
If a summary of a subthread has been written, a person writing a summary at a higher level in the discussion thread can promote the lower summary to their position and build on the summary text; this lower summary can be a useful starting point for authoring the higher-level summary.
We chose to stop subjects working on both tasks after each Wikum summary was completed because we wanted to use our other user study participants to provide feedback on the Wikum summary qualities as opposed to spending all their study time finishing the Google Docs summaries.
A thousand words of summary is around two pages long, which may be more than someone is willing to read. However, because of recursive summarization in the Wikum case, users can read a 250-word summary of the entire discussion and drill in to get more detailed summaries.
À comparer avec le mien :p Il y a des trucs que j’ai pas dit et je dis des trucs qui n’y sont pas. Le automatique n’est pas ultra cohérent étant donné qu’il y a des détails sur l’expérience mais pas les résultats, ce qui est fâcheux. Niveau description des fonctionnalités par contre c’est pas mal.
Vous voulez dire quoi par « sur le même cozy » ? qu’on ne peut pas calculer une moyenne entre deux instances perso de Cozy parce que ce n’est pas « le même Cozy ? »
Ça me semble un peu paradoxal quand même. Il y a forcément une certaine quantité d’information qui « fuit » sur ces données. On se situe à la limite entre le cas ou le programme qui tourne sur le client fait un « return null » et un ou il fait un « return data accessibles » tel quel. Dans le cas intermédiaire il fait un traitement qu’on peut assimiler à une « compression » avec perte (plus ou moins importante) de l’ensemble des données.
Si l’enjeu c’est l’anonymat, la perte d’information doit être suffisamment importante pour qu’il soit compliqué de remonter à partir des données publiées jusqu’à l’émetteur de ces données. Cela dit si ce sont des données « privées » on a pas forcément de point de comparaison, effectivement. Est-ce que finalement il ne suffirait pas de publier les données privées en rendant les données de l’utilisateur qui sont accessibles par d’autres canaux (l’annuaire par ex) suffisamment « floues » (en ne conservant par exemple que des coordonnées tronquées pour l’adresse) pour qu’il soit difficile de faire le chemin inverse. La question clé serait alors « quelles informations on doit biffer / approximer / agréger » pour que les données publiées au final ne permette pas d’identifier les donateurs d’infos. Une histoire d’entropie des données utilisables pour l’identifier.
Après réflexion, je pense comprendre votre objectif : si les calculs ont lieux chez le client, il a le contrôle sur quel degré d’info il veut laisser fuiter.
On peut avoir des détails sur la thèse ? L’objectif au moins.
J’ai du mal à voir comment on peut constituer un jeu de donnée en garantissant (j’imagine) que les données restent chez soi (vu que c’est un des objectifs d’owncloud), un minimum d’information doit filtrer.
Par exemple pour calculer une moyenne (genre si on veut calculer la moyenne de l’age des gens qui participent) on peut faire ça de manière incrémentale. Ça nécessite deux nombre : un nombre pour la somme et un nombre pour le nombre de personne dont l’age a été sommé, la moyenne étant la division des deux. Si on imagine une chaîne entre les participants, le premier passe ces deux nombre au suivant, le second connaît l’age du premier (ce n’est plus vrai opur les suivants) … donc le premier ne doit pas passer directement l’info au second. Il pourrait passer par un tiers, l’expérimentateur, mais de même, l’expérimentateur doit peut en déduire l’âge du premier.
J’ai lu des trucs sur les systèmes homomorphes : http://www.pourlascience.fr/ewb_pages/a/article-chiffrement-homomorphe-deleguer-des-calculs-sans-divulguer-les-donnees-35907.php mais dans le cadre d’une expérience scientifique (ouverte), il peut être de bon ton de publier ses données anonymisées pour soumettre son analyse aux autres chercheurs qui voudraient refaire des calculs. Dans ce cas la question deviendrait, est-il possible de créer un jeu de données anonymisé de manière homomorphe, s’il s’agit d’effectuer les calculs chez les clients ?
Plus simplement, s’il s’agit simplement de constituer un jeu de données anonymisé, l’expérimentateur à une « clé privée », diffuse la clé publique à l’ensemble des participants qui chiffrent leurs données, agrègent ces données chiffrées entre eux puis finissent par renvoyer un jeu complet à l’expérimentateur qui a la clé de décryptage sans que l’expérimentateur puisse savoir qui a envoyé quoi mais en pouvant décrypter l’ensemble grâce à sa clé.
Une fois ce jeu anonymisé constitué, il peut servir à toutes les analyses qu’on veut …
Donc non, pour l,instant ça colle pas, tu ne peux pas faire d’étude épidémiologique en te créant un jeu avec les données de 1000 personnes et faire des stats dessus. Tu peux juste faire une analyse locale des données d’un individu.
A la rigueur j’ai l’impression que la fonctionnalité « partage » pourrait coller : «je partage ce type de données sur telle plage de temps avec ce groupe de chercheurs ».
Ça semble donc résoudre de problème du partage de données.
Pour le problème de format par contre je sais pas, Cozy semble être conçu pour que l’appli puisse définir ses propres types, donc n’impose par de format, un peu comme Wikidata. Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.
Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?
Faut savoir qu’étanchéifier ça a tendance à rendre le sol imperméable et donc faire monter l’eau et la faire ruisseler. Des circonstances plutôt aggravantes en fait …
Prévisions du GIEC : réchauffement implique plus de précipitations et une fréquence et une intensité accrue des événements extrême.
Il est évident que quand dans un contexte ou on bat quasiment d’une année sur l’autre le record d’années la plus chaude jamais enregistrée, avoir des événements extrêmes qui sont pas loin de battre des records fait dresser l’oreille. Alors oui, l’analyse du climat étant par nature statistique, les climatologues n’attribueront pas à un événement particulier l’étiquette « réchauffement climatique ». On commence cependant à voir des pourcentages d’attributions, peut être l’anomalie de l’intensité par rapport aux événements précédents (j’ai cru voir des chiffres genre 10 ou 30% pour Harvey)…
Oui je sais bien, mais autant je pense que la question se poserait complètement dans le cas d’un tremblement de terre, autant pour un ouragan sur une île pas très grande qui risque de perdre de sa surface à court/moyen terme, ça me semble un peu vain. Mais ce n’est que mon avis.
Rajoute la montée du niveau des océans dans l’équation et tu auras beau avoir construit des bâtiments solides (et sans doute chers, donc pas accessibles à tous) ils résisteront pas à la submersion si ils sont trop bas.
Tout ne se règle pas avec des normes de construction.
[^] # Re: go 2.0
Posté par thoasm . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
J’ajouterai perso que la théorie sur la sémantique d’un langage, ça devrait largement aider à construire un outillage puissant pour l’écosystème du langage.
L’exemple de l’inférence de type est un cas d’école, je pense : c’est une fonctionnalité très bien comprise théoriquement, qui permet d’aider le programmeur à faire moins d’erreur. La coloration syntaxique, c’est quand même utile d’avoir une grammaire formelle pour l’implémenter, et ces objets sont très bien connus théoriquement. Ça fait partie du baggage de base d’un informaticien. Peut être d’ailleurs qu’un des boulot du chercheur en langage c’est d’essayer de penser à des outils que la formalisation des langages peut aider à concevoir … après tout si c’est plus régulier et plus compréhensible pour les humains, c’est aussi très utile pour les machines pour raisonner sur le programme …
[^] # Re: Super texte …
Posté par thoasm . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2. Dernière modification le 18 octobre 2017 à 19:47.
Ah oui pardon, j’ai dû être trompé par « Dans cette partie du texte, quand je parle de "voir un programme comme un objet mathématique", je parle plutôt du code source ». Toujours cette satanée confusion … c’est absolument pas naturel pour moi de considérer le code simplement comme un programme.
On est pas aidé par des expressions comme langage formel. En fait un langage de programmation (ou sa formalisation) est du côté des système formels, un langage formel en fait simplement partie. Le système formel est constitué du couple (langage formel, sémantique), et on est d’accord que la grammaire définit la partie « langage formel ».
[^] # Re: Super texte …
Posté par thoasm . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Ça se discute. Tu notes une relation de temporalité (voire de causalité) qui n’existe pas forcément dans le monde mathématiques. On ne définit pas les entiers en donnant tous les exemples d’entiers, et une fois qu’on l’a fait, on définit les entiers. On donne des axiomes qui permettent de décider si un objet du formalisme est ou pas un entier. Par l’axiome d’extensionnalité, à tout prédicat correspond une extension : « Étant donné un ensemble A et une propriété P exprimée dans le langage de la théorie des ensembles, il affirme l'existence de l'ensemble B des éléments de A vérifiant la propriété P » https://fr.wikipedia.org/wiki/Sch%C3%A9ma_d%27axiomes_de_compr%C3%A9hension . Mais à chaque propriété sur un ensemble correspond une seule extension … que tu définis « en même temps » que tu donnes la propriété. En complexité, on définit même un problème de décision comme l’appartenance ou pas d’une chaîne à un ensemble. Le prédicat associé à l’ensemble n’est même pas évoqué … En gros dans mon esprit la BNF (le prédicat) définit l’ensemble (le langage). Sauf si tu assimiles l’écriture de la BNF à la définition d’«un» programme, mais c’est pas du tout ma vision des choses. Enfin cette manière de décrire les choses correspond peut être à une vision constructiviste des choses ;).
Sinon je suis entièrement d’accord pour ce que tu dis sur la formalisation, avoir un accord parfait entre la théorie et l’expérience est un acte inaccessible. Cela dit, je pense avoir identifié un truc qui manque dans ton texte : il est considéré comme implicite que le programme est destiné à être exécuté. Du coup la métaphore du « parler » tombe un peu à plat. Quand je fais une requête google, je « parle » à la machine, pourtant je ne la programme pas. Un programme est destiné à être exécuté, et peut être exécuté pleins de fois. ça ne transparaît dans ton texte que quand tu parles de comportement du programme. Ce qui pourrait lever ton ambiguïté d’ailleurs.
(et je poste en l’état parce que j’y ai déjà passé trop de temps)
[^] # Re: Super texte …
Posté par thoasm . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Je dirai que « les informaticiens ont inventé de nombreuses manières de décrire les programmes qui sont exécutés par un ordinateur » conviendrai dans un premier temps. Tu peux rajouter « souvent ils sont écris sous forme de texte, parfois d’autres formes, ou d’autres formes symboliques (« graphiques » par ex. https://scratch.mit.edu/) ». Dans tous les cas, le formalisme qui permet de les décrire constitue ce qu’on appelle un « langage de programmation ». »
Je comprend pas. Un programme écrit dans un langage donné est quelque part déjà un objet mathématique. « et à partir de cela définir le langage » euh, on commence pas par définir le langage avant d’écrire des programmes ??? Peut être qu’il faut que tu parles de sémantique (en général) d’un langage de programmation, sinon pareil je pense que ça peut ne pas être clair pour un débutant.
Je propose :
«Les informaticiens apprennent souvent par l’exemple et la pratique (et un prof et ses explications) ce qu’est supposé faire un programme et se forgent une intuition de la signification du code qu’ils écrivent, Ensuite, on essaye de le faire tourner pour voir si « ça marche » … et parfois, « ça marche ».
Les approches formelles s’appuient sur autre choses que l’essai et l’erreur et s’appuient sur la logique et les mathématiques pour décrire le comportement attendu d’un programme (indépendamment de ce qui se passe vraiment quand on le teste). La sémantique formelle (cette fois) d’un langage permet de faire le lien entre chaque programme écrit dans ce langage et ce comportement attendu. Votre boulot est en partie de l’écrire et de l’imaginer.»
Du coup vous vous nourrissez de la rigueur des maths pour détecter d’éventuels problèmes, et le point de vue différent offert peut donner de nouvelles idées et définir des choses précises là ou les langages de programmation « défini par l’implémentation ou la doc » sont moins précis et solides, peuvent avoir des trous et des points non documentés ou on est vraiment obligé de tester pour savoir ce que ça fait « en vrai ». Non ?
« Intuitivement on pense à le définir comme un ensemble de programmes » Mmm certainement pas l’intuition d’un débutant … En fait ce que tu entend par « programme » n’est pas forcément clair. Et cette intuition de programme en tant que composition de programme interroge sur une notion de « programme primitif » qui est un peu HS et pas du tout intuitive pour quelqu’un qui ne connait pas la programmation. C’est un peu une impasse, je pense.
J’imagine que par « mathématiquement » tu veux dire « dans un formalisme logique ».
Il faut que tu utilises soit un langage algorithmique basique, qu’on peu facilement assimiler à un langage de programmation, soit des formules déclaratives (dans une logique) pour décrire des propriétés du résultats. La preuve visera à démontrer que les opérations décrites par l’algo réalisent bien les propriétés attendues. Ton utilisation de « mathématique » me gène en fait, en tant que personne qui connait un peu le domaine.
Autre remarque :
Je pense que c’est clair uniquement pour ceux qui savent ce qu’est une relation mathématique.
[^] # Re: J'aime les arbres
Posté par thoasm . En réponse au sondage Que pensez-vous des liseuses ?. Évalué à 4.
Ça n’absorbe pas grand chose si le papier finit cramé. Le CO2 est relargué relativement rapidement. Au mieux le bilan carbone de la filière est neutre si ces bois produisent suffisamment de matière pour l’industrie du papier, et en ignorant les énergies nécessaires au transport et à la fabrication du papier.
En plus pour des bouquins qui seront lus souvent une fois ou resteront invendus et termineront direct au pilon et au recyclage … voire prendront de la place et de la poussière dans une bibliothèque.
Cela dit j’aime bien le support papier, mais c’est pas ces forets d’exploitation qui vont le sauver. Le bilan d’une liseuse est probablement désastreux aussi, mais c’est sans doute mieux pour la forêt et la biodiversité en général. Petite pensée opur tous les auteurs qui ne sont pas Amélie Nothomb et qui peinent à se faire éditer aussi.
# Super texte …
Posté par thoasm . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je trouve ça dans l’ensemble très clair et très intéressant, même en étant pas la cible. Après je pense que la première phrase est un peu sèche pour un béotien (« représentation symbolique », ça peut faire peur, ce serait dommage). Et tu ne reparles pas de symbole dans la suite, donc l’utilité est sans doute discutable.
Quelques remarques :
Je pense aussi que tu peux intervertir « formalisation mathématique d'un langage de programmation » et « sémantique formelle ». Le second est plus technique, utiliser la première expression en définissant la seconde.
Un peu ambigu je trouve, mais c’est pas très grave, et peut être un peu confusant : le programme peut être considéré comme la spécification d’un algorithme dans un langage, alors que la sémantique formelle peut être considérée comme la spec du langage lui même. Ou alors tu veux dire que si le langage n’a pas de sémantique formelle, on ne peut pas considérer le programme comme un objet mathématique ? Mais je pinaille peut être un peu beaucoup pour ce que tu cherches à faire.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par thoasm . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 4.
Tu entends quoi par "de plus en plus buggué" ? C'est étrange car encore maintenu.
# Débattons !
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 7.
J'espère que vous allez mettre débattons sur les rails, et pas dans les roues !
[^] # Re: Trollons
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 4.
Alors que je suis juste tombé sur un nid de gens contre le progrès sur Internet blasés !
[^] # Re: Trollons
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 2.
L’idée c’est de débattre et de supprimer les silos, donc c’est fort possible. C’est presque le but. Mais l’idée ça a aussi l’air de pas refaire 43 milles fois le match, genre comme c’est possible en relançant un thread sur linuxfr ou tu vas dupliquer la même discussion.
Donc les farfelus, tout l’enjeu technique est de fournir des moyens de leur faire comprendre que le match à déjà eu lieux et que les arguments on déjà été donnés.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par thoasm . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 9.
Je sais que ce n'est pas du tout ton objectif principal, mais si tu arrétais de personnaloser les débats àtpjt bout de champ ce serait quand même une bonne chose pour l'ambiance.
# Resumé
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 4.
Vous avez connaissance de systèmes de résumé comme wikum ? Cf. https://linuxfr.org/users/thoasm/journaux/wikum-resume-et-recursion ca me semble intéressant à considérer pour une telle plateforme.
[^] # Re: Trollons
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 3.
J'ai l'impression que c'est précisément ce qu'ils cherchent à éviter.
[^] # Re: du boulot!
Posté par thoasm . En réponse au journal Wikum : Résumé et récursion. Évalué à 4.
Il ne suffit pas de ne pas permettre des commentaires de résumé ?
Dans le papier il notent le fait qu’on note un début de «culture» du résumé avec les pratiques des participants qui s’alignent sur les pratiques des premier contributeurs du résumé, ça note que la communauté adopte une position pragmatique. Je pense que cette «culture» peut se bonifier avec l’expérience, et je pense aussi qu’elle se baserai sur l’intérêt communautaire bien compris (faire un résumé utile), et pas sur une volonté de discuter chaque virgule. En particulier, sur ce que tu dis, je pense qu’il s’agit de dépersonnaliser les arguments (ne pas évoquer « machin »), et mentionner le problème en question et ne pas le qualifier
Dans cette approche, j’ai l’impression que l’utilité est aussi de servir de « poteau indicateur » et de jouer le rôle de « sommaire » de la discussion.
[^] # Re: du boulot!
Posté par thoasm . En réponse au journal Wikum : Résumé et récursion. Évalué à 3.
Un copier/coller du résumé de l’article :
(paramètres par défaut)
http://smmry.com/https://people.csail.mit.edu/axz/papers/wikum.pdf#&SM_LENGTH=7
À comparer avec le mien :p Il y a des trucs que j’ai pas dit et je dis des trucs qui n’y sont pas. Le automatique n’est pas ultra cohérent étant donné qu’il y a des détails sur l’expérience mais pas les résultats, ce qui est fâcheux. Niveau description des fonctionnalités par contre c’est pas mal.
[^] # Re: Cozy ?
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Ça se passe comment pour l’agrégation ?
Vous voulez dire quoi par « sur le même cozy » ? qu’on ne peut pas calculer une moyenne entre deux instances perso de Cozy parce que ce n’est pas « le même Cozy ? »
[^] # Re: Cozy ?
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 3.
Ça me semble un peu paradoxal quand même. Il y a forcément une certaine quantité d’information qui « fuit » sur ces données. On se situe à la limite entre le cas ou le programme qui tourne sur le client fait un « return null » et un ou il fait un « return data accessibles » tel quel. Dans le cas intermédiaire il fait un traitement qu’on peut assimiler à une « compression » avec perte (plus ou moins importante) de l’ensemble des données.
Si l’enjeu c’est l’anonymat, la perte d’information doit être suffisamment importante pour qu’il soit compliqué de remonter à partir des données publiées jusqu’à l’émetteur de ces données. Cela dit si ce sont des données « privées » on a pas forcément de point de comparaison, effectivement. Est-ce que finalement il ne suffirait pas de publier les données privées en rendant les données de l’utilisateur qui sont accessibles par d’autres canaux (l’annuaire par ex) suffisamment « floues » (en ne conservant par exemple que des coordonnées tronquées pour l’adresse) pour qu’il soit difficile de faire le chemin inverse. La question clé serait alors « quelles informations on doit biffer / approximer / agréger » pour que les données publiées au final ne permette pas d’identifier les donateurs d’infos. Une histoire d’entropie des données utilisables pour l’identifier.
Après réflexion, je pense comprendre votre objectif : si les calculs ont lieux chez le client, il a le contrôle sur quel degré d’info il veut laisser fuiter.
[^] # Re: Retroshare
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Oui ?
[^] # Re: Cozy ?
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
On peut avoir des détails sur la thèse ? L’objectif au moins.
J’ai du mal à voir comment on peut constituer un jeu de donnée en garantissant (j’imagine) que les données restent chez soi (vu que c’est un des objectifs d’owncloud), un minimum d’information doit filtrer.
Par exemple pour calculer une moyenne (genre si on veut calculer la moyenne de l’age des gens qui participent) on peut faire ça de manière incrémentale. Ça nécessite deux nombre : un nombre pour la somme et un nombre pour le nombre de personne dont l’age a été sommé, la moyenne étant la division des deux. Si on imagine une chaîne entre les participants, le premier passe ces deux nombre au suivant, le second connaît l’age du premier (ce n’est plus vrai opur les suivants) … donc le premier ne doit pas passer directement l’info au second. Il pourrait passer par un tiers, l’expérimentateur, mais de même, l’expérimentateur doit peut en déduire l’âge du premier.
J’ai lu des trucs sur les systèmes homomorphes : http://www.pourlascience.fr/ewb_pages/a/article-chiffrement-homomorphe-deleguer-des-calculs-sans-divulguer-les-donnees-35907.php mais dans le cadre d’une expérience scientifique (ouverte), il peut être de bon ton de publier ses données anonymisées pour soumettre son analyse aux autres chercheurs qui voudraient refaire des calculs. Dans ce cas la question deviendrait, est-il possible de créer un jeu de données anonymisé de manière homomorphe, s’il s’agit d’effectuer les calculs chez les clients ?
Plus simplement, s’il s’agit simplement de constituer un jeu de données anonymisé, l’expérimentateur à une « clé privée », diffuse la clé publique à l’ensemble des participants qui chiffrent leurs données, agrègent ces données chiffrées entre eux puis finissent par renvoyer un jeu complet à l’expérimentateur qui a la clé de décryptage sans que l’expérimentateur puisse savoir qui a envoyé quoi mais en pouvant décrypter l’ensemble grâce à sa clé.
Une fois ce jeu anonymisé constitué, il peut servir à toutes les analyses qu’on veut …
[^] # Re: Cozy ?
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Donc non, pour l,instant ça colle pas, tu ne peux pas faire d’étude épidémiologique en te créant un jeu avec les données de 1000 personnes et faire des stats dessus. Tu peux juste faire une analyse locale des données d’un individu.
A la rigueur j’ai l’impression que la fonctionnalité « partage » pourrait coller : «je partage ce type de données sur telle plage de temps avec ce groupe de chercheurs ».
[^] # Re: Cozy ?
Posté par thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Intéressant. Je n’avais jamais regardé Cozy de près.
Je ne sais pas si c’est totalement ça. J’ai quelques questions :
A priori oui : https://github.com/Ljinod/cozy-docs/blob/master/src/documents/en/hack/cookbooks/sharing.html.md
Ça semble donc résoudre de problème du partage de données.
Pour le problème de format par contre je sais pas, Cozy semble être conçu pour que l’appli puisse définir ses propres types, donc n’impose par de format, un peu comme Wikidata. Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.
Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?
[^] # Re: préparation
Posté par thoasm . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 3.
Faut savoir qu’étanchéifier ça a tendance à rendre le sol imperméable et donc faire monter l’eau et la faire ruisseler. Des circonstances plutôt aggravantes en fait …
[^] # Re: Attention, n'allons pas trop vite…
Posté par thoasm . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 1. Dernière modification le 08 septembre 2017 à 14:26.
Et bien bien sur que ça apporte une lumière.
Prévisions du GIEC : réchauffement implique plus de précipitations et une fréquence et une intensité accrue des événements extrême.
Il est évident que quand dans un contexte ou on bat quasiment d’une année sur l’autre le record d’années la plus chaude jamais enregistrée, avoir des événements extrêmes qui sont pas loin de battre des records fait dresser l’oreille. Alors oui, l’analyse du climat étant par nature statistique, les climatologues n’attribueront pas à un événement particulier l’étiquette « réchauffement climatique ». On commence cependant à voir des pourcentages d’attributions, peut être l’anomalie de l’intensité par rapport aux événements précédents (j’ai cru voir des chiffres genre 10 ou 30% pour Harvey)…
Du coup ton « ça n’a aucun rapport » quand on nous dit d’un autre côté « faut s’y habituer » (ex parmi d’autre : https://www.sciencesetavenir.fr/nature-environnement/le-rechauffement-climatique-facteur-aggravant-du-risque-d-inondation_10389 hors contexte puisque l’article est de 2013)
[^] # Re: préparation
Posté par thoasm . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 2.
Oui je sais bien, mais autant je pense que la question se poserait complètement dans le cas d’un tremblement de terre, autant pour un ouragan sur une île pas très grande qui risque de perdre de sa surface à court/moyen terme, ça me semble un peu vain. Mais ce n’est que mon avis.
[^] # Re: préparation
Posté par thoasm . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à -2.
Rajoute la montée du niveau des océans dans l’équation et tu auras beau avoir construit des bâtiments solides (et sans doute chers, donc pas accessibles à tous) ils résisteront pas à la submersion si ils sont trop bas.
Tout ne se règle pas avec des normes de construction.