Bonjour Aimé,
On est bien d'accord qu'il s'agit surtout d'un problème de science
humaine: le management du code et de son développeur.
Si en 1980, Fortran ne souffrait aucune comparaison, il est de plus en
plus obsolete aujourd'hui: même si des nouvelles normes du langage
existe, plus personne ne se presse pour les implementer dans un
compilateur.
https://fortranwiki.org/fortran/show/Fortran+2008+status
Cela étant dit, fixer une signature à une fonction et figer l'API est
une solution qui marche bien. Peu de gens se plaignent de l'interface
de BLAS (qui est en Fortran)! C'est ce que je conseille à Fred.
Pour ce qui est de ta volonté de documenter du code, on utilise avec un
certain succès nbsphinx pour convertir des notebook jupyter en
documentation (générée par sphinx). Juste un exemple:
https://www.silx.org/doc/pyFAI/dev/usage/cookbook/integration_with_python.html
Ce n'est pas limité à Python puisque JuPyteR correspond à la
concatenation de Julia Python et R ... et beaucoup d'autres languages
de programmation aujourd'hui.
A++
Jérôme
On Mon, 31 Jan 2022 15:30:17 +0100
Aimé Vareille <aime.vareille@???> wrote:
> Bonjour,
>
> En LL pour les maths j'ai aussi vu passer https://www.scilab.org/ et
> https://www.sagemath.org/ sans compter https://www.r-project.org/ .
>
> https://wiki.octave.org/GNU_Octave_Wiki est-il plus facile pour faire
> ses gammes ?
>
> Question migrations je vois qu'il y a de plus en plus de possibilités
> qui rendent les réalisations de plus en plus difficile à maintenir et
> transmettre ...
>
> Le bon exemple qui correspond à ce que je voudrais enrichir est
> https://www.f-legrand.fr/scidoc/index.html
>
> Le 31/01/2022 à 10:12, Frédéric a écrit :
> > Le lundi 31 janvier 2022, Jérôme a écrit :
> >
> >> En tant que voisins, on a des déboires du même genre ...
> >> Notre approche est un peu differente:
> >> * Les gens qui veulent faire du matlab, on ne les en empêche pas, mais
> >> ils se démerdent
> >> * Les gens qui veulent partir sur du "gratuit" (car le libre, ils s'en
> >> foutent, c'est le prix de la license matlab qui leur pose problème)
> >> - on traduit les routines numerique en python, numpy et numba/cython
> >> au besoin, travail bien adapté aux stagiaires avec des tests de non
> >> régression
> >> - on refait l'interface graphique au besoin avec les technos à la
> >> mode du moment. C'était pyQt, maintenant c'est des interface web.
> >> - Une fois la transition faite, le scientifique n'a plus le droit de
> >> toucher à son code Matlab.
> >> * Octave se trouve un peu hors du chemin car pas assez compatible avec
> >> Matlab d'un coté et trop différent du reste pour être compatible.
> >> Quelques scientifiques ont franchi le pas mais c'est presque pire
> >> que Matlab car il y a moins de documentation donc plus compliqué de
> >> faire du portage.
> > Alors l'approche initiale était aussi de passer en Python, mais c'est pas
> > trivial. Même avec Numpy, quand je vois la liste des différences à gérer,
> > c'est plus qu'une migration :o/ J'ai bien tenté les moulinettes
> > automatiques, mais y'a absolument rien qui passe.
> >
> > Et le problème de repartir de zéro, c'est qu'il n'y aura personne pour
> > m'expliquer la partie scientifique, et que je n'ai aucune chance de la
> > comprendre moi-même, vu la tronche du script Matlab :o/ Et si c'est pour
> > transformer ligne à ligne, sans comprendre, ça va rester un tas de boue
> > impossible à maintenir ; ça n'a vraiment pas d'intérêt.
> >
> > Du coup, pour le moment, Octave me semble la solution la moins pire...
> > Surtout si ça se résume à 2 fonctions graphiques à modifier.
> >
> > Mais, comme tu dis, les docs de ces softs, c'est vraiment pas glorieux !
> > Même Matlab, franchement, pfff ! Ça ne m'étonne pas que les scripts soient
> > moches, à la sortie ;o)
> >
> --
> Aimé
>
>
