gipoisson a écrit 97 commentaires

Sinon, comme barmic, je dois bien dire que je ne comprends pas grand chose. Au langage sparql, déjà, à la fin de la lecture de la dépêche je ne suis pas sûr de savoir écrire une requête simple (même après la deuxième lecture).

Les requêtes écrites directement dans de la dépêche sont là pour introduire la syntaxe et certaines notions mais elles ne sont pas exécutables. Un triplet est comme la traditionnelle formule grammaticale une phrase = SUJET + VERBE + OBJET ; en RDF, le verbe est appelé prédicat. On s'exprime en triplets sur le contenu d'une base de connaissances (BC) et ça c'est seulement au niveau de la syntaxe. C'est au moteur de requêtes de voir si les triplets écrits correspondent à quelque chose contenue dans la BC.

La notion de nœud blanc est à comprendre comme un quantificateur existentiel : on est persuadé qu'il existe quelque chose dans la BC mais on ne sait pas comment le nommer, i.e. on ignore son URI et donc, on s'y réfère avec un nœud blanc¹.

La requête envoyée sur WikiData masque la déclaration des préfixes et la spécification du graphe par défaut (la BC). Chaque nœud SPARQL possède un graphe par défaut ; comme l'expression « par défaut » l'indique, on peut changer le graphe à interroger et ça se fait avec la clause FROM ou FROM NAMED. En omettant ledit graphe par défaut, la requête complète se réécrit ainsi :

PREFIX wdt: <http://www.wikidata.org/prop/direct/>

select ?personne ?personneLabel {
  ?personne wdt:P22 ?father filter(isBlank(?father)) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}

Comme pour toute autre ressource en RDF, un graphe est identifié par un URI. Si le graphe à interroger était identifié par foo:bar, la requête serait (ne pas exécuter ça !)

PREFIX wdt: <http://www.wikidata.org/prop/direct/>

FROM <foo:bar>

select ?personne ?personneLabel {
  ?personne wdt:P22 ?father filter(isBlank(?father)) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}

Le protocole indique comment et où un moteur de requêtes va chercher le graphe indiqué par FROM. Enfin, les PREFIXs évitent de réécrire l'espace des noms dans chaque triplet. Mais ici, comme il n'y a qu'une seule ressource utilisée dans cet espace, on peut omettre le préfixe :

select ?personne ?personneLabel {
  ?personne <http://www.wikidata.org/prop/direct/P22> ?father filter(isBlank(?father)) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}

Fondamentalement, ça me rappelle ce qu’on pouvait faire avec prolog, avec une syntaxe encore plus obscure.

Le langage est plutôt conçu pour envahir le champ syntaxique du SQL. Il y a même une norme qui réalise un mapping cohérent entre SQL et SPARQL, ça s'appelle R2RML. Et c'est génial, car on peut se mettre à vider les bases de données relationnelles pour remplir des graphes RDF et faire des trucs très avancés, de la gageure si c'était à faire absolument en SQL².

Ce que je trouve plutôt obscur, c'est cette volonté de continuer à forcer une syntaxe imaginée pour des données tabulaires sur des graphes. C'est typiquement le genre de situations où les types de données algébriques auraient fait des merveilles.

Or, dans les exemples, je vois que tout est en français. C’est traduit, ou bien chacun fait ce qu’il veut, il n’y a pas de norme établie ?

Les triplets, les graphes (ensembles de triplets) peuvent être typés. La syntaxe est en Unicode mais la sémantique est déterminée par un schéma. Il y a plusieurs types de schémas avec des niveaux d'expressivités variables : vocabulaires contrôlés, taxonomies, corpus, ontologies, … Les schémas sont eux-mêmes écrits en triplets. On ne dit pas ce qu'on veut a priori, on dit tout ce que le graphe (avec schéma ou non) permet. Mais on peut ajouter de nouveaux triplets arbitraires dans le graphe, donc a posteriori on peut écrire tout ce qu'on veut, c'est l'hypothèse du monde ouvert.

Ouai mais ça ne m'a pas vraiment convaincu et je ne crois pas que ça sortira des domaines d'expérimentation. Ton lien montre peu de site et il n'est pas à jour (le fait même que ce ne soit pas à jour monté le peu d'enthousiasme).

En supplément de la réponse de Thomas, voici d'autres cas d'utilisation du Web Sémantique (WS) et qui sont tirés d'horizons diversifiés.

Projets d'envergure des GAFAM

Dans cette catégorie, ce sont les applications de type knowledge graph qui prédominent. De la même manière que SQL est systématiquement associé à la notion de table, SPARQL a sa structure de données de prédilection, le graphe (ou le tenseur pour généraliser). Il se trouve qu'une palanquée de situations sont mieux capturées dans des graphes plutôt que dans des tables. C'est ce qu'ont constaté

• Google qui a avalé Freebase pour plus tard verser une partie de son contenu dans dbPedia et surtout, pour créer leur Knowledge Graph. Il est difficile de trouver des détails sur son implémentation mais c'est un projet qui est omniprésent dans leur moteur de recherche. Par contre, Freebase reposait bien entendu sur les langages du WS. Google propose tout de même une API non-WS exposant son graphe de connaissances.

• Microsoft avec son Satori dont il est difficile de trouver des détails qui ne sont pas du mainstream, un paradoxe … lorsq'on regarde l'étymologie de l'appellation donnée à leur outil. Cependant, cet article ne laisse pas de place au doute que SPARQL est utilisé dans Satori.

• Google, Microsoft, Yahoo et Yandex en joignant leurs forces pour concevoir des schémas en RDFa à usage de moteurs de recherche.

• Apple en rendant Siri friand des données structurées selon les pratiques du WS. Dit en passant, c'est ce Tom Gruber qu'on cite à chaque fois qu'on veut donner une définition de ce qu'est une ontologie informatique.

• IBM en faisant ingurgiter à Watson une immense quantité de données tirées du WS. L'article dit que parmi les sources de données filées à W., il y avait des « bases de données, des taxonomies ou vocabulaires contrôlés et des ontologies telles dbPedia, WordNet et Yago.»

• Nvidia avec son Blazegraph décliné en deux versions, une pour GPUs et une autre pour CPUs. C'est ce même outil qu'utilise le nœud SPARQL de WikiData et il passe très bien à l'échelle vu qu'il se permet de battre Apache Spark dans des benchmarks.

• Oracle en mettant en place Spatial and Graph RDF Semantic Graph. Mais on ne s'est pas arrêté aux données géospatiales chez Oracle car on propose aussi une implémentation de la norme W3C appelée R2RML. Ainsi, on peut faire des aller-retour entre SQL et SPARQL sans perdre la sémantique des données.

• Et beaucoup d'autres ! Mentions spéciales pour Virtuoso, Jena, RDF4J, AllegroGraph ainsi que Stardog.

Projets Spécialisés à Certaines Disciplines

Il y en a des myriades, ça va de l'archivage, à la configuration de pièces composant un produit mécanique, en passant par les sciences biomédicales. Deux exemples pour faire court :

• NELL, une machine qui apprendra jusqu'à ce que mort s'en suive !

• Portail où sont déposées beaucoup d'ontologies conçues pour la Bioinformatique.

Année™ du™ Desktop™ sur™ Linux™ (ADL)

Même dans ton GNU, il y a des triplets qui moulinent pour indexer le système de fichiers. Le projet original s'applelait Nepomuk et avait été repris dans FreeDesktop. Depuis, KDE l'a éliminé pour le remplacer avec Baloo. Son leg se retrouve dans Zeitgeist et dans Tracker. Pour dire que si tu utilises GNOME, tu as déjà des cas très concrets où SPARQL fonctionne sans même t'en douter.

Si des iGadget-Users nous narguent nous autres GNOMErs en disant que notre outil n'a pas d'assistant personnel, on pourrait leur rétorquer qu'à la base, Siri est une sorte de moteur de requêtes fédérées sur des vocabulaires et que GNOME en a depuis Nepomuk ; bref que l'ADL c'est pas de la fixion !

P.S. 1- Pour « mélanger » des graphes provenant de plusieurs sources, on fait des opérations d'alignement, de matching, de fédération sur leurs schémas (ontologies). Mais ces traitements sont quasi superflus si on ne s'oriente pas vers des questions d'inférence sans qui on peut manipuler des corpus dotés des centaines d'ontologies, pourvu que le moteur SPARQL tienne. Voir par exemple sur sur cette page même s'il y a un peu de curation de ce côté-là.

P.S. 2- Le Center for Data Science à Paris-Saclay héberge des nœuds SPARQL très hétérogènes, cela peut être un moyen de s'exercer au WS en travaillant sur des jeux de données qui n'ont été conçus ni au même endroit ni en poursuivant les mêmes objectifs.

Sommaire

• • Ça dévisse
  • Hors-sujet approfondi
  • Fin de l'aparté

Merci de cette dépêche sur ces sujets plutôt en retrait dans ces lieux, si ce n'est Thomas Dᴏᴜɪʟʟᴀʀᴅ qui en parle régulièrement pour nous instruire sur la vie de WikiData. Je vais aller un peu hors sujet de la dépêche et pousser quelques grognements à partir des extraits infra.

[…] ce domaine et la recherche autour ont dans un premier temps donné naissance à des technologies normalisées par le W3C […]
[…] est un langage qui ressemble beaucoup à SQL, dont il reprend d'ailleurs des mots clés et des constructions, étendu pour pouvoir gérer des relations qui ne sont pas définies à la manière des schémas de données SQL classiques […]
[… SPARQL] délègue ainsi le typage des données qu'il manipule à RDF et RDFS. […] Il y aurait beaucoup à dire sur le typage dans le web sémantique, mais c'est hors cadre de cet article. Ça concerne la notion d'ontologie formelle, et les couches plus hautes de la pile du web sémantique comme OWL et les moteurs d'inférences. Ces couches rajoutent la possibilité de faire des schémas de données plus avancées, et la possibilité de déduire des triplets qui ne sont pas explicites dans le dépôt grâce à des règles logiques.

Ça dévisse

En creusant un peu divers documents traitant du Web Sémantique (WS), il devient apparent que la communauté autour souhaite vivement attirer les individus habitués au WWW. La perspective de passer d'une toile de pages à une toile d'URIs ne manque pas de fringuant, un de ses effets de bord coïncidant avec les thèmes souvent abordés ici pourrait être la sortie de la googlisation rampante. Toutefois, il me semble que les dévs. SQL n'ont pas massivement migré vers SPARQL, au contraire, ce dernier reste un langage confidentiel si l'on se fie à une pifométrie comme celle-ci : plus de 365 kilo-questions versus environ 3 kilos. Il n'y aurait même pas la possibilité de mettre cette disproportion (perçue) sur le dos de la jeunesse, les initiatives de normalisation du WS ayant débuté quelques années après celles sur le WWW.

Tout cela pour en arriver à un ensemble de questions qui me taraudent et que j'aimerais poser à vous qui êtes plus au fait de ce qui se fait dans le WS.

• Est-ce justifié de continuer à chercher de « faciliter la vie » aux aficionados du SQL ? Si oui, pourquoi faire et pour quoi faire ?
• Pourquoi se trimbaler un système de typage qui est, si ce n'est bancal, volontairement bridé alors que si l'on pousser à fond du côté des ontologies, on pourrait augmenter significativement son expressivité ?
• Est-ce la même volonté de louvoyer vers des « dévs. standards » qui est derrière la monoculture Java qui semble régner dans ce milieu ? Dès qu'on examine l'outillage, on ne manquera sans doute pas de remarquer que les outils Java se sont taillés une part de lion dans le WS.

Hors-sujet approfondi

Bien que les logiques de description soient déjà limitées, notamment par rapport aux logiques d'ordres supérieurs, il est étonnant de voir un langage comme OWL encore réduit dans ses implémentations pratiquement à son sous-ensemble compatible avec la Programmation Orientée Objet. Là où il serait légitime de s'attendre à ce qu'un tel langage soit implémenté dans des langages plus ou moins proches de son cadre théorique¹, on se retrouve avec une API officielle déclinée en Java. Lorsqu'un contributeur de ladite API s'interroge à haute voix s'il ne faudrait pas accorder sa chance au monde hors JVM, il se heurte à un silence assourdissant.

Lors de mes premiers pas dans les ontologies, c'était enthousiasmant d'apprendre que l'on pourrait vérifier la cohérence d'une base de connaissances de façon complètement automatique, qu'on se permettrait de lâcher un moteur d'inférence sur un amas de triplets afin d'observer de la connaissance cachée émerger. Quelques temps après, déchanter n'était pas si difficile, ayant constaté, comme tant d'autres, qu'on passe surtout un temps non-négligeable à contourner les plus de 220 kilo-classes de l'API d'OWL pour la faire dialoguer correctement avec des outils souvent codés en C++. Finalement, le fait que WikiData décide de ne pas s'entêter dans cette direction n'est pas si paradoxal.

Pour parer à la traditionnelle rengaine du « code la fonctionnalité manquante par toi-même », j'admets tout de go mon incompétence. C'est dans ce sens que les efforts que font les personnes derrière WikiData sont vraiment admirables. D'ailleurs en tentant de jouer avec l'exemple de la dépêche à l'aide de quelques paquets codés en Haskell, on se rend compte de l'étendue du parcours que ces derniers ont encore à faire : le nœud RDF de WikiData est accessible en TLS, la page pointée par un http:// étant redirigée vers un https:// ; normal dirait-on, on est en 2017 après tout. Sauf que le paquet Haskell qui gère les nœuds RDF utilise actuellement une implémentation du HTTP qui date du début des années 2000 ne supportant pas le HTTPS. Le contournement que j'avais imaginé était de passer par DBpedia dont le nœud passe en HTTP mais son jeu de données ne semble pas englober tout WikiData. Ce qui m'amène à d'autres questions :

• au niveau de leurs backends, quelle est la différence entre WikiData et DBpedia ?
• on lit dans le texte que « [sur WikiData], on n'en est pas du tout » porté vers OWL et des inférences ; pourquoi alors le schéma du graphe de WikiData comporte des choses comme celles de l'extrait ici-bas ?

<vocabulary xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#sameAs"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#complementOf"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#onProperty"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#someValuesFrom"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#imports"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Restriction"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Ontology"/>

Fin de l'aparté

Pour mémoire, la tentative en Haskell évoquée plus haut est celle-ci :

{-# LANGUAGE OverloadedStrings #-}

import Database.HSparql.Connection
import Database.HSparql.QueryGenerator

main :: IO ()
main = do
    (Just t) <- selectQuery "http://dbpedia.org/sparql" selectFatherless
    print t

selectFatherless :: Query SelectQuery
selectFatherless = do
    wdt <- prefix "wdt" (iriRef "http://www.wikidata.org/entity/")

    person  <- var
    father <- var
    concept <- var
    lang <- var

    -- Cette ligne retourne un graphe vide probablement parce que
    -- les arcanes de DBpedia diffèrent de celles de WikiData.
    -- S'il y avait eu des résultats, filtrer les nœuds blancs aurait été une formalité.
    -- _ <- triple person (wdt .:. "P22") father

    -- On se rabat sur cette ligne pour explorer la notion de « patternel » dans diverses langues.
    _ <- triple (wdt .:. "P22") concept lang

    -- L'exhaustivité n'est pas requise.
    limit 100

    return SelectQuery { queryVars = [concept, lang] }

Échantillon de sorties :

"Vater" "de"
"father" "en"
"その項目は主題に対し男性の親" "ja" -- Pour les amateurs du kan'ji qui postent de temps en temps ici.
…
"isä" "fi" -- Pour mupuf (voir http://www.mupuf.org/blog/2016/11/07/learning-finnish/)
…
"père" "fr"
…
"lien familial, parent direct de sexe masculin" "fr"
"male parent" "en"
…
"Papa" "fr"
…

Pour voir jusqu'où on peut aller avec des outils versatiles, se référer par exemple à Swish de G. Klyne dans cet article qui date, certes mais dont l'intuition est des plus actuelles.

En plus de la solution Archlinux proposée supra, il y a bien sûr snapper d'openSUSE qui est l'upstream de ce que fait Archlinux. snapper est porté sur plusieurs autres distributions. Dans la dépêche que tu as initiée, il semble que tu aimerais une solution pour Ubuntu ; ça tombe bien, les auteurs de snapper proposent des paquets pour Debian 8 et xUbuntu, la création d'un paquet pour une Ubuntu de base ne devrait pas a priori être une tâche insurmontable.

Malheureusement je ne le trouve plus sur wikipédia […]

Il y en a sous l'entrée Black Perl. La version française renvoie sur une URL externe, l'anglaise recopie le poème.

Tant qu'on y est, L.W. avait aussi participé à deux reprises à l'IOCC, en gagnant en 1986 le prix « en confusionnisme élégant » et en 1987 celui de « la plus pertinente obfuscation.» Le code de 1987 compile sans erreur avec les toutes dernières versions de GCC et CLANG. En entrée du programme, taper successivement des unsigned int pour écouter Virgile et Horace.

Pour terminer, dans la catégorie poésie, crapuleuse cette fois-ci (Ne pas Basher !), il y a :

uname | talk | date | touch | unzip | strip | finger | mount | fsck | more | umount | make clean | sleep

https://google.com/search?hl=fr&q=r%C3%A9cursivit%C3%A9

https://www.google.com/?hl=en#hl=en&q=answer+to+life+the+universe+and+everything

Edit. Licence : WTFPL

Addendum : selon cette page sur Launchpad, Ubuntu 16.04 (la version qu'a utilisée C. Evans) n'a pas encore reçu la MàJ mais Ubuntu 16.10 en a.

tracker est l'objet global que traitent la récente série d'articles de Chris Evans. Par défaut, un des modules de tracker parse une grande quantité de données présentées dans une multitude de formats ; ce parsing doit être fait dans une bac-à-sable pour protéger le système hôte, cela a été discuté en plusieurs endroits, par exemple dans les ML de Fedora, sur LWN, par Carlos Garnacho – un contributeur à tracker – ou par C. Evans qui, dans l'article lié par le journal écrit :

As always, the general lack of sandboxing here contributes to the severity. I think we inhabit a world where media parsing sandboxes should be mandatory these days. There’s hope: some of my other recent disclosures appear to have motivated a sandbox for Gnome’s tracker.

Traduction : « Comme souvent, le manque de mécanismes de bac-à-sable aggrave la situation alors qu'ils devraient être obligatoires pour toutes les tâches touchant au parsing de contenus audiovisuels. Cependant, tout n'est pas perdu : GNOME-tracker serait doté d'un tel mécanisme suite à mes dernières publications.»

En effet et pour répondre à maclag (« Si le patch est disponible, est-ce que les paquets concernés ont été mis à jour ?»), le bac-à-sable est disponible depuis les commits de C. Garnacho (ici et là). La version de Fedora concerné dans les articles de C. Evans contient les mises à jour upstream. Pour Ubuntu, d'autres plus au fait de la distribution pourraient mieux éclairer le statut du paquet que je ne saurai le faire ; voir néanmoins cette page.

Quelques subtilités des numeric en R, type qui englobe les integers et les doubles :

a <- c(1L, 0L, -0L)
1/a
all(a == c(1, 0, -0))
identical(a, c(1, 0, -0))

[1]   1 Inf Inf
[1] TRUE
[1] FALSE

Quid de bibliothèques de haute précision ? Par exemple, GNU MPFR implémente les cinq modes d'arrondis d'IEEE754-2008.

/* linuxfr.c */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <mpfr.h>

void exemplifier(mpfr_t, mpfr_rnd_t, char **, size_t);

int main(int argc, char* argv[]) {
    mpfr_t x;
    mpfr_init2(x, 64);
    char *eleven[] = {"11.5", "-11.5"};
    char *twelve[] = {"12.5", "-12.5"};

    exemplifier(x, MPFR_RNDN, eleven, 2);
    exemplifier(x, MPFR_RNDN, twelve, 2);

    exemplifier(x, MPFR_RNDZ, eleven, 2);
    exemplifier(x, MPFR_RNDZ, twelve, 2);

    exemplifier(x, MPFR_RNDU, eleven, 2);
    exemplifier(x, MPFR_RNDU, twelve, 2);

    exemplifier(x, MPFR_RNDD, eleven, 2);
    exemplifier(x, MPFR_RNDD, twelve, 2);

    exemplifier(x, MPFR_RNDA, eleven, 2);
    exemplifier(x, MPFR_RNDA, twelve, 2);

    mpfr_clear(x);
    mpfr_free_cache();
    return 0;
}

void exemplifier(mpfr_t val, mpfr_rnd_t rnd, char **lit, size_t size) {
    size_t i = 0;
    fprintf(stdout, "\n");
    for(i = 0; i < size; ++i) {
        mpfr_set_str(val, lit[i], 10, rnd);
        mpfr_out_str(stdout, 10, 10, val, rnd);
        fprintf(stdout, "\t");
    }
    fprintf(stdout, "\n");
}

Disclaimer: n'ayant pas de grande aisance en C, je me fie au compilateur pour m'indiquer les éventuelles bourdes de ce que j'aurais commises.

gcc -lmpfr -lgmp -std=c11 -g -O3 -Wall -pedantic -Wextra -ggdb -fomit-frame-pointer -fstack-protector-all -ftrapv -pipe -flto linuxfr.c -o linuxfr

1.150000000e1   -1.150000000e1  

1.250000000e1   -1.250000000e1  

1.150000000e1   -1.150000000e1  

1.250000000e1   -1.250000000e1  

1.150000000e1   -1.150000000e1  

1.250000000e1   -1.250000000e1  

1.150000000e1   -1.150000000e1  

1.250000000e1   -1.250000000e1  

1.150000000e1   -1.150000000e1  

1.250000000e1   -1.250000000e1

Et vous, vous feriez vous avoir ? Comment votre outil gère-t-il ce cas ?

Ici, c'est du R. La fonction de base qui gère pareils cas est nommée rank. Sa documentation, help(rank), dit partiellement ceci :

Description:

 Returns the sample ranks of the values in a vector.  Ties (i.e.,
 equal values) and missing values can be handled in several ways.

Usage:

 rank(x, na.last = TRUE,
      ties.method = c("average", "first", "last", "random", "max", "min"))

Arguments:

   x: a numeric, complex, character or logical vector.

   na.last: for controlling the treatment of ‘NA’s.  If ‘TRUE’, missing
      values in the data are put last; if ‘FALSE’, they are put
      first; if ‘NA’, they are removed; if ‘"keep"’ they are kept
      with rank ‘NA’.

   ties.method: a character string specifying how ties are treated, see
      ‘Details’; can be abbreviated.

Details:

 If all components are different (and no ‘NA’s), the ranks are well
 defined, with values in ‘seq_along(x)’.  With some values equal
 (called ‘ties’), the argument ‘ties.method’ determines the result
 at the corresponding indices.  The ‘"first"’ method results in a
 permutation with increasing values at each index set of ties, and
 analogously ‘"last"’ with decreasing values.  The ‘"random"’
 method puts these in random order whereas the default,
 ‘"average"’, replaces them by their mean, and ‘"max"’ and ‘"min"’
 replaces them by their maximum and minimum respectively, the
 latter being the typical sports ranking.

Traduction à l'arrache :

Synopsis:

 Retourne les rangs des éléments contenus dans la liste indiquée. Propose
 plusieurs possibilités de traitement des éléments ayant des valeurs égales
 ou/et manquantes.

Signature:

 rank(x, na.last = TRUE,
      ties.method = c("average", "first", "last", "random", "max", "min"))

Arguments:

   …
   ties.method: une chaîne de charactère indiquant comment ranger les éléments de
 même(s) valeur(s). Voir la section « détails » ici-bas.

Détails:

 Les rangs seront bien définis si toutes les valeurs sont différentes et
 s'il n y a pas de valeurs manquantes : ce sera le résultat d'une
 permutation de seq_along(x). S'il y a certains éléments partageant des
 valeurs égales (appelées « égalités » dans la suite), leurs rangs
 dépendront de l'argument « ties.method » qui prend les valeurs suivantes :
 "first", les rangs des égalités sont pris suivant les indices croissants
 selon lesquels elles apparaissent dans la liste en entrée ; "last" procède
 comme "first", cette fois-ci en prenant les indices décroissants ;
 "random" range aléatoirement les égalités ; "average" est la méthode
 utilisée par défaut et moyenne les rangs des égalités ; "max" considère le
 rang de la dernière égalité à apparaître dans la liste ; "min" en
 considère celui de la première …

Talk is cheap, show me the code.

print(R.version.string)

set.seed(39)

eg <- new.env(parent = emptyenv())
eg$b <- c(21L, 58L, 21L, 0L)
eg$critères <- c("first", "last", "random", "average", "max", "min")

print(eg$b)
for (i in eg$critères) cat(i, "\t: ", rank(b, ties.method = i), "\n")

Les sorties ressemblent à quelque chose du genre

[1] "R version 3.3.2 (2016-10-31)"
[1] 21 58 21 0
first : 2 4 3 1
last : 3 4 2 1
random : 3 4 2 1
average : 2.5 4 2.5 1
max : 3 4 3 1
min : 2 4 2 1


Les discussions en rapport avec systemd ont une certaine tendance à déchaîner les passions. Si, disons dans une décennie pour prendre du recul, des anthropologues/sociologues se penchent sur les mécanismes en jeu pendant la naissance/(dé)croissance de systemd, plusieurs leçons pourront émerger à la place du côté popcorn actuel.
À noter que sur LWN aussi, les débats semblent avoir dégénéré : 226 commentaires au moment où ce message est rédigé ; quand l'embargo sur l'article sera levé, on verra sur quoi ça ferraillait.

[…] c'est beaucoup plus ça le problème : du code spécifique à systemd dans des programmes.

En l'occurrence, ce qui était proposé pour tmux était plutôt du code spécifique à PAM, histoire de notifier le gestionnaire de session que le processus tmux pourrait être détaché de la session dans laquelle il a été lancé. Le mainteneur de tmux a refusé soit d'écrire pareil code soit de recevoir des patches implémentant ce comportement. systemd propose des possibilités de faire avec le statu quo tout en nettoyant le système après la fermeture des sessions. Mais dans la discussion sur Fedora-devel, la notion de « logout » n'a pas été explicitée malgré au moins deux demandes dans ce sens ; il paraît sous-entendu par les mainteneurs de systemd que logout est à prendre dans le sens de loginctl bien que d'autres types de logout soient envisageables, comme souligné dans différents fils sur le sujet.

Entretemps, Zbigniew Jędrzejewski-Szmek a promis de chercher un moyen de patcher systemd pour qu'il laisse screen en exécution même après un logout et sans passer par systemd-run.

Titre provocateur certes mais à la lecture des commentaires, je n'ai pas pu m'empêcher de penser que Fedora ne serait pas loin d'être une valeur aberrante si on tentait d’échantillonner sur les distributions des commentateurs sur ce fil. Pourquoi penser ça ?

1. Dans ce fil, divers liens et discussions renvoient vers l'upstream –systemd– pour surtout noter le bon paramètre à renseigner.
2. Dès qu'il s'agit de discuter de l'intégration de systemd dans les distributions, c'est Debian dont il s'agit grosso modo (normal, l'auteur du journal utilise Debian)
3. L'avis des mainteneurs et/ou des développeurs de systemd est furtivement évoqué, notamment dans ce commentaire.

Il est bien sûr flagrant que la discussion est riche, qu'il y a de riches propositions de configurations/comportements de systemd et des distributions qui en font usage. Cependant, ça m'a personnellement étonné de constater que l'endroit où s'est passé « la discussion upstream »¹ n'est mentionné que très indirectement (voir le point 3 ici-haut) alors que bien de « discussions downstream » sont franchement reprises.

En parcourant ce fil¹, on se rend compte que les commentateurs sont, non seulement des mainteneurs ou des développeurs de systemd, mais aussi maintes contributeurs à Linux soi-même y interviennent. Dans ce fil-là se trouvaient déjà la plupart des choses écrites dans ce fil-ci. Un exemple parmi tant d'autres : la notion intéressante de « controlling terminal » qui semble ne pas encore être consensuelle ici a déjà été débattue.

Bref, il me semblait être de notoriété publique que les versions de développement de systemd sont testées par leurs propres développeurs dans Fedora. En complément des mailing lists d'autres distributions, il irait de soi alors de jeter un coup d'œil à celles de Fedora si on cherchait à connaître le pourquoi du comment d'un choix fait dans systemd : la probabilité est élevée de lire dans ces dernières des avis de première main.

Ironie de l'histoire, un participant à la discussion upstream a annoncé la naissance d'un fil sur les listes Debian comme si c'était le moment idoine de servir du pop corn.

Le combo xrandr & gtf pourrait être utile, quelque chose du genre :

xrandr | grep --word-regexp 'connected' #1
gtf 1920 1080 60 #2
xrandr --newmode AAA #3
xrandr --addmode BBB CCC #4

1. Détecter des informations sur les écrans branchés, la donnée la plus utile pour la suite étant leurs IDs.
2. Définir un mode d'affichage avec une résolution adéquate.
3. AAA : dans les sorties obtenues en 2), tout ce qui suit Modeline à partir de l'ouverture des guillemets (inclus).
4. BBB : l'ID de l'écran sur lequel appliquer le nouveau mode. CCC : La partie entre guillemets dans les sorties obtenues en 2).

La nouvelle configuration se retrouve dans le fichier adéquat, ~/.config/monitors.xml, et est visible dans la fenêtre des paramètres (ici: Settings → Hardware → Displays) où la finition peut alors être faite ; lxrandr peut aussi faire le boulot de finition.

Bonjour Sarcastic ,

Toutes mes plates pour la période d'hibernation.

Sans transition, d'abord, la fonction image (bibliothèque base) peut aider à obtenir des résultats semblables à ceux de Gnuplot. Ensuite, pour des résultats améliorés, on peut voir du côté de la fonction image.plot (bibliothèque fields) ; dans les deux cas, la bibliothèque akima peut accomplir l'interpolation. Puis, si on veut ajouter de la perspective à la visualisation, la bibliothèque misc3d pourra aider. Enfin, à mon avis, ggplot2 est inadéquat pour ce genre de traitement. Foin de verbiage, place au code.

• Pre-processing et quelques définitions

invisible(sapply(c("akima", "fields", "ggplot2", "gridExtra", "misc3d"), function(xxx) {
    library(xxx, character.only = TRUE)
}))

interpoCoord <- function(component) {
    return(seq(
        from = min(component),
        to = max(component),
        length.out = 2 * length(component)
    ))
}

utilFields <- function(interpolated, xText = "", yText = "", legText = "") {
    image.plot(interpolated, horizontal = TRUE, legend.lab = legText)
    title(xlab = xText, ylab = yText)
}

rphys1 <- read.table("rphys_a1_K_1_3.dat", sep = "", quote = "", skipNul = TRUE)
rphys2 <- read.table("rphys_a2_K_2_3.dat", sep = "", quote = "", skipNul = TRUE)
names(rphys1) <- names(rphys2) <- c("x", "y", "z")

rphys1Smooth <- with(rphys1, interp(x = x, y = y, z = z , xo = interpoCoord(x), yo = interpoCoord(y)))
rphys2Smooth <- with(rphys2, interp(x = x, y = y, z = z, xo = interpoCoord(x), yo = interpoCoord(y)))

imWidthBase <- 800
imHeightBase <- 600
imWidthFields <- imWidthBase - 350
imHeightFields <- imHeightBase - 100

shapeChar <- 19
shapeSize <- 3
lowCol <- "#720808"
highCol <- "#ffff00"
oddMargins <- unit(c(.01, .01, .01, .2), "cm")
evenMargins <- unit(c(.01, .2, .01, .01), "cm")

• Bibliothèque base

png("rphys1_base.png", width = imWidthBase, height = imHeightBase)
image(rphys1Smooth, xlab = absTag, ylab = ordTag)
dev.off()

png("rphys2_base.png", width = imWidthBase, height = imHeightBase)
image(rphys2Smooth, xlab = absTag, ylab = "")
dev.off()

• Bibliothèque fields

png("rphys1_fields.png", width = imWidthFields, height = imHeightFields)
utilFields(rphys1Smooth)
dev.off()

png("rphys2_fields.png", width = imWidthFields, height = imHeightFields)
utilFields(rphys2Smooth)
dev.off()

• Bibliothèque misc3d

Warning : La projection des perspectives est un traitement très lourd pour ces données !

sceneObj1 <- with(rphys1, surfaceTriangles(x, y, z, material = "shiny"))
sceneObj2 <- with(rphys2, surfaceTriangles(x, y, z, material = "shiny"))

exportScene(sceneObj1, filename = "rphys1_3D", format = "OFF")
exportScene(sceneObj2, filename = "rphys2_3D", format = "OFF")

drawScene(sceneObj1, engine = "standard")
drawScene(sceneObj2, engine = "standard")

• Bibliothèque ggplot2

fig1 <- ggplot(rphys1, aes(x, y, fill = z)) +
    geom_raster(interpolate = TRUE) +
    scale_fill_continuous(low = lowCol, high = highCol, name = "") +
    xlab("") + ylab("") +
    theme(legend.position = "top", plot.margin = oddMargins)

fig2 <- ggplot(rphys2, aes(x, y, fill = z)) +
    geom_raster(interpolate = TRUE) +
    scale_fill_continuous(low = lowCol, high = highCol, name = "") +
    xlab("") +
    theme(legend.position = "top", axis.title.y = element_blank(), axis.text.y = element_blank(), plot.margin = evenMargins)

fig3 <- ggplot(rphys1, aes(x, y, colour = z)) +
    geom_point(shape = shapeChar, size = shapeSize) +
    scale_colour_gradient(low = lowCol, high = highCol, name = "") +
    xlab("") + ylab("") +
    theme(legend.position = "top", plot.margin = oddMargins)

fig4 <- ggplot(rphys2, aes(x, y, colour = z)) +
    geom_point(shape = shapeChar, size = shapeSize) +
    scale_colour_gradient(low = lowCol, high = highCol, name = "") +
    xlab("") +
    theme(legend.position = "top", axis.title.y = element_blank(), axis.text.y = element_blank(), plot.margin = evenMargins)

grid.arrange(fig1, fig2, ncol = 2, respect = TRUE)
grid.arrange(fig3, fig4, ncol = 2, respect = TRUE)

Note. À part ceux de ggplot2, le reste des résultats s'interfacent très péniblement avec Tikz. Donc Gnuplot gagne haut la main sur la question de l'interopérabilité avec LaTeX et sur celle de la légèreté+rapidité, modulo mes connaissances très minimes sur Tikz : je suis preneur des propositions de comment éviter des erreurs du genre

TeX capacity exceeded, sorry [main memory size=5000000].

Oui, j'ai lu des propositions de solutions de ce type mais rien n'y a fait.

Ce commentaire est un aveu d'incompétence : "Je ne suis pas X".

Pas physicien nucléaire. Dans l'incapacité de générer des données de test après avoir regardé les diverses quantités et relations de la Physique, je me suis fait des données bidons, histoire d'illustrer ggplot2. On y va :

invisible(sapply(c("ggplot2", "tikzDevice", "gridExtra"), function(xxx) {
    library(xxx, character.only = TRUE)
}))

intervals <- seq(-40, 40)
celerity <- 299792458
hbar <- 1054571726e-34

sampleData <- expand.grid(x = intervals, y = intervals)

fakeQuantumRadius <- hbar * celerity / exp(sin(sampleData$x) * cos(sampleData$y))
sampleData$z1 <- 2 * fakeQuantumRadius
sampleData$z2 <- fakeQuantumRadius / 2

shapeChar <- 20
lowCol <- "chocolate4"
highCol <- "yellow"

fig1 <- ggplot(sampleData, aes(x, y, colour = z1)) +
        geom_point(shape = shapeChar) +
        scale_colour_gradient(low = lowCol, high = highCol, name = "$R = 2R_q$",
                              label = seq(from = 0, to = 20, by = 5)) +
        xlab("$\\hbar\\omega / E_B$") +
        ylab("$\\hbar\\omega_{dc} / E_B$") +
        theme(panel.background = element_blank(), legend.position = "top")


fig2 <- ggplot(sampleData, aes(x, y, colour = z2)) +
        geom_point(shape = shapeChar) +
        scale_colour_gradient(low = lowCol, high = highCol, name = "$R = R_q / 2$",
                              label = seq(from = 1, to = 5)) +
        xlab("$\\hbar\\omega / E_B$") +
        theme(panel.background = element_blank(), legend.position = "top",
              axis.title.y = element_blank(), axis.text.y = element_blank())


tikz("exemple_bidon.tex", standAlone = TRUE, width = 8, height = 5.33)
grid.arrange(fig1, fig2, ncol = 2)
dev.off()

Le fichier exemple_bidon.pdf fait 838.8 kB. Avec ImageMagick :

convert -density 150 exemple_bidon.pdf -quality 100 exemple_bidon.png

Pas graphiste. Concernant la rasterisation, je me contente de citer quelques bibliothèques en R qui pourraient t'intéresser même si le langage n'est pas vraiment l'outil adéquat pour faire du Traitement d'Image avancé. Les bibliothèques alors : raster, rasterVis, adehabitatMA, Cairo, readbitmap

On dirait qu'il y a un petit souci avec la partie basse de l'image, à moins que le "découpage" ait été intentionnel.
J'ai une vague idée de ton pipeline mais l'idéal serait d'avoir un code qui part de la lecture d'un de tes CSVs jusqu'à la création d'une image ; comme cela, j'essaierai de reproduire le traitement en R. Ou alors, un lien vers quelque chose de semblable sera aussi suffisant.

As-tu un exemple de ce que tu fais habituellement et que tu aimerais refaire en R ? Si on prend ceci par exemple :

library("misc3d")
library("tikzDevice")

tikz("parametric3d.tex", standAlone = TRUE)

parametric3d(fx = function(u,v) u,
             fy = function(u,v) sin(v)*(u^3+2*u^2-2*u+2)/5,
             fz = function(u,v) cos(v)*(u^3+2*u^2-2*u+2)/5,
             umin = -2.3, umax = 1.3, vmin = 0, vmax = 2*pi,
             scale = FALSE, color = "red", color2 = "blue",
             material = "shiny", engine = "grid")

dev.off()

Après compilation du fichier .tex, la résolution est plus que respectable :

L'image est une capture d'écran de la "partie utile" dans le fichier parametric3d.pdf. Sa taille : 312.2 kB pour 946 x 731 pixels. Le PDF fait 318 kB.

Bonjour,
Concernant Gnuplot, je ne pourrais répondre, quelqu'un d'autre connaissant à la fois R et Gnuplot pourrait t'éclairer.
Quant à Tikz, on configure les dépendances système de façon adéquate (distribution LaTeX) et après, Tikz sera considéré comme un périphérique de graphique au même titre que les autres (PDF, PNG, JPG, X11, …). Cela est valable quel que soit le système graphique qu'on souhaite utiliser et peu importe les fonctions graphiques qu'on manipule, notamment mettre plusieurs graphiques sur une même zone de rendu. Je reprends le même exemple :

invisible(sapply(c("ggplot2", "tikzDevice", "grid", "gridExtra"), function(xxx) {
    library(xxx, character.only = TRUE)
}))

humPop <- read.csv("./hum-pop.csv")
names(humPop) <- c("Year", "Population")

humLin <- qplot(x = Year, y = Population, data = humPop, geom = c("point", "smooth"), main = "Linear")

humLog <- qplot(x = Year, y = Population, data = humPop, geom = c("point", "smooth"), log = "y", main = "Logarithmic")

#Les sorties vont dans le périphérique par défaut
grid.arrange(humLin, humLog, ncol = 2, main = "Earth Population Over Time")

#Nous indiquons le périphérique de destination des sorties
tikz("plotting_outputs.tex")
grid.arrange(humLin, humLog, ncol = 2, main = "Earth Population Over Time")
dev.off()

La sortie ressemblera à ça :

Dans le fichier TEX généré, ne pas oublier d'inclure le préambule et l'environnement document, quelque chose du genre :

\documentclass[10pt]{article}

\usepackage{tikz}
\usepackage[active,tightpage,psfixbb]{preview}
\PreviewEnvironment{pgfpicture}
\setlength\PreviewBorder{0pt}
\usepackage[T1]{fontenc}
\usetikzlibrary{calc}
\batchmode

\begin{document}
%contenu du fichier généré en R
\end{document}

Le mainteneur du binding de Tikz en R est Yihui Xie ; il a écrit d'autres bibliothèques spécialisées dans le traitement de LaTeX, Markdown, HTML et compagnies : voir sa page sur GitHub. En particulier, knitr est un authentique couteau suisse.

Merci pour les clarifications et astuces sur le téléversement. Voici donc les sorties du code se trouvant dans mon précédent commentaire :

Première sortie

Deuxième sortie

Bonsoir,

J'aimerais noter qu'en R, les systèmes de graphiques diffèrent surtout de par leurs philosophies. Un aperçu sommaire infra, sans prétendre à l'exhaustivité.

• Le système traditionnel : on dessine (ou ajoute des éléments) sur le graphique courant, il est impossible de modifier quoi que ce soit d'un élément déjà dessiné. C'est le plus connu car venant nativement avec R dès les premières versions ; nous le devons principalement à Ross IHAKA.

• Le système grid : un modèle informel représente les objets graphiques indépendamment du rendu ; on peut donc mettre à jour ces objets. Les systèmes de coordonnées sont liés à des viewports et non pas à la zone de dessin elle-même, ce qui permet de concevoir des graphiques sophistiqués. Ce système a vu le jour avec la thèse de doctorat de Paul MURRELL ; son principal défaut est le manque de primitives natives pour les graphiques statistiques.

• Le système lattice ajoute au système grid les idées de William S. CLEVELAND sur les treillis (mathématiques). On a alors une grammaire de graphiques à disposition mais le modèle reste informel.

• ggplot2 donc : reprise des bonnes idées que présentent tous les systèmes précédents, plus un modèle formel cette fois-ci.

• Ce n'est pas tout : voir http://cran.r-project.org/web/views/Graphics.html.

Quant à l'objet de la dépêche, pour reprendre le commentaire de eingrossfilou tout en restant dans le minimalisme souhaité par l'auteur du journal, je proposerais ceci :

library("ggplot2")

humPop <- read.csv("./hum-pop.csv")
names(humPop) <- c("Year", "Population")

qplot(x = Year, y = Population, data = humPop, geom = c("point", "smooth"), main = "Earth Population Over Time (linear)")

qplot(x = Year, y = Population, data = humPop, geom = c("point", "smooth"), log = "y", main = "Earth Population Over Time (log)")

P.S. C'est mon premier commentaire, j'ignore comment téléverser une image sur les serveurs de LinuxFR.