Michaël a écrit 2929 commentaires

En général “Madame” indique une femme.

Quant à la « logique en général » de l'anglais, si la langue me semble au départ plus simple à apprendre que le français, elle montre son manque de cohérence dès qu'on désire parler de façon un peu subtile/avec des constructions un peu complexes.

Cela semble plus simple que le français, à condition qu'on sache déjà parler français, ce qui est assez biaisé. Cela s'explique par les nombreux échanges et contacts entre les deux langues

Deux points notables sont une construction de la phrase très proches – une divergence est l'ordre des adjectifs épithètes, c'est assez petit! – un lexique greco-latin très important dans le domaine technique ou scientifique. À titre personnel je trouve que le point le plus difficile pour un francophone apprenant l'anglais est la maîtrise de l'emploi des temps, mais dans la langue orale on s'en tient en général à l'indicatif et pour les autres modes à quelques tournure fixes (“Have you ever been in…” ”Could you …”)

Pourquoi genrer la table et le tabouret ?

Pour pouvoir utiliser des pronoms dans des phrases complexes “Je me suis assis sur le tabouret devant la table et il s'est cassé.” alors qu'en anglais on est obligé soit de se répéter soit de changer la structure de la phrase “I took a sit on a stool for the table and it broke.” dit que c'est la table qui s'est cassée alors on peut dire “I took a sit on a stool for the table and the stool broke.” ou bien “I took a sit for the table on a stool and it broke.” Avoir un genre pour les noms communs permet de s'exprimer clairement, sans ambiguïté, sans pour autant se répéter.

Tu voudrais un générateur d'algorithme efficace en fonction de la précision souhaitée?

C'est ce qu'il m'a semblé comprendre. C'est particulièrement difficile parceque si on prend la borne la plus pessimiste de l'erreur elle est bien pire que tout ce qui arrive en pratique (on perd un bit de précision à chaque addition, on divise la précision par deux en prenant une racine carrée, etc.) et que le premier affinage qui vient à l'idée est de prendre en compte la distribution des entrées possibles pour en déduire la variable d'erreur et optimiser cette variable, et je doute que ces calculs soient faciles à mener, surtout si on quitte le domaine des fractions rationnelles en ajoutant les expoentielles, etc.

Si on veut sérieusement aller dans cette direction, il me semble que la première chose à faire serait de traiter les cas des polynômes car ce doit être le plus facile.

Ensuite dans le calcul scientifique il ne faut pas oublier que:

1. Les entrées elles-même ne sont pas nécessairement exactes

2. Beaucoup d'algorithmes numériques sont itératifs et s'arrêtent lorsque “l'erreuer est assez petite” sans savoir a priori combien d'opérations vont être utilisées (p.ex. les théorèmes de point fixe – dont la méthode de Newton quand elle marche bien – ou bien les algo d'optimisation comme le simulated annealing.)

J'ai fait une recherche mais il ne semble plus être édité

Tu peux certainement le consulter à la BU la plus proche de chez toi. Comme il est intéressé par l'algèbre il ne fait pas trop la géométrie réelle (paramétrisation du cercle par l'exponentielle complexe, ce qui est le problème difficile justifiant la présentation moderne qui prend les choses à l'envers, en partant d'une définition a priori de l'exponentielle.)

(ij = -ji ?)

Dans la présentation classique des quaternions, où on prend comme base sur R, 1, i, j, k avec les relations qui vont bien (comme p.ex. dans Wikipedia).

Je me suis demandé si on ne pouvais pas prendre le problème dans l'autre sens. C'est à dire de proposer un langage dans lequel on déclare utiliser un nombre réel pour faire une opération, ce qui permet ensuite de transformer le code. Mais comme un ordinateur ne peut pas calculer avec des réels, il faut des restrictions, typiquement un range et une précision.

Je ne suis pas sûr de bien te comprendre, mais j'ai l'impression qu'en gros tu veux que le langage se retienne le plus longtemps possible de faire les calculs sur les nombres réels jusqu'à ce que “l'expression finale” soit connue, pour être adéquatement simplifiée avant que le calcul proprement dit n'ait lieu, en choisissant une précision adéquate?

Je pense qu'on est très loin de pouvoir faire ça de façon automatique et dans une généralité assez grande pour que le traitement soit implémenté par les langages généralistes. La difficulté tient dans le fait qu'il faut pouvoir faire des optimisations qui soient cohérentes dans un contexte que le compilateur ne connaît a priori pas, par exemple un système d'équations que le compilateur ne connaît pas parceque les systèmes d'équations ne sont pas un concept du langage.

Dans ce genre d'applications, on fait une analyse a priori des calculs qu'on a à mener, et on peut aussi, selon l'entrée, choisir telle ou telle méthode de calcul qui va minimiser l'erreur, au besoin en s'aidant d'un logiciel de calcul symbolique, puis après cette analyse on implémente le calcul en flottants. En gros ce que tu proposes de laisser au compilateur est aujourd'hui largement un processus manuel.

Je ne sais pas si cela existe déjà. Mais j'imagine bien un langage qui propose les fonctions typiques (tan, sin, integral, etc…) qui ne sont pas des fonctions en C écrite à la main avec une précision maximum sur base d'une série quelconque, qui s'enchainent. Mais leur vrai définition mathématique qui peuvent ensuite se réduire automatiquement à un polynôme, avec la précision finale demandée.

La principale difficulté est que c'est très difficile de savoir où “couper” la série pour obtenir la précision nécessaire, sans faire trop de calculs. En pratique il faut faire une analyse au cas par cas de chaque série à calculer et utiliser des heuristiques pour gagner du temps dans le calcul. Aussi la plupart des implémentations des fonctions mathématiques de la libc (hors implémentations spécialisée) ne calculent pas toutes les fonctions de façon exacte (le ou les deux derniers bits sont souvent faux, pour raccourcir le calcul.) La bibliothèque CRLIBM implémente des fonctions exactes en double précision, le lien est une documentation abondante qui permet de se faire une idée de la complexité du problème et des méthode utilisées.

Le programme dc utilise des flottants en précision arbitraire, cela peut te donner une seconde piste pour tes investigations:

Calcul d √2 avec une précision de 199
```
199 k
2 v p
1.4142135623730950488016887242096980785696718753769480731766797379907\
324784621070388503875343276415727350138462309122970249248360558507372\
126441214970999358314132226659275055927557999505011527820605714

2 ^ p
1.9999999999999999999999999999999999999999999999999999999999999999999\
999999999999999999999999999999999999999999999999999999999999999999999\
999999999999999999999999999999999999999999999999999999999999998
```

(cf. https://apod.nasa.gov/htmltest/gifcity/sqrt2.10mil pour le premier million des décimales de racine de 2.)

Par contre toutes les fonctions classiques d'une bibliothèque mathématique (exponentielle, logarithme, gamma, Bessel, etc.) ne sont pas implémentées. Les algorithmes de base pour implémenter des nombres flottants avec une précision arbitraire est décrite dans le livre de Knuth (The Art of Computer Programming Vol. 2).

Un intérêt du travail en précision arbitraire est au contraire d'utiliser une très faible précision, cela permet de facilement comparer la stabilité numérique des algorithmes utilisés.

Ici il y a plein de petites déviations de terminologie, qui dépend de la spécialité. Quand on fait de l'arithmétique ou de la géométrie algébrique on considère que les anneaux et a fortiori les corps sont commutatifs et ont une unité et on nomme tout ce qui diverge dans le grand fourre-tout des “algèbres” que l'on qualifie de manière ad-hoc (algébre unitaire ou non, commutative ou non, associative ou non, etc.) Mais dans les spécialités (géométrie non-commutative par exemple :-) ) on peut trouver des terminologies divergentes.

Petite correction sur mon commentaire précèdent : la véritable différence entre un corps et un anneau, c'est l'existence de la division (la multiplication est inversible).

Pour être plus précis, où tout élément non nul est inversible. Exemples notoires élémentaires d'anneaux qui ne sont pas des corps: l'anneau des nombres entiers (car 1 n'est le double d'aucun nombre entier p.ex.) et l'anneau des entiers modulo 6 (parceque 3 x 2 y vaut 0, donc ici aussi 1 n'est le double d'aucun nombre.) et pour les corps, les nombres rationnels, réels, et complexes, et les entiers modulo un nombre premier.

Sur les rapports entre anneaux et géométrie il y a le joli petit livre de Pierre Samuel “géométrie projective” qui part des axiomes de la géométrie plane pour retrouver le corps des scalaires sous-jascent (avec les figures que tu mentionnais) et redécouvre les corps finis dans son analyse.

Les quaternions sont associatifs et pas commutatifs (ij = - ij) et les octonions ne sont effectivement ni commutatifs, ni associatifs.

Du point de vue strictement calculatoire, le seul intérêt d'implémenter l'algèbre des quaternions par des matrices est que c'est une approche générale (on peut le faire pour toute la classe d'algèbres dont je parlais plus haut) et une solution spécialisée pour une algèbre spécifique a intérêt à être meilleure. :)

Le fait d'identifier les quaternions à des transformations linéaires d'un espace de dimension 4 (les transformations naturelles d'au dessus) ouvre plein de questions de géométrie – justement parceque la transformation est naturelle (on n'a pas besoin de faire un choix). Le groupe K des quaternions de norme 1 est une sphère de dimension 3, du coup en voyant les quaternions comme des transformations de l'espace à quatre dimension, on voit K comme un sous-groupe des transformations qui préservent la sphère – groupe orthogonal O_4, est-ce qu'on peut décrire K juste géométriquement, sans parler des quaternions (genre K est le stabilisateur de machin patin couffin)? Quels éléments il manque à K pour engendrer tout O_4? Quelles sont les classes de l'opération de K sur O_4? En regardant l'opération de K sur l'espace tangent à K en 1, on trouve aussi une représentation de K dans O_3, le groupe orthogonal de cet espace tangent, cela arrive aussi avec tout son lot de questions… en bref cette identification est une porte ouverte! :)

Pour autant, ça fait un peu explication que « quand on n'a qu'un marteau, tout souci est un clou… ». Le lien [complexe|quaternion|octonion] vers matrice n'étant pas forcément évident pour moi :-)

Cela vient juste de l'observation que si A est une algèbre alors tout élément a de l'algèbre définit deux opérations

la multiplication à gauche par a et celle à droite. Dans de bonnes conditions, cela donne une “modélisation” de l'algèbre comme sous-algèbre de l'algèbre des matrices, rien de bien arbitraire là-dedans (à part la base choisie, mais on peut parler de tout ça sans matrices pour se débarasser de cet arbitraire ;) )

On est très loin de la situation du marteau et du clou, parceque le point de vue “algèbre linéaire” dans l'étude des algèbres permet de démontrer de nombreux théorèmes, c'est à dire qu'identifier ce point de vue, loin de n'engendrer que des souffrances pour l'utilisation d'un outil inadapté au problème est très riche en enseignements.

Au contraire, je cherchais des infos sur les polynômes avec des complexes ou des quaternions, et je n'ai rien trouvé en ligne.

Ah okay, alors voici quelques pistes:

• Une pan important de la théorie sur les polynômes complexes est la théorie des fonctions holomorphes, ce sont les fonctions complexes de la variable complexe qui sont dérivables. Une partie importante de la théorie appliquée aux polynômes vise à comprendre comment les racines dépendent des coefficients, voir par exemple le calcul des résidus, la théorie de Sturm-Liouville, le théorème de Gauss–Lucas ou les théorèmes de Hurwitz. Du point de vue “recherche numérique des racines” c'est l'application de la méthode de Newton qui a fait découvrir les ensembles de Julia et de Mandelbrot. Une autre partie de la théorie complexe est liée au problème de représentation conforme – comment transporter deux parties du plan l'une sur l'autre en respectant les angles, où on essaie parfois de trouver des solutions polynomiales.

• Pour les polynômes, complexe ou non, les classes d'algorithmes importants sont ceux déduis de la recherche des bases de Grobner pour un idéal. En gros cela généralise la notion de PGCD d'une famille de polynômes aux cas où tout va mal. C'est surtout intéressant pour les géomètres algébristes et c'est expliqué avec un point de vue tout à fait algorithmique dans le livre de David Eisenbud.

• Les quaternions jouent un rôles très important en mathématiques, et surtout en géométrie algébrique, à cause du théorème de Hurwitz (les seules algèbres réelles normées et à division sont les réels, les complexes, les quaternions et les octonions) de la classification des algèbres de Jordan et du carré magique de Freudenthal – encore une fois c'est plutôt du matériel avancé.

puis tout retournait en matrice, car cela faisait moins d'opérations scalaires mathématiques que d'utiliser les quaternions.

En fait on peut représenter les quaternions par des matrices, notamment pour faire des calculs (Tout comme les complexes d'ailleurs.) C'est un cas général pour toutes les algèbres “bien comme il faut” (sur un corps, de dimension finie, intègre, associative) car on peut identifier un élément de l'algèbre à la multiplication par cet élément – qui est linéaire et peut donc être vu comme une matrice.

Mais typiquement, quand il y a du gros calcul en informatique, il est toujours question à 99.9% de matrice, pas de polynôme.

Ça dépend de ce que tu fais. :) Mais je ne comprends pas pourquoi tu en veux à ces pauvres polynômes, ni à vrai dire ce à quoi tu penses quand tu opposes polynômes et matrices.

Il ne faut pas perdre de vue que les matrices, en plus de leurs applications en algèbre linéaire sont aussi utilisées comme des gros tableaux de nombres dans des simulations numériques. Si le point de vue “algèbre linéaire” disparaît c'est un peu artificiel de parler de matrice, mais bon tout ça c'et un peu du jeu de mot.

Dans tout ce qui est calcul numérique on va utiliser beaucoup de matrices de flottants. Si tu cherches des calculs qui utilisent beaucoup de polynômes il faut aller voir du côté du calcul symbolique, par exemples des outils de géométrie algébrique qui étudie le lien entre la géométrie d'un objet et les équations polynomiales qui le définit, voir le programme Macaulay2 par exemple. Ce logiciel est probablement inutilisable si on n'a pas un DEA/Master dans la discipline mais je te garantis que si tu veux occuper un ordinateur avec des calculs sur des polynômes pendant plusieurs jours, c'est un excellent outil.

En passant, je répète ce que j'ai dis ailleurs, le formalisme utilisé par exemple sur Wikipedia rend la traduction d'un théorème en code très compliqué, voir incompréhensible. Les matheux pourraient faire un effort pour les pauvres informaticiens qui veulent utiliser leurs outils ?

Les textes de Wikipedia sont même souvent incompréhensibles pour un mathématicien spécialisé – je suppose que ça dépend des disciplines – je ne peux que te recommander de plutôt utiliser des livres ou des cours de fac, souvent dispo en ligne, si possible orientés vers le calcul scientifique pour avoir des implémentations potables.

En pratique c'est un gros problème quand on fait du calcul scientifique (par exemple en géométrie algébrique): les outils de calcul sont de relativement bas niveau et donc il faut “traduire” son problème dans une représentation qu'on va pouvoir faire ingurgiter à un système de calcul., et souvent on fait des erreurs en traduisant.

Tu devrais taper le titre de l'article dans ton moteur de recherche préféré. :)

heu … ouais peut-être. Je n'ai aucune idée de comment fonctionne docker. Tout au plus j'en sais les plus vils stéréotypes; genre que je ne vais pas installer une VM de 10Gi qui va manger mon processeur juste pour compiler un truc bête en LaTeX.

L'intérêt serait de normaliser les dépendances de préparation du document, pour qu'un contributeur puisse préparer une image Docker avec ta recette au lieu d'installer les logiciels requis (classqieus problèmes de version, etc.)

Je tient un prof de math, je pose ma question : est-ce que les polynômes de complexe ou de quaternion existent et ont les mêmes propriétés que les polynômes avec des réels ?

Oui pour les complexes, un peu pour les quaternions, et bien que tu ne l'aies pas demandé, pas trop pour les octonions (la dernière algèbre normée).

En gros les anneaux de polynômes sur un anneau A répondent à la question

Est-ce que je peux construire un anneau A[X] qui contient A et un élément supplémentaire X

• de sorte que je calcule comme dans A
• de sorte que je calcule de façon universelle, càd qu'une égalité de polynômes devienne une égalité entre éléments de A si je substitue un élément de A à X.

Si la multiplication est associative et commutative alors la réponse est oui, si certaines de ces propriétés disparaissent (cas des quaternions ou des octonions) alors on peut toujours cacluler formellement sur ces anneaux, mais il faut faire plus attention et comme a des relations tout à fait différentes des anneaux de polynômes classiques qu'on leur donne un autre nom (cf. algèbre de Jordan).

J'ai l'impression que cette branche des mathématiques a un peu laissé la place aux matrices, mais les cours parlent beaucoup des polynômes. De plus les opérations sur les matrices sont un peu moins "souple".

De quelle branche des mathématiques parles tu? Aujourd'hui les polynômes ou les matrices font partie du bagage de base du mathématicien, quelle que soit sa spécialité. Si on regarde des branches plus spécialisées, comme la théorie algébrique des groupes de Lie, il y a beaucoup d'alèbre linéaire parcequ'on peut représenter les groupes de Lie algébriques comme des sous-groupes du groupe linéaire – et évidemment beaucoup de polynômes parceque c'est de la géométrie algébrique.

Oui, je le mentionne dans le commentaire auquel tu réponds. Le seul problème est que comme c'est une fonction d'utilisation relativement rare, on ne la découvre qu'a posteriori, lorsque c'est trop tard. :)

Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.

Je ne veux pas parler pour les gens qui sont farouchement opposés au multicore puisque je n'en fais pas partie. Cependant je peux faire quelques remarques qui tendent a relativiser l'importance de la disponibilité d'un système tirant partie des multiples cœurs.

Dans mon expérience professionnelle, j'ai eu à travailler sur des systèmes avec beaucoup de cœurs (environ 200) pour faire du calcul numérique (finance) et pour tirer pleinement parti de ce genre d'équipement il ne faut pas seulement paralléliser les calculs mais aussi travailler sur la localisation des données en mémoire pour éviter les mouvements de cache trop importants qui pénalisent grandement l'application. On peut bien-sûr faire du calcul numérique en OCaml ou dans n'importe quel langage de haut niveau et faire attention à la localisation des données mais certaines fonctionnalités des plateformes (de type OpenMP) sont plus faciles à utiliser dans certains langages, et puis il y a tout un écosystéme historique, comme des logiciels scientifiques (Mathematica il me semble) qui peuvent émettre du code C etc., ce qui dans l'ensemble fait qu'il est assez naturel dans ce contexte d'écrire la fonction de calcul dans un langage bas niveau et de faire un binding vers le langage de haut niveau – d'autant qu'il est relativement facile d'écrire ce type de bindings pour OCaml et Lisp, que Python est quasiment conçu “par design“ comme un langage facilement extensible en C++. (Lua a aussi une FFI très facile à utiliser mais je n'ai pas encore entendu parler de gens qui font du calcul scientifique en Lua.)

Le type d'application numérique qui demande un grand nombre de cœurs sur une machine donnée est assez spécifique, il faut que le calcul utilise abondamment toute la structure initiale, autrement il est plus avantageux de faire tourner le calcul sur plusieurs machines. Pour prendre deux exemples simples, un calcul du premier genre est le calcul du carré d'une grosse matrice carrée. On peut faire un calcul par blocs en parallèle, mais cela n'est pas facile à délocaliser parceque, si par exemple si on fait 4 blocs de même taille, il faut transférer 3/4 des données pour obtenir 1/4 du résultat (et plus le nombre de blocs augmente, pire le ratio est!). Un calcul du second genre sont les calculs exploratoires faits sur une classification, où chaque fil va faire un calcul très complexe sur une petite donnée ce qui se parallélise facilement sur des machines différentes (pas forcément facile ou judicieux de louer une machine à 200 cœurs en comparaison de la location de 100 machines à 2 cœurs).

En dehors du calcul scientifique une autre application du calculs en parallèle est l'écriture de serveurs. L'approche consistant à écrire un serveur monofil dont on fait tourner un grand nombre de copies derrière un répartiteur de charge offre tellement d'avantages (logique d'application plus simple, circonscription a priori des erreurs, bugs plus facilement reproductibles, déploiement plus facile à redimensionner) qu'à la condition qu'il ne pose pas de problème de synchronisation particulier, c'est souvent la solution privilégiée.

Pour revenir au cas particulier de pijul je n'au aucune idée des algorithmes mis en jeu ni des structures de données utilisées donc je ne peux pas juger de l'avantage que ce logiciel peut tirer ou non du parallélisme léger (par opposition au fork & IPC) sur une architecture multicœur, mais dans ma petite expérience personnelle les problèmes pour lesquels ce type de parallélisme est bien adapté sont plutôt une niche qu'une généralité – surtout parceque pour que cela soit vraiment efficace il y a un travail considérable à faire sur les structures de données, travail d'autant plus critique sur les machines grand public qui ont souvent moins de mémoires cache que de cœurs. Ce n'est pas que je sois contre OCaml multicœur – et j'ai d'ailleurs bien du mal à comrpendre qu'on puisse l'être – et je serai même ravi de jouer avec lorsqu'il sera là, mais il me semble particulièrement facile de surestimer les bénéfices qu'on peut retirer de ce genre de parallélisme.

Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU.

Je ne connais pas async, quant à Lwt il me semble qu'elle utilise la même approche que NodeJS (à moins que ce ne soit le contraire) en utilisant un deuxième fil d'éxécution (Thread lourd géré au niveau de l'OS par oppositions aux Threads légers implémentés par Lwt.) Comme je l'esquissais plus haut cette approche à le mérité de la simplicité au niveau de l'application dans les cas où le redimensionnement horizontal d'une application est possible, cela permet de travailler avec une variable simple, le nombre de processus, au lieu d'une grandeur composée par le nombre de processus auquel il fait adjoindre le nombre de fils d'éxécution. Évidemment, cela ne convient pas à tous les les problèmes.

Ceci dit je suis bien d'accord que la situation des Threads sous OCaml est loin d'être idéale mais j ne suis pas certain que la remarque à laquelle pmeunier fait allusion est spécifique à OCaml.

Comparer des langages de programmation est difficile, et il est facile d'être mal interprété.

Je n'ai pas jugé utile de le préciser mais je le fais à présent: loin de moi l'idée d'ouvrir une guerre de paroisses, ma question est tout à fait naïve – je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml. Donc du coup, merci beaucoup pour ta réponse!

Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.

Ça c'est un trait vraiment particulier, est-ce que tu sais l'expliquer historiquement?

Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).

Qu'est-ce qui ne vas pas avec les threads? Dans le cas de services dont le terme dominant de la performance est assujetti aux IO, l'approche alternative à la Lwt/NodeJS basée sur un thread système pour les IO, un thread système pour la logique de l'application, et des threads légers collaboratifs dans l'application et une échelonnement (“scalabilité” en bon franglais) horizontal pour monter en charge est maintenant bien mise à l'épreuve; mais c'est totalement hors de propos pour un gestionnaire de version, non? Du moins pour la partie client. ;)

Pour OCaml j'ai écrit rashell que je recommande. :)

Ah oui effectivement, comme mathématicien assez peu versé dans la logique je considère un peu rapidement que les sommets d'un graphe et ses arêtes sont des ensembles, mais si on relaxe ces conditions au même niveau que celles que l'on met sur les objets d'une catégorie, il n'y a pas d'obstacle à associer formellement les deux notions.

Comme te l'a déjà répondu Michaël : toute catégorie peut être vu comme un graphe orienté (on les présente souvent ainsi d'ailleurs) mais la réciproque n'est pas vraie

Ce n'est pas plutôt le contraire? Un graphe orienté peut toujours être transformé en catégorie (attention, les morphismes de la catégorie correspondent aux chemins!) tandis qu'une catégorie peut ne pas être transformée en graphe, essentiellement parceque les objets de la catégorie ne forment pas nécessairement un ensemble.

Ceci-dit, c'est une objection essentiellement scolaire parcequ'il va de soi qu'on ne peut tirer quelque chose du point de vue “graphe” sur les catégories que pour des catégories bien particulières.

Pijul était initialement écrit en OCaml, il a été ré-écrit en Rust au moment de la version 0.2 début 2016.

Qu'est-ce qui a motivé ce changement? Est-ce qu'il y a des choses plus faciles en Rust qu'en OCaml? Et réciproquement? Bref, si tu as choses à dire sur l'étape de traduction, que cela concerne la motivation, les difficultés ou les résultats, ça m'intéresse. :)

Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers. Je peux envisager de voir un graphe orienté comme une catégorie, en tant que suite de morphismes dans le même groupe (transformation de fichiers) à chaque fois, mais à l'inverse, voire toute catégorie comme un graphe orienté, j'ai plus de mal, puisque dans une catégorie par définition les morphismes de groupe n'ont à priori pas les mêmes ensembles de définition et d'image ?

Je pense que la façon habituelle de voir un graphe G comme une catégorie C est de dire que

1. Les objets de C sont les sommets du graphe
2. Les morphismes de C entre deux objets A et B sont les chemins de A à B dans le graphe G, que l'on compose comme les chemins de G.

C'est un “gag” assez déroutant de la théorie des catégories qu'à aucun moment elle ne demande que les objets soient des ensembles avec des éléments ni que les morphismes puissent être appliqués sur des éléments de ces objets. On peut aussi transformer groupes et monoïdes en catégories ou en graphes. Si ces manipulations semblent a priori un peu gratuites il ne faut pas perdre de vue que chacune des ces théories (graphes, catégories, monoïdes) ont chacune un corpus phénoménal de théorèmes ce qui justifie le besoin de changer de point de vue sur les objets qu'on étudie.

Qu'est-ce que tu veux dire exactement?

Ce dont je parle est la situation suivante: partant de la branche maintenance/v2.0 deux branches fix/bug-1 et fix/bug-2 sont “mergées“ vers une nouvelle branche patchset/v2.0.1 elle aussi issue de maintenance/v2.0, ce qui donne lieu à une résolution de conflit. Si maintenant on décide que le “patchset” patchset/v2.0.1 ne soit finalement pas ajouté à maintenace/v2.0 mais seulement à master alors on a envie de “rebaser” la branche maintenance/v2.0..patchset/v2.0.1 sur master et cela ne marche pas facilement parceque dans sa version la plus simple l'appel

git rebase --onto master --preserve-merges patchset/v2.0.1 maintenance/v2.0`

demande de rerésoudre les conflits résultant du “merge” de fix/bug-1 et fix/bug-2. C'est dans ce sens que “git ne sauvegarde pas les résolutions de conflit”. Ce comportement peut dépendre de la version (2.8.4 ici) et de la configuration (cf. rerere) mais c'est dans certains cas le fonctionnement normal de git.

Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :

Merci pour ces références! Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles – il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit – à moins d'un paramétrage spécial. C'est gênant lorsqu'on travaille sur l'historique, par exemple, dans les rebase complexes où figurent des résolutions de conflit, que git demande de résoudre à nouveau. Par ricochet cela rend inutilement pénible la fusion de deux dépôts GIT, puisque l'approche bébête consistant à importer (fetch) une deuxième historique COMMIT-0 … { historique complexe … } COMMIT-1 puis à faire un cherry-pick de COMMIT-0 sur la tête de la vieille historique puis un rebase de COMMIT-0..COMMIT-1 ne marche pas. Le problème peut être résolu grâce au filter tree mais c'est bien plus compliqué à mettre en œuvre et incroyablement lent. (J'en ai récemment fait un de 12h sur une historique assez modeste, 4 ans et équipe de 4 à 8 personnes.)