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)
--
Frédéric
