Le topic de la programmation: Et envoyez des sioux!

[Møgluglu]

Quelques tests fait sur un script simplifié du problème. Mais à vrai dire, je n'ai pas pensé à regarder le remplissage et la suppression des tableaux. Le remplissage se fait par calcul d'une fonction densité de probabilité avec loi normale suivant un ou deux axes, avec réplication du résultat dans le second axe pour le cas du 1d. Mais je n'ai pas ça dans le script simple avec lequel j'ai tester le argmax.

Du coup est-ce que tu as vraiment besoin de tes tableaux ? Tu ne peux pas calculer la fonction à la volée ?

Question subsidiaire, les fonctions de densité de proba sont-elles vraiment non-continues, non-dérivables et irrégulières au point que la seule solution pour trouver leur max soit de les échantillonner régulièrement sur tout l'intervalle ? Ou c'est plus compliqué que ça ?

[Thingazazi]

Du coup est-ce que tu as vraiment besoin de tes tableaux ? Tu ne peux pas calculer la fonction à la volée ?

Il faut que je stock le résultat quelque part, je dois appliquer des masques sur les valeurs infinies ou nan obtenues dans certains endroit des tableaux où l'un des paramètres n'est pas toujours défini.

Question subsidiaire, les fonctions de densité de proba sont-elles vraiment non-continues, non-dérivables et irrégulières au point que la seule solution pour trouver leur max soit de les échantillonner régulièrement sur tout l'intervalle ? Ou c'est plus compliqué que ça ?

Je dirai non aux trois premières questions, mais sans certitude. Sur l'ensemble des fonctions utilisées, il y en a une qui me pose soucis si je n'ai pas une résolution suffisante, la seule qui dépend des dimensions, toutes les autres n'ayant une dépendance que dans une.

Mais après réflexion, le problème vient peut-être de là, on fait peut être. A savoir que pour notre mesure V, notre pdf est calculée comme suit lorsqu'on la compare à notre abaque(x,y) avec x et y indépendant l'un de l'autre,:
(1./sqrt(2pi*sigma²))*exp((Abaque(x,y) - V(x,y))²/sigma²) sigma ayant pour valeur 0.1 suivant x et y, et V variant de -50 à 20, comme l'abaque en gros.
C'est du côté de l'abaque que je fais varier la résolution, elle à une forme assez spéciale que je ne pourrais pas décrire facilement.

Je vous montrerai des images, ce sera plus parlant.

Edit, j'ai reformulé un peu suite à des petite erreurs.

[Møgluglu]

Il faut que je stock le résultat quelque part, je dois appliquer des masques sur les valeurs infinies ou nan obtenues dans certains endroit des tableaux où l'un des paramètres n'est pas toujours défini.

Tu n'as intérêt à stocker des données que si tu les réutilises plusieurs fois derrière. Et appliquer un masque, c'est juste ajouter un if, non ?

Mais après réflexion, le problème vient peut-être de là, on fait peut être. A savoir que pour notre mesure V, notre pdf est calculée comme suit lorsqu'on la compare à notre abaque(x,y) avec x et y indépendant l'un de l'autre,:
(1./sqrt(2pi*sigma²))*exp((Abaque(x,y) - V(x,y))²/sigma²) sigma ayant pour valeur 0.1 suivant x et y, et V variant de -50 à 20, comme l'abaque en gros.
C'est du côté de l'abaque que je fais varier la résolution, elle à une forme assez spéciale que je ne pourrais pas décrire facilement.

Si ton problème c'est de trouver le max de ta fonction multivariée sur des intervalles donnés, et que tu sais calculer les gradients de ton abaque (et donc ceux de ta PDF), alors ça se fait en un coup de scipi.optimize.minimize : https://docs.scipy.org/doc/scipy/ref.../optimize.html
Et tu as le choix entre plein d'algos très intelligents implémentés de façon efficace.

[Anonyme20240202]

Yo les copains je vais me lancer dans un projet perso d'analyse de séries temporelles et de stats avec dans le tas de la jolie data visualization. (et dans une moindre mersure le tout parsemé de bonnes perfs si possible parce que ça va envoyer de la grosse donnée, donc multithreading & grid computing dans le tas)

Vous avez des recommandations niveau lib sympa ou langage/framework particulier?

Là je pense partir sur une base de python avec éventuellement des modules indépendants si j'ai besoin de perfs ou d'une lib en particulier.
L'idée sera de pas réinventer la roue et de lier tout le bouzin via le python. Genre si jamais y'a un truc mega cool en R je taperai dedans, etc.

Sinon je m'intéresse à Julia en ce moment, z'avez un avis d'expert expéditif? Ça a l'air cool

- - - Mise à jour - - -

Je suis aussi particulièrement intéressé par des libs qui permettent de faire des trucs du genre (le mec utilise une lib perso en l'occurence), animations et transformations 2D/3D

[Lazyjoe]

Quelques tests fait sur un script simplifié du problème. Mais à vrai dire, je n'ai pas pensé à regarder le remplissage et la suppression des tableaux. Le remplissage se fait par calcul d'une fonction densité de probabilité avec loi normale suivant un ou deux axes, avec réplication du résultat dans le second axe pour le cas du 1d. Mais je n'ai pas ça dans le script simple avec lequel j'ai tester le argmax.

Mouais. De manière général, pour ta problématique sur le calcul du max il n'y a pas grand-chose à optimiser en fait. Lire, comparer, sur un grand tableau le processeur va se tourner les pouces et c'est le débit de la mémoire qui va entrer en compte. Pas beaucoup d'intérêt à paralléliser cette opération sur une seule machine (sauf si il faut plusieurs coeurs pour exploiter toute la bande passante mémoire, possible sur "le gros serveur de calcul" ). Sinon, vu que tu as multiplié par dix la dimension en x et par 10 en y c'est pas très étonnant que ça prenne 100 fois plus de temps.

Mais bon, l'opération la plus efficace reste encore celle qu'on n'a pas besoin de faire. Donc comme le dit mogluglu, au minimum il faudrait calculer le max en même temps que tu calcules les valeurs du tableau (si il est vraiment indispensable de les conserver). Tu t'éviteras une lecture complète du tableau, et vu le calcul un poil lourd à faire sur chaque case y ajouter un calcul de max ne devrait même pas se ressentir sur les performances de cette étape.

Et pour le coup, ces calculs de valeurs m'ont l'air suffisamment intenses arithmétiquemnt que pour bénéficier d'une parallélisation.

Mais bon, l'opération la plus efficace reste encore celle qu'on n'a pas besoin de faire. La solution finale de mogluglu à l'air encore mieux si applicable dans ton cas (là ça devient trop mathématique pour moi).

[vectra]

C++ 17
https://www.oreilly.com/ideas/c++17-...wsltr_20171118

[FB74]

Des livres sur Java chez Humble Bundle:
https://www.humblebundle.com/books/java-books

[TarteAuxFleurs]

Question pour du C++ : j'ai besoin de récupérer de événements de touches dans un programme qui tourne dans un terminal. Autant sur Windows aucun problème, autant sur Linux, je n'ai aucune idée comment faire.
Les solutions proposées vont de utiliser SDL/SFML, à lire directement depuis /dev/input/event0.
Le problème, c'est que ça doit compiler avec le moins de librairies externes. Le mieux ce serait 0 librairies.
Vous avez une idée de comment faire ?

[deathdigger]

OZ Code à 44$ pour le Black Friday : http://landing.oz-code.com/BF-sale20...2bc1-205752201

Par contre, le système de licence a changé, c'est dorénavant un abonnement. Du coup, je passe mon tour.

[rOut]

Ben lis directement /dev/input/event*, y'a une API evdev exposée directement par le noyau. Mais bon tu vas te faire bien chier quand même... (Un peu de doc là : https://www.kernel.org/doc/html/v4.1...vent-interface)

[Cwningen]

Les définitions des structures et ioctls sont dans linux/input.h (et linux/input-event-codes.h pour les codes de touches mais tu n'as pas besoin de l'inclure directement). Comme dit dans le lien de rOut, lire les évènements c'est juste lire la structure input_event en boucle depuis le fichier. Il y a aussi des ioctls pour avoir plus d'infos sur le périphériques (boutons et axes présents par exemple).

Sinon, il y a la possibilité d'utiliser libevdev mais ce n'est pas indispensable, surtout si tu veux limiter les dépendances.

[TarteAuxFleurs]

Merci

[Thingazazi]

Mouais. De manière général, pour ta problématique sur le calcul du max il n'y a pas grand-chose à optimiser en fait. Lire, comparer, sur un grand tableau le processeur va se tourner les pouces et c'est le débit de la mémoire qui va entrer en compte. Pas beaucoup d'intérêt à paralléliser cette opération sur une seule machine (sauf si il faut plusieurs coeurs pour exploiter toute la bande passante mémoire, possible sur "le gros serveur de calcul" ). Sinon, vu que tu as multiplié par dix la dimension en x et par 10 en y c'est pas très étonnant que ça prenne 100 fois plus de temps.

Mais bon, l'opération la plus efficace reste encore celle qu'on n'a pas besoin de faire. Donc comme le dit mogluglu, au minimum il faudrait calculer le max en même temps que tu calcules les valeurs du tableau (si il est vraiment indispensable de les conserver). Tu t'éviteras une lecture complète du tableau, et vu le calcul un poil lourd à faire sur chaque case y ajouter un calcul de max ne devrait même pas se ressentir sur les performances de cette étape.

Et pour le coup, ces calculs de valeurs m'ont l'air suffisamment intenses arithmétiquemnt que pour bénéficier d'une parallélisation.

Mais bon, l'opération la plus efficace reste encore celle qu'on n'a pas besoin de faire. La solution finale de mogluglu à l'air encore mieux si applicable dans ton cas (là ça devient trop mathématique pour moi).

Retour sur le projet après quelques jours à avoir du faire autre chose. Merci pour tous vos retour, ça me donne des pistes pour améliorer le programme là où c'est possible.

Concernant la simultanéité du calcul du max et de ma fonction, le max est recherché sur la combinaison de plusieurs fonctions du type décrit et non pas sur une seule. Nous avons en fait 6 fonctions densité de probabilités évaluées pour des paramètres différents qui sont toutes ou partie combinées entres elle, en une fois ou en plusieurs fois (recherche de solution intermédiaires) etc. Il y a donc des cas où on pourrait tout faire d'un coup, mais j'ai besoin des tableaux pour la suite.

@Mogluglu
Merci pour la mention de scipy.optimise.minimise, je ne connaissais pas, je vais aller voir ce qu'il en est.

@Vectra
Comme tu l'avais évoqué, j'ai tracé précisément les différentes étapes de mes calculs. Il se trouve donc en effet que le argmin n'est pas la plus coûteuse en temps, le plus long se trouve être le calcul de chacune de nos pdfs. En revanche, comme on détermine seulement 6 pdfs contre bien plus de argmin, le temps cumumlé de ces derniers devient plus long. Nous sommes donc en train de voir pour changer notre approche et éliminé un maximum d'étapes intérmédiaires qui ne sont plus forcément pertinentes. Un fois que ce sera fait, je me pencherai de nouveau sur l'optimisation de tout ça à partir de toutes les infos que vous m'avez donné.

Merci les canards

[Møgluglu]

Ma suggestion : tu écris une nouvelle version du composant dans laquelle tu repart de zéro en utilisant scipy.optimize. Au pire, si ça ne marche pas tu pourras simplement reprendre ton ancien code. Mais ça n'a pas de raison de ne pas marcher.

Parce que j'ai pas vu ton code mais pour ce que tu décris m'évoque ça :

Spoiler Alert!

[Thingazazi]

Ma suggestion : tu écris une nouvelle version du composant dans laquelle tu repart de zéro en utilisant scipy.optimize. Au pire, si ça ne marche pas tu pourras simplement reprendre ton ancien code. Mais ça n'a pas de raison de ne pas marcher.

Parce que j'ai pas vu ton code mais pour ce que tu décris m'évoque ça :

Spoiler Alert!

http://leocat.free.fr/shadok/series/images/velo.jpg

C'est un peu l'idée ouais, plein de choses se sont ajoutées petit à petit pour aboutir à un truc mal branlé. En même temps c'est logique, on a voulu partir de l'existant pour changer le coeur de l'algo mais en conservant une démarche proche de ce qui se faisait avant. Sauf que ça n'est pas adapté du tout.
Je démarre un code parallèle pour repartir sur de bonnes bases.

[Møgluglu]

OK, on est d'accord.
Ce que je veux dire surtout, c'est qu'il faut faire gaffe à pas réinventer la roue carrée. Tu as l'avantage de coder en Python et d'avoir accès à des bibliothèques à la fois très puissantes et simples d'emploi. Dans scipy, même l'algo bruteforce que tu utilises est déjà codé. Voici une autre doc avec plein de dessins pour expliquer les algos : http://www.scipy-lectures.org/advanc...ion/index.html

De ce que tu expliques de ton problème et tes contraintes en résolution, ça n'a pas l'air de nécessiter spécialement de calculs ou de mémoire, pas besoin de code parallèle si tu utilises le bon algo. Quelques centaines de milliers de fonctions en 2 ou 3 dimensions à optimiser avec une précision d'une douzaine de bits, c'est du gâteau. Quand tu seras en dimension 1000, on pourra commencer à discuter de parallélisation.

[vectra]

Y'a des postes en GPU/Télécom dispo en Belgique.
C'est une SSII qui me démarche, mais y'a p'têt moyen pour des coins du coin de tenter le coup en direct (moi je ne peux pas).

[Cwningen]

J'ai un problème de C++, je voudrais avoir un type qui contient un variant dont il est lui-même une alternative. Je peux utiliser un pointeur pour régler le problème de taille, mais j'aimerais avoir un alias pour le type de variant comme je l'utilise à plusieurs endroits mais je ne peux pas le déclarer en avance.

struct mon_variant; // problème: struct déclare un type, pas un alias

struct Truc
{
    std::unique_ptr<mon_variant> machin;
};

using mon_variant = std::variant<..., Truc , ...>;

Je suis obligé d'utilisé le (long) nom complet du variant ou quelqu'un a une astuce ?

[Møgluglu]

Dans la définition de ta classe Truc, ça me semble difficile d'éviter la référence explicite à Truc d'une façon ou d'une autre vu que la définition est récursive. Mais une fois que le type est construit, tu peux utiliser un typedef.

[BentheXIII]

Réinventer la programmation?

[William Vaurien]

L'article est assez indigeste et finalement n'apporte rien de bien nouveau. Les commentaires sont plus concis et plus intéressants aussi
Faire générer du code par la machine avec des diagrammes... comme avec l'UML ? Ou avec les designers d'IHM, genre VB...
Au début des années 2000 un de mes profs ne jurait que par l'UML qui devait selon lui remplacer les développeurs...

Dans certains cas c'est peut être adapté, mais j'ai pu voir de sacrés horreurs avec des systèmes EAI.
Avec ce truc là plus précisément:


J'ai du reprendre un process de système d'envoi de fax développé avec ce truc par un 'informaticien sur le tas' qui avait tiré des flèches dans tous les sens.
Le code spaghetti c'est pourri aussi bien en texte qu'en diagramme. Par contre démêler un diagramme c'est finalement bien plus pénible: le 'code' est multi-dimensionnel; ce qui est visuel et ce qui est caché.

Le non informaticien à l'impression que c'est super simple et qu'il comprend le processus, mais en fait derrière c'est plein de merde planquée, sous chaque flèche et sous chaque étape. Bien évidemment toutes ces merdes sont dans un langage propriétaire, impossible à refactoriser et très dur à maintenir. J'ai eu également des expériences similaire avec du BPMN.

Manipuler des graphes plutôt que du texte à parfois du sens (EAI, BPMN, ...), mais le code textuelle à quand pas mal d'avantages. A condition de pas vouloir mettre la logique dans le diagramme...

Ou alors, autre piste de l'article, utiliser des méthodes formelles que seuls les mathématiciens comprennent et peuvent utiliser ?
C'est pas vraiment viable comme solution pour des entreprises hors NASA et autre AIRBUS...

Il manque clairement quelque chose pour aider à gérer des énormes base de codes, peut être une sorte d'IA, qui pourrait faire ce travail de validation formelle en fond pour s'assurer de la cohérence à plus haut niveau
et gérer l'implémentation à partir de spécifications. Mais là il faudrait aussi des IA pour reprendre en main ceux qui écrivent ces dites specs, quand c'est le cas

[rOut]

Pareil, on nous raconte aussi que c'est pour que des les gens qui connaissent les problématiques métiers puisse implémenter eux-même les bons algorithmes et vérifier qu'ils sont corrects... On sait très bien en vrai qui va se taper le sale boulot d'implémentation, et qui sera bien plus heureux de pouvoir faire ça en mode texte, qui est finalement une représentation bien plus expressive et même plus formalisée que la version graphique.

C'est un peu comme si on voulait remplacer le langage mathématique par des preuves à base de petits croquis parce que ce serait plus abordable par le commun des mortels, et soit disant que ça éviterait des erreurs sur des théorèmes fondamentaux.

[Møgluglu]

C'est vrai que l'article part un peu dans tous les sens. Quitte à s'intéresser aux travaux de Gérard Berry, autant aller directement directement à la source, par exemple : http://www.college-de-france.fr/site...3-04-16h00.htm

C'est un excellent orateur et pédagogue, il n'est pas arrivé au Collège de France par hasard... D'ailleurs ses cours reprennent à partir de janvier prochain, si vous avez l'occasion d'y assister, foncez, c'est vraiment intéressant.

[William Vaurien]

En effet la présentation du cours est intéressante.

Génie logiciel et vérification formelle partagent deux prérequis essentiels : d’abord, la qualité des spécifications initiales, qui doivent être précises, non-contradictoires, et complètes mais sans excès de précision inutile ; ensuite, la qualité des langages de programmation, dont la sémantique doit être précise tout en restant intuitive. Beaucoup de projets industriels échouent encore à cause de leur non-respect de ces contraintes.

Voilà tout est dit en 2 lignes

Bon après perso je me méfie des langages qui tirent trop vers les maths, parce que je ne suis pas matheux. Ils manipulent des concepts qui sont parfois bien obscures pour moi, et je ne sais pas si c'est totalement une bonne chose: les langages plus 'terre à terre' ont l'avantage de rester à peu près lisible... Je ne sais pas ce qu'il entend par la sémantique qui doit être précise tout en restant intuitive...

[Dross]

Pareil, on nous raconte aussi que c'est pour que des les gens qui connaissent les problématiques métiers puisse implémenter eux-même les bons algorithmes et vérifier qu'ils sont corrects... On sait très bien en vrai qui va se taper le sale boulot d'implémentation, et qui sera bien plus heureux de pouvoir faire ça en mode texte, qui est finalement une représentation bien plus expressive et même plus formalisée que la version graphique.

C'est un problème de modélisation surtout, pas d'outil. Et c'est pas comme si les gourou/programmeurs ne s'y penchaient pas. On parle parfois du Domain-Driven Design pour ce besoin très précis : intégrer les experts du domaine DANS la boucle de modélisation, justement pour intégrer les problématiques métier.

Dans l'Event Sourcing aussi j'ai vu des aspects du genre, par exemple lors de la réhydratation des entités (rejouer les évènements pour retrouver l'état actuel), on a tendance à vouloir utiliser des "règles métier" qui collent au plus proche du domaine. Avec des notions qui proviennent du DDD.

Bref soit j'ai rien compris à l'article, soit ces gens ne suivent pas ce qui se passe aujourd'hui dans les entreprises et se limitent aux cas choquants/erreurs (Toyota qui n'a pas utilisé de langage fonctionnel avec en plus des états partagés, c'est le cas d'école de ce qui ne faut pas faire en embarqué), donc totalement à coté de la plaque.

[Møgluglu]

Bon après perso je me méfie des langages qui tirent trop vers les maths, parce que je ne suis pas matheux. Ils manipulent des concepts qui sont parfois bien obscures pour moi, et je ne sais pas si c'est totalement une bonne chose: les langages plus 'terre à terre' ont l'avantage de rester à peu près lisible... Je ne sais pas ce qu'il entend par la sémantique qui doit être précise tout en restant intuitive...

Le fait qu'un langage soit défini formellement ("tire vers les maths") ne veut pas dire qu'il est forcément haut niveau. On utilise des méthodes formelles pour prouver des propriétés sur du code assembleur, ou encore plus souvent sur des circuits.
Et ça remonte peu à peu vers le software... On commence enfin à avoir des spécifications de jeux d'instructions sont dans un format lisible en machine, par exemple ARMv8 en ASL, ou des modèles de consistance mémoire décrits précisément d'un point de vue mathématique, par exemple chez Nvidia. Pourtant là on manipule des concepts très terre-à-terre comme des bits dans les registres et des octets en mémoire.

Et inversement, tu as plein de langages "modernes" très haut niveau qui sont mal voire pas du tout spécifiés, je ne vais pas donner de noms mais ils se reconnaîtront.

Quand tu as 1h30 de libre tu peux regarder le replay, promis ça ne fait pas mal à la tête.

[ducon]

Si si, je veux des noms.

[Sahnvour]

Un indice chez vous dans le nom du topic.

[GrandFather]

Un indice chez vous dans le nom du topic.

Ma première citation dans un titre de topic, j'en suis encore tout ému.

Bon, j'ai continué mon bout de chemin avec Python, et je dois dire que le langage en lui-même me laisse encore un peu dubitatif. Avec l'absence de switch/case, son opérateur ternaire contre-intuitif et la vilaine pièce rapportée qu'est son implémentation des classes abstraites, il m'a réservé quelques autres surprises pas toutes agréables. C'est partiellement compensé par quelques sucreries syntaxiques sympathiques, mais dans l'ensemble je reste sur le constat d'un langage un peu bricolé, et Ruby reste à mes yeux infiniment plus élégant.

Il y a par contre un point sur lequel Python est très impressionnant, c'est sur l'écosystème. Le projet sur lequel je bosse ratisse assez large sur le plan technologique, et j'utilise donc, en plus des librairies natives pléthoriques, pas mal de librairies tierces : lxml pour le parsing XML/validation XSD, pymysql pour MySQL, PyQT pour l'IHM, ReportLabs pour la génération de PDF, pycryptodome pour de la signature PKCS#1_v1_5, pywin32 pour l'API Win32, PyInstaller pour le déploiement... Toutes sont riches fonctionnellement, bien supportées et correctement documentées. De ce point de vue, c'est une réussite.

[William Vaurien]

Est-ce que les IA vont remplacer les codeurs ???
Par-ce que "coder, c'est chiant à mourir" ?

Persos je pense que les IA qui codent je crois bien que oui, ça va bien finnir par arriver. Plus rapidement qu'on l'imagine. Peut-être pas tout, mais dans les grandes lignes, oui.