Re: Domaine de définition

Le 16/11/2024 à 15:52, efji a écrit :

Le 16/11/2024 à 13:17, Python a écrit :
 

  Vous êtes pathétiquement ridicule M. "efji". Le sujet de ce fil n'est

 Mis à part cette introduction cavalière, merci pour cette réponse construite et constructive. Je vais me permettre d'en couper quelques morceaux pour que tout cela reste plus lisible.

Ce n'était pas une introduction mais une réaction à un procès d'intention doublé d'une injonction sans propos.

Je me suis contenté de pointer qu'il est un peu désinvolte de parler d'un divorce absolu entre géométrie analytique et géométrie analytique alors que s'il est un bien un hiatus qui est sujet de beaucoup d'attention. Je vous renvoie au papier de Jean-Pierre Serre que vous connaissez certainement (http://www.numdam.org/article/ AIF_1956__6__1_0.pdf)

 Si on passe sur le petit lapsus (mais les lapsus sont souvent révélateurs),

D'autant plus révélateur que je suis de formation plus algébriste qu'analyse !

vous illustrez en fait sans le vouloir ce que j'essayais de dire, et vous donnez comme référence probablement un des pires Ayatollah qui ont créé la césure que j'évoquais. L'article de Serre n'a pas grand chose à voir avec le sujet : je vous parlais d'analyse (analyse des EDP par exemple) et de probabilités, pas de géométrie analytique!

Vous opposiez algèbre et analyse laconiquement sans plus de détails.
JP Serre un "ayatollah" ! Rien que ça !

C'est une césure historique qui se résorbe petit à petit, et en particulier les membres actuels du groupe Bourbaki indiqués sur la page Wikipedia (bon, normalement c'est secret...), que je connais pratiquement tous personnellement, ne sont plus du tout dans cet esprit. Il y en a même un, dont la spécialité est très pure, qui me donne toujours l'impression qu'il connait plus de choses que moi dans les domaines appliqués. Une sorte de fantôme du mathématicien universel du XIXe siècle.

Et ?

Surtout, c'est votre ricanement sur la notation infixe qui serait un délire d'informaticiens tordus qui m'a fait bondir : Michel Talon vous a bien recadré sur ce point, je pourrai ajouter quelques pierres, mais à quoi bon ?

 Mon rapport à l'informatique est purement utilitariste, et donc je raisonne par le petit bout de la lorgnette. Mais j'ai quand même une petite expérience de programmation : il y a 20 ans j'avais compté mes lignes de codes pour faire un dossier : 350000 :)
Donc de mon point de vue d'utilisateur de langages informatiques pour faire des calculs numériques, si possible le plus rapidement possible, j'ai beaucoup de mal à voir à quoi peut servir la notation polonaise inverse, et ce qu'elle est capable de faire que les langages plus lisibles ne sauraient pas faire. Mais je ne demande qu'à apprendre.

Votre expression de "délire d'informaticien" ne semblait guère montrer un désir d'apprendre.
Pour compléter les remarques de Michel je peux illustrer l'intérêt de cette notation sur deux points :
- L'homoiconicité de LISP : https://en.wikipedia.org/wiki/Homoiconicity ; un programme LISP est aussi une donnée en LISP. Ce qui permet facilement d'écrire un programme qui génère un autre programme. J'ai travaillé au portage sur GNU/Linux d'un logiciel de ce type au CNES à Toulouse. Un programme LISP lit une description des tests et résultats attendus, y compris les contraintes temps réels et génère un programme en LISP qui réalise les tests. Celui-ci est ensuite compilé et injecté dans les calculateurs qui pilotent les bancs de tests.
- Le calcul formel. Derrière tous les logiciels du type Maxima, Maple, Mathematica, etc. Vous avez une représentation en arbre des formules algébrique. Par exemple pour x^2 + 2*x + 1 c'est :
       +
     / | \
    /  |  \
   /   |   \
  /    |    \
 ^     *     1
/\    / \
x 2  2   x
Vous imaginez, je pense, qu'implémenter, par exemple, la dérivée formelle est très simple à partir d'un telle représentation. Et bien c'est cet arbre LISP représente directement avec la notation infixe :
(+ (^ x 2) (* 2 x) 1)

Par exemple j'ai longtemps été persuadé que la récursivité était un truc d'informaticiens qui avaient envie de se faire plaisir. Jusqu'au jour où j'ai donné des cours d'algorithmique et j'ai découvert des algos incroyables qui tiennent en 30 lignes de python, alors que j'aurais été bien en peine de les écrire de façon séquentielle.

Vous avez donné des cours d'algorithmique sans avoir rien su de la récursivité ? Du lambda-calcul ? de récursivité terminale ? J'en reste pantois.

Quant à ma remarque sur python 2 vs python 3, je l'assume à 100%. Je ne vois pas d'autre mot que "tordu" pour qualifier le type qui a décidé de changer la signification de "/" d'une version à l'autre. C'est assez monstrueux quand on y pense. Imaginez le pauvre gars qui avait 350000 lignes de python 2...

Vous êtes à côté de la plaque. De fait c'est le choix du comportement de / et // dans Python 2 qui était problématique. Le fait que "/" ne renvoyait de float que si l'un des opérandes était un float conduisait à énormément de bugs vicieux à détecter. Et clairement pose un problème de polymorphisme quand on souhaite écrire une fonction qui traite int et float de façon homogène.
Pendant des années, d'ailleurs, on pouvait avoir le comportement de Python 3 en Python 3 en invoquant "from __future__ import division", ce qui était fait dans la quasi totalité des projets en Python 2 que j'ai vu passer à l'époque.
Le comportement de la division n'a pas vraiment été un souci lors de la conversion de milliers de paquetage de Python 2 à Python 3, il y avait bien d'autres constructions à revoir. Des outils comme 2to3 ont aidé à cette transition.

Du haut de votre position académique (je n'ai rien du tout contre l'Université, tout au contraire, hein !) vous semblez considérer qu'hors de l'Université, personne n'a de légitimité pour parler de science et à la moindre critique vous montez sur vos grands chevaux.

 Mais non, il y a des gens qui font des recherches très intéressantes au sein de certaines entreprises aussi. Le critère n'est pas l'employeur mais les publications scientifiques (sans que ce soit nécessairement une question de nombre).

Je ne répond pas à ce qui se passe dans votre tête et que vous n'exprimiez pas.

Bref : je pense que votre remarque sur l'opposition algèbre/analyse est inepte s'agissant du champ de recherche actuel en géométrie et je SAIS que votre remarque sur LISP est inepte.

 Et, voilà! Flagrant délit de récidive qui montre que vous ne voyez probablement même pas de quoi je parle :) Qui vous parle de "géométrie" ? Ai-je une fois employé ce mot ?
 Je parle d'analyse et de probabilité. Ca va de l'analyse fonctionnelle, la théorie de la mesure, pour la partie fondamentale, jusqu'aux applications les plus concrètes en calcul scientifique et en statistiques. Une paille. En France, le Conseil National des Universités (CNU) a 2 sections la 25 et la 26, représentant environ chacune 50% des mathématiciens de France (même s'il y en a quelques-uns en section 27: informatique). La section 25 s'intitule "mathématiques" et la section 26 "Mathématiques appliquées et applications des mathématiques". Je pense que ça dit à peu près tout sur la césure dont je parle et dont vous semblez tout ignorer :)

L'argumentation à coup de smileys, de raccourcis et de hors-sujets (on appelle ça une "robbynette" dans la profession) est aussi pénible que pathétique.
La communauté mathématique ne se réduit pas à la France, et la communauté mathématique française ne se réduit pas au CNRS. Et je ne vois pas vraiment le rapport entre oppositions "analyse/algèbre" et "maths/maths appliquée".
Si cette césure supposée vous traumatise autant, pourquoi ne résolvez-vous pas le problème en révolutionnant le domaine au lieu de poster des souriards sur Usenet ?

Envoyez-moi plutôt des complément à mon cours que je sais fort imparfait :
 https://framagit.org/jpython/math

 Il est très intéressant, mais vous ignorez de nouveau une grande partie des mathématiques. C'est indiqué et donc assumé, et à moitié pardonné. On ne peut pas tout aborder.

En cinq jours face à des étudiant de 4ème année d'école d'ingénieurs en informatique évidemment non.

J'y ai appris une chose : en python les entiers sont non limités. Ca nous ramène à un fil récent sur les racines carrées. Et ça nous ramène à ma remarque sur la division :)
  >>> 2**500
 3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376
(fou!)

Pourquoi fou ? Les systèmes formels que j'utilisais à l'Université de Brest en 1988 (mumath et derive) en faisait déjà autant !

 >>> 2**500/2**490
1024.0
  >>> 2**500//2**490
1024

et alors ? / renvoie un float et // une "floor division" (float ou int). C'est un problème pour vous ?