C++ et calcul mathématique (python ? Scilab ?)

Bonjour,

La question a du être traitée des dizaines de fois mais...je me fais un noeud au cerveau depuis jeudi.


Situation initiale :
- soft en C++
- données sous forme de double* et de tempscustom* (i.e. vecteurs values/times) de même dimension stockées dans une classe A, instanciée autant de fois qu'il y a de "courbe" à tracer. Je ne peux pas changer cette classe.
- Le soft est sous C::B et tourne via wxWidgets

Problématique :
- Faire des opérations complexes sur ces courbes (matlab-like)

Solution envisagée :
- Envoyer les données à Scilab (via Call_SciLab) pour calculs et rappatrier les résultats
- Idem Python (via ???)

Pour SciLab, j'ai vu Call_SciLab qui pourrait répondre à la problématique. Je n'ai pas tester mais ça semble faisable et coté mathématique, c'est un must.
Par contre, niveau ouverture, Python est bien. Je n'ai pas de recul quant à la façon de faire par contre. Des infos que j'ai pu lire, Boost encapsule un objet C++ pour qu'il soit traité dans un soft en Python. De mon coté, je cherche plutot l'inverse : embarquer python dans mon soft C++. L'idéal serait d'avoir un shell python au passage...

Avez vous des sujets/topics/tuto pertinents (ou simplement des conseils) la dessus ?

Je continue à googler...
Merci d'avance

edit : quelques liens interessants
http://www.developpez.net/forums/d76...pp/cpp-python/
http://www.codeproject.com/Articles/...-C-Application
https://www.coveros.com/calling-python-code-from-c/
http://weihuang.blogs.rice.edu/tips-...ion-in-c-code/

Salut,

si tu veux embarquer Python https://docs.python.org/2/extending/embedding.html
Boost le permet plus facilement.

Merci pour ta réponse rapide,

J'avais vu cet article, je me demandais s'il y avait plus efficace/simple.
Bon, donc j'ai ma réponse : ça ou boost, c'est ce qui vient à l'esprit et qui fonctionne.

Je teste :-)

Pourquoi pas une solution en C++ comme Gnu Octave ? Ça me paraîtrait bizarre que tu n’y trouves pas les fonctionnalités que tu cherches.

Je reprends un soft existant, du genre déjà déployé.

L'idée c'est que le soft manipule de gros volumes de données, que ces données sont parfois exotiques (et que ce n'est pas représentable sauf sur une appli custom), et qu'il ne s'adresse a deux trois collègues qui ne sont ni automaticien, ni mathématicien. Donc, Matlab/SciLab/Octave, ils n'en veulent pas. Enfin, pas en tant que base logicielle.

Donc je dois porter sur une base C++/wxWidgets quelques fonctionnalités dont : la possibilité de faire des opérations entre les données, voir de faire quelques opérations custom via scripts conçu par le prochain collègue qui aura envie de jouer.

Je pars peut etre dans le mur, mais j'avais en tête SciLab/Octave (et pad'sous pad'Matlab) ou Python (qui a l'air tres open).
Le problème d'Octave, c'est qu'il n'inspire pas confiance (perenité/aspect IHM) donc je suis parti sur SciLab/Python.


A l'heure actuelle, je deblaie le coté SciLab en attendant d'avoir digéré un peu C++/Boost/Python.
D'ailleurs, si quelqu'un sait comment lire la console SciLab, je suis preneur.



A ce propos, si quelqu'un a la mauvaise idée d'utiliser C::B/Mingw32-gcc pour SciLab :
- faire attention à la version de SciLab (32 bits = 32 bits)
- les BOOL, on est ifndef MSC_VER mais il faut traiter ça comme si on l'était pas (passiver le "typedef enum bool" ainsi que le else dans bool.h des includes SciLab 5.5.2)
- Le SendScilabJob prends des char*, donc :

Code:

---

1 2 3 4 5 6

wxString maclasse::Execute(wxString myCmd) { SendScilabJob(myCmd.char_str()); myRep = wxT("Sent [") + myCmd + wxT("]"); return myRep; }

---

Mais l'idée étant d'avoir l'env. maths géré par .dll, je vais sans doute regarder.
Quelques pages interessantes ici :
https://www.gnu.org/software/octave/...-Programs.html
http://jordi.platinum.linux.pl/octav...-is-octave.pdf (46 et suivantes)
http://octave.sourceforge.net/docs.html
http://octave.sourceforge.net/coda/coda.pdf

Au final,

SciLab fait le job mais Call_Scilab est pas évident à implémenter (il existe une amélioration de l'API...pour java);
Octave aurait sans doute etait plus efficace, cause proche du C++. Mais dans mon cas, le GNU n'est pas synonyme de perenités et d'améliorations (puis pas d'équivalent à Simulink si un jour quelqu'un a la folie des grandeurs).

Python aurait pu être cool mais j'ai été refroidi par Boost.Python + NumPy.
Mais ça aurait sans doute été la solution la plus efficace sur le long terme.

Bref, plus de question,
Je tag en resolu.