Discussion :

[Clotho]

Salut la compagnie!

Il y a longtemps que je ne vous ai plus cassé les pieds ici (principalement parce que mes questions ont des réponses déjà fournies en cherchant un peu...) mais là je ne sais pas trop par quel côté aborder mon problème.

Pour faire simple, j'ai un signal très bruité que je dois décomposer en deux parties, et ces deux parties subissent ensuite une approximation pour me fournir dans le cas idéal 2 équations de droites quand c'est possible, sinon une équation de droite, ou quand c'est calme rien. (Cf pièce jointe, des courbes extraites sous Excel ...)

On voit que le premier signal ne fournit qu'une droite, et le second est un cas "bien mais pas top".

Je n'ai pas/plus vraiment de soucis sur la syntaxe et le fonctionnement de mon code matlab (pour une fois ) mais un soucis de performances.

Pour faire ces approximations linéaires, j'ai une équation du type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

coefficients_droite = polyfit((1:fin_droite1,signal_entree(1:fin_droite1),1)

(c'est bien sûr pas fonctionnel comme ça)

La procédure est donc (très) simple, et me donne les bons coefficients a et b de l'équation y=ax+b.

Mon soucis, on y arrive, est qu'utiliser polyfit me semble revenir à chasser des moustiques avec un lance-flamme. Au profiler pour traiter 25000 itérations il me faut une quarantaine de secondes, mais presque la moitié du temps est nécessaire pour une vérification de la fonction polyfit, à savoir la condition:

polyfit>warnIfLargeConditionNumber

, et le calcul qui y est attenant, passant par un condest.

On touche à mes limites, parce que:
-j'ai beau pratiquer Matlab, je connais un dixième des fonctions en étant très optimiste.
-j'ai beau faire un peu de traitement de données/signal, je suis chimiste (j'aime raconter ma vie) donc je ne sais pas vraiment comment faire pour traiter un signal aussi dégueulasse en entrée et arriver à extraire une équation de droite.

Donc on va enfin arriver à ma question:

Mon code marche, c'est la fête, mais c'est trop lent. Pour une approximation linéaire, est-ce que vous avez quelque chose en magasin de plus efficace que polyfit, et qui marcherait sur un signal affreux (donc pas de moyenne glissante ou de calcul de droite niveau collège, j'ai essayé...)?

J'ai un peu regardé interp1, qui me semble rapide pour trouver l'ordonnée à l'origine (mais poins précis que polyfit...) mais je ne vois pas comment l'utiliser pour le coefficient directeur, avec un signal bruité.

[Jerome Briot]

L'opérateur backslash \ devrait être plus efficace que polyfit

=> Ajustement aux moindres carrés de courbes et de surfaces

[Clotho]

Ok parrain.

Mais vu que je suis en vacances je chercherai à mettre en oeuvre à la "rentrée" ! Et si j'y arrive pas je continuerai ce thread. Si j'y arrive je donnerai un ordre de grandeur du gain de performance.

Et comme le dit le premier post dans le lien que tu as donné, effectivement, on est trois à pratiquer Matlab au boulot (bon, c'est moi le meilleur, c'est dire si les autres sont mauvais... ) et personne ne connaissait...

To be continued...

[le fab]

Mais vu que je suis en vacances je chercherai à mettre en oeuvre à la "rentrée" ! Et si j'y arrive pas je continuerai ce thread. Si j'y arrive je donnerai un ordre de grandeur du gain de performance.

salut

j'avais fait un algo de "dérivée glissante", cad des régressions linéaires sur fenêtres de n points glissantes
pour un échantillon de 300 000 points (et fenêtre sur 5 points), j'avais les performance suivantes :
- polyfit : 155 s
- régression linéaire (*) : 14 s
- opérateur \ : 3.5 s

y a pas à dire, c'est que qui va le mieux

sinon j'ai pas testé, mais le pire doit être lsqcurvefit

fab

(*) : développement à la main de pente = covariance/variance

[Clotho]

Des nouvelles!

J'ai donc appliqué la division à gauche (ou \, ou mldivide...) en lieu et place de mon polyfit.

Le premier point: ça fonctionne et fournit rigoureusement les mêmes résultats. Ce qui est le plus important.

Ensuite de passer par \ me permet d'exécuter 20497 calculs en 19.33s tandis que polyfit réclame 39.20s. La vitesse d'exécution est donc doublée!
Ca correspond au meilleur pronostic possible, la fonction polyfit réclamant 20s d'exécution et \ quasiment rien...

Le gain est appréciable, je me retrouve limité par le temps de lecture dans Excel. Ce qui me fait supposer qu'à part quelques petites améliorations sur des fonctions garde-fou j'ai à peu près atteint le niveau de performance maximal.

Merci de m'avoir aiguillé vers cet opérateur, quand j'aurais un peu plus de temps je chercherai à mieux me familiariser avec pour saisir un peu plus l'étendue de ses capacités!

Une fois encore merci, et le sujet passe en résolu!

[Jerome Briot]

je me retrouve limité par le temps de lecture dans Excel.

Tu pourrais nous en dire plus ?
Que fais-tu exactement ?

[Clotho]

Le programme que je fais est la continuité de mes premiers posts ici (à l'époque: découverte de Matlab, vaut mieux pas chercher les questions...).

J'ai 4 caméras qui filment une flamme, je synchronise les images et leur applique tout un tas de calcul de mon cru, pour me retrouver avec des courbes énergétiques, mon signal crado du premier message. Pour tout un tas de contraintes de temps, de budget, de capacité de l'appareil déporté... j'ai actuellement l'ensemble coupé en trois parties.

Une première me fournit les fichiers "vidéo" en fichiers binaires , de la plus petite taille possible juste quelques To pour une semaine d'enregistrements. D'où mon intérêt assez récents pour les NAS dans la partie hardware...

La seconde fait le traitement d'image, ou en gros à partir d'une image j'applique des calculs en cascade (j'aimerai les intriquer par la suite, mais c'est pas une priorité) améliorant l'image pour la détection mais me sortant les profils bruts par détection et par voie.

La troisième partie applique donc cette découpe en droite, ou peut être plus tard en gaussienne, ou autre... puis fait une reconnaissance de signatures suivant ces composantes par voie, puis entre les voies, puis par chronologie.

J'ai donc mes fichiers suivants:

Acquisition -> fichiers binaires très volumineux sans perte -> Détection et profils -> fichiers excel temporaires (divison par 27.000 de la quantité de données à traiter en moyenne) -> classification et sortie des résultats. (division par 50k environ)

Mes fichiers excel sont de l'ordre de 10 à 40.000 fichiers de 2000 à 150.000 lignes par semaine. Ils disparaitront par la suite, le but étant de chaîner l'ensemble "traitement du signal", puis de recoder (ou plutôt faire recoder, je ne sais pas du tout le faire) pour du FPGA ou assimilé pour le passer en embarqué. Pour le temps d'exécution d'excel, j'applique un xlsread pour chaque fichier a traiter et copie en mémoire la totalité du tableau de données, afin de ne pas y faire trop appel (une seule fois par fichier).

Je finalise ma troisième partie en ce moment, et je m'attaquerai ensuite à ne plus passer par Excel. Pour le moment c'est bien pratique pour faire circuler les info à des personnes ne connaissant pas du tout Matlab. Donc le temps des xlsread est "pénible" mais je fais avec, sachant que ça disparaitra par la suite. La découverte du profiler a été un atout énorme!

Pour un néophyte absolu en programmation il y a deux ans, les deux principaux écueils que j'ai rencontré ont été dans un premier temps de comprendre pourquoi simulink travaillait lentement, puis ensuite, après passage à Matlab, bien plus plastique, la gestion des caméras à haute vitesse et de mon appareil en environnement difficile (redémarrages fréquents, configurations qui sautent...) j'ai toujours presque rien compris à la programmation dite objet donc j'ai sans doute appliqué des méthodes bourrines, mais c'est robuste et suffisant!

[Jerome Briot]

Pour le temps d'exécution d'excel, j'applique un xlsread pour chaque fichier a traiter et copie en mémoire la totalité du tableau de données, afin de ne pas y faire trop appel (une seule fois par fichier).

Comme précisé dans la FAQ, tu peux utiliser une fonction plus rapide en cas d'appel fréquent à xlsread : xlsread1

Et si tu veux en savoir plus, tu trouveras sans doute ceci intéressant : Contrôle d'Excel par MATLAB via Automation (dédicace sur simple demande )
Surtout ce chapitre : http://briot-jerome.developpez.com/m...n/lecture/#LIV

[Clotho]

J'avais lu, et appliqué pour un tout autre sujet, ne faisant qu'un appel par fichier je n'ai pas pensé à l'utiliser, pensant que le gain de temps serait négligeable, il faudra que je regarde ça avec attention... En admettant que je retrouve en gros le facteur 2 que j'avais eu sur mon autre fonction, je gagnerai 1.5s sur 10s par fichier. Je pense qu'ensuite je risque d'être limité par mon disque...