Simplification de programme

[invite936c567e]

N'est-ce pas tres exactement ce que Tensorflow fait?

En general, je comprendrais ton point s'il s'agissait de C ou d'assembleur. Mais ce qui concerne python (le sujet du fil) perso oui je m'attend d'un langage de haut niveau qu'il permette de s'abstenir de specifier exactement toutes les etapes une par une. N'est-ce pas la definition meme d'un langage de haut niveau?

Même en langage de haut niveau, on s'attend à ce que les opérations réalisées correspondent à ce qui a été écrit dans le code, ne serait-ce que parce que cette façon de faire garantit, du point de vue du développeur, le résultat que ce dernier souhaite obtenir.

Dans le meilleur des mondes, on ne devrait pas s'inquiéter du fait que le déroulement du programme puisse être remanié afin d'aboutir au même résultat en utilisant des moyens différents mais meilleurs selon certains critères (code exécutable plus compact, plus rapide, utilisant mieux les ressources, etc.).

Mais dans la vrai vie, il existe des limitations d'ordre matériel qui imposent parfois de préciser les moyens en question et de s'y tenir, faut de quoi le résultat attendu risque de ne pas être obtenu dans certaines situations, car le compilateur n'est pas capable de détecter ces cas particuliers et de leur apporter une réponse spécifique adaptée.

Le plantage du code de la fonction Python cumsum après seulement quelques centaines d'itérations en est un exemple simple, très certainement inattendu pour les néophytes. Mais il en existe bien d'autres, en Python et dans d'autres langages de haut niveau. Par exemple, contre toute attente, on trouve que le calcul math.floor(math.log(1000,10)) (qui doit donner le nombre de zéros du nombre 1000) retourne 2 au lieu de 3.
-----

[jiherve]

Re
En asm l'inlining s'appelle macro!
Mais cela consomme de la mémoire, morte cette fois ci, toujours pas de miracle!

Mais il serait prudent que les gens écrivant du code amené à être certifié un jour (si les règles restent les mêmes)ouvrent les yeux car la chute sera douloureuse et couteuse.
Bon stricto sensu c'est HS.
JR

[invite6c250b59]

Même en langage de haut niveau, on s'attend à ce que les opérations réalisées correspondent à ce qui a été écrit dans le code, ne serait-ce que parce que cette façon de faire garantit, du point de vue du développeur, le résultat que ce dernier souhaite obtenir.

Prenons un exemple. Je fais un graph X sous tensorflow. Je le donne à manger à l'ordinateur Y et à l'ordinateur Z. L'ordinateur Y le mange et recrache le résultat. L'ordinateur Z le mange et recrache les résultats. Je ne passe pas deux plombes a specifier que, attention sur l'ordinateur Y telle boucle ben oui elle finit en moins que tant, alors qu'ici tel calcul devrait être fait en GPU si possible, sinon en essayant de le diviser en deux pour Z qui a une plus petite carte.... En fait je m'en fout, et si l'ordinateur a calculé les paramètres optimaux ou juste pas trop moche, c'est très bien et il peut même se garder le détails des paramètres pour lui si ça lui chante. Allez tiens, cela fait plaisir, sisi garde le, c'est un cadeau!

Comment est-ce que cette pratique (qui je crois correspond à une population relativement petite mais surreprésenté en sciences et en geakitude) s'accorderait de l'opinion "je m'attend à ce que les opérations réalisées correspondent à ce que j'ai écrit dans le code". Dans le code au sens de code de haut niveau, oui. Dans le code au sens de comment on gère une réccursion dans un ordinateur, non.

Le plantage du code de la fonction Python cumsum après seulement quelques centaines d'itérations en est un exemple simple, très certainement inattendu pour les néophytes. Mais il en existe bien d'autres, en Python et dans d'autres langages de haut niveau. Par exemple, contre toute attente, on trouve que le calcul math.floor(math.log(1000,10)) (qui doit donner le nombre de zéros du nombre 1000) retourne 2 au lieu de 3.

O mais moi tu m'as convaincu, en fait. Je ne me serais pas douté que la récurrence planterait aussi vite, i.e. c'est une bonne raison pour que *je* décide d'éviter de les utiliser. En fait j'avais déjà exclu les formes compliquées. Les formes simples me semblaient toujours aussi séduisantes, mais j'ai constaté que si j'essai de faire des programmes trop complexes (avec deux trois variables qui se passent entre deux trois boucles de récursion pas tapé! oui je sais c'était pas une bonne idée mais c'est mon point!). Parfois oui cela marche, et éventuellement de façon très belle, mais dès que je laisse passer une semaine sans avoir le nez dessus, paf je reviens et je ne comprend plus rien à mon propre code.

Cela dépend. Pour la répartition CPU/GPU, c'est très particulier et il y a des langages et librairies spécialisées. Mais en dehors de l'IA, on a plutôt tendance à écrire directement pour les GPU.

Par contre, les compilos font des trucs étonnant notamment dans l'ordonnancement des instructions pour profiter à fond de l'architecture des machines : pipe-line, hyper-threading...
C'est une techno qui a été développée aux débuts des processeurs RISC et cela a abouti à une génération de compilateurs qui sont plus efficaces que des humains.

Super intéressant merci

DO178 DALXX

Je ne connaissais pas merci. Mais je n'ai pas vu l'interdiction de récursion. Je crois avoir compris qu'il faut soit prouver qu'elle finit en temps démontrable soit démontrer statistiquement qu'elle ne finit pas. Est-ce à cela que tu faisais référence?

[invite936c567e]

Prenons un exemple. Je fais un graph X sous tensorflow. Je le donne à manger à l'ordinateur Y et à l'ordinateur Z. L'ordinateur Y le mange et recrache le résultat. L'ordinateur Z le mange et recrache les résultats. Je ne passe pas deux plombes a specifier que, attention sur l'ordinateur Y telle boucle ben oui elle finit en moins que tant, alors qu'ici tel calcul devrait être fait en GPU si possible, sinon en essayant de le diviser en deux pour Z qui a une plus petite carte.... En fait je m'en fout, et si l'ordinateur a calculé les paramètres optimaux ou juste pas trop moche, c'est très bien et il peut même se garder le détails des paramètres pour lui si ça lui chante. Allez tiens, cela fait plaisir, sisi garde le, c'est un cadeau!

Comment est-ce que cette pratique (qui je crois correspond à une population relativement petite mais surreprésenté en sciences et en geakitude) s'accorderait de l'opinion "je m'attend à ce que les opérations réalisées correspondent à ce que j'ai écrit dans le code". Dans le code au sens de code de haut niveau, oui. Dans le code au sens de comment on gère une réccursion dans un ordinateur, non.

Ce qu'on veut, c'est obtenir de bons résultats du point de vue de l'utilisateur (ce qui peut différer de résultats rigoureusement exacts).

Dans la mesure où certaines façon de faire qui paraissent bonnes en théorie produisent parfois, dans des cas très exceptionnels, des résultats inacceptables (c'est-à-dire des résultats carrément faux ou pas de résultat du tout), il est important de pouvoir s'assurer, au moins dans ces cas-là, que l'outil qui génère le code exécutable ne remplace pas la « bonne » façon de faire décrite au moyen du langage de haut niveau par une autre qui serait mauvaise sous prétexte qu'elle offre de meilleures performances.

Et quand le langage ne permet pas de décrire assez précisément la « bonne » façon de faire, on est obligé d'ajouter des pansements logiciels pour contourner les problèmes (lorsqu'ils sont clairement identifiés et qu'on a trouvé une méthode pour y remédier), ou bien on se heurte à une impossibilité de garantir la fiabilité des résultats .

On pourrait croire que, la technique évoluant, on finit par faire disparaître les causes de ces problèmes. Mais le fait est que les évolutions, même correctives, tendent à en faire apparaître de nouvelles.


Donc il ressort de mon expérience qu'on ne peut pas toujours « se foutre » de la façon dont l'outil de développement et la machine qui exécute le programme produit vont effectivement se comporter, sauf à s'exposer à des déconvenues, systématiques ou inopinées, qui peuvent parfois coûter cher en argent, en temps, en réputation ... voire en vies humaines.

[invite6c250b59]

qui peuvent parfois coûter cher en argent, en temps, en réputation ... voire en vies humaines.

Oui c'est vrai qu'avec l'IA au contrôle de la voiture cela devient une préoccupation même au-delà des applications sécuritaires "traditionnelles". Je ne vois pas comment on pourrait les corriger par contre. Patcher des exceptions en interdisant une règle de programmation, dans le fond c'est un peu ce que fait python quand il interdit d'écrire autrement que dans un certain style. Patcher les 'exceptions' qui font planter un réseau sur des données arbitraires pas si faciles à définir à l'avance, c'est autre chose.

[jiherve]

re,

Je ne connaissais pas merci. Mais je n'ai pas vu l'interdiction de récursion. Je crois avoir compris qu'il faut soit prouver qu'elle finit en temps démontrable soit démontrer statistiquement qu'elle ne finit pas.

On voit en effet que tu ne connais pas!
il faut aller lire le papier complet.

Je fais un graph X sous tensorflow. Je le donne à manger à l'ordinateur Y et à l'ordinateur Z. L'ordinateur Y le mange et recrache le résultat. L'ordinateur Z le mange et recrache les résultats. Je ne passe pas deux plombes a specifier que, attention sur l'ordinateur Y telle boucle ben oui elle finit en moins que tant, alors qu'ici tel calcul devrait être fait en GPU si possible, sinon en essayant de le diviser en deux pour Z qui a une plus petite carte.... En fait je m'en fout, et si l'ordinateur a calculé les paramètres optimaux ou juste pas trop moche, c'est très bien et il peut même se garder le détails des paramètres pour lui si ça lui chante. Allez tiens, cela fait plaisir, sisi garde le, c'est un cadeau!

Et si le process en question c'est celui d'assistance au pilotage d'un aéronef crois tu que ton raisonnement tient toujours, à merde j'ai codé comme un cochon et au lieu d'avoir la réponse en 16 ms il faut 1 min oups tout le monde il est mort !
Donc souhaites ne jamais avoir à connaitre tu dormiras mieux !
JR

[invite6c250b59]

Est-ce à cela que tu faisais référence?

il faut aller lire le papier complet.

S'il faut lire le papier complet pour savoir ce à quoi tu fais référence, c'est un peu longuet. Est-ce que tu ne pourrais pas indiquer directement le chapitre spécifique de tes pensées?

Et si le process en question c'est celui d'assistance au pilotage d'un aéronef

Alors ce ne sont mes oignons de décider ni même d'être informé de comment ça sera programmé. Pas que je me fiche que quelqu'un s'en préoccupe, mais le cas échéant on peut supposer qu'il ne viendra pas chercher son entrainement sur le forum. Il parait même qu'il y a des écoles pour cela, non?

[invite936c567e]

Il parait même qu'il y a des écoles pour cela, non?

Tout le problème est qu'on y apprend par exemple à faire des fonctions récursives, avec potentiellement les conséquences catastrophiques qu'on a vues plus haut (enfin, savoir ce qu'est une fonction récursive c'est bien, mais savoir également qu'a priori il ne faut pas les utiliser c'est beaucoup mieux).

Comme dans la plupart des écoles, on y enseigne les bases, et même des connaissances avancées, mais généralement en décalage plus ou moins marqué avec les pratiques adaptées au monde réel, que les domaines enseignés et les quelques travaux pratiques ne suffisent bien évidemment pas à appréhender complètement.

C'est la raison pour laquelle on ne confie pas de projets importants aux débutants dans les entreprises. Non pas qu'ils ne soient pas capables de les mener à bien sur le principe, mais leur manque d'expérience les rend insensibles à toute une série de problèmes et ignorants de certaines solutions originales adaptées, et cela constitue un risque réel.

Cela dit, on confie aussi parfois des projets importants à des gens qui, malgré leur ancienneté dans le métier, n'ont pas tiré les enseignements utiles de leurs expériences passées, ou ont passé leur temps à les éviter. Et de ceux-là, j'en ai connu qui ont planté de gros projets de façon monumentale. Dans les projets en rapport avec la sécurité des personnes, on atténue en principe ce risque en répartissant les développements entre plusieurs responsables distincts et en éprouvant les résultats obtenus à tous les niveaux, de sorte que les manquements dans certaines parties aient des chances d'être découvertes au contact des autres parties. Mais au final, il reste toujours un petit risque.

Toutefois, il m'est apparu que durant ces dernières décennies, le niveau de sûreté acceptable pour les biens et les personnes n'avait cessé de baisser, et qu'on s'autorise aujourd'hui à confier les matériels, les données et la vie d'êtres humains à des systèmes qu'on n'aurait jamais osé utiliser auparavant. Ceux qui promeuvent ces solutions évoquent souvent la sécurité accrue des systèmes modernes, alors qu'au fond ils se contentent de méconnaître des dangers qui sont inhérents aux types de solutions retenues, voire qui sont apparus avec l'évolution technologique. Ajouter à cela qu'on a souvent affaire à des startups qui pratiquent le jeunisme, c'est-à-dire des structures qui manquent cruellement d'expérience, de recul et de contradicteurs, et on a tous les ingrédients de catastrophes technologiques annoncées (et pour certaines, déjà survenues).

[invite01703c44]

Bonjour,

Nous sommes très loin du sujet initial me semble t-il.

J'aime bien la récursivité. C'est élégant, concis et permet un haut niveau d'abstraction. Cependant je ne l'utilise qu'avec des pincettes. Un haut niveau d'abstraction qui nécessite des essais pour savoir précisément quelles sont ses limites, qui impose de connaître la logique du compilateur voir de regarder l'assembleur généré n'est pas vraiment d'aussi haut niveau que cela (mais c'est souvent vrai de ces abstractions qui nous laissent espérer - et croire lorsqu'on sort des études - à tort l'indépendance vis à vis des couches basses).

Ceci étant je les utilise dans les algorithme en O(log(n), comme les algorithmes dichotomiques par exemple, essentiellement parce que la profondeur est limitée. L'intérêt des appels récursifs linéaires de types f(x) = g(f(n-1) me semble nul : ils présentent des risques alors qu'ils sont faciles à "dérécursiver" en boucles qui restent aisées à lire. En revanche, dans les appels récursifs arborescents les risques sont liés à la profondeur de l'arbre qui peut être faible relativement aux nombres de cas traités.

Les propos échangés m'incitent à deux commentaires. 1/ Il n'y a pas de recette parfaite mais une collection d'outils avec des qualité et défauts que les besoins et compétences vont exacerber. 1/ Nous ne devrions pas oublier que les gens intelligents se mettent d'accords sur leurs désaccords.

Salutations.