Discussion :

[neismarspra]

bonjours,

ça fait 5 mois que je travaille sur un projet, pour mon niveau énorme.
Il est hors de question d'abandonner.
Mais voila mes méthodes, et idées deviennent ingérables dans le cadre d'un projet si gros.

Il s'agit de traitement/analyse de données, surtout de recherche multiple.
Un facteur important est le temps de calcul qui devrait être réduit au minimum.
Donc une usine a gaz avec sql ou autre ne serait pas une bonne solution.
(les données en question peuvent être comparées à des flux), donc inutile de se casser la tête avec sql, oracle ou...

Je cherche plusieurs entrées en même temps sur un flux.

Bon jusque la pas de souci, le problème c'est dans le nombre d'algorithmes (il devrait y'en avoir autour de 75 une fois le projet terminé).

Certains algorithmes se basent sur le résultat de ceux qui ont été exécutés précédemment. Certain sont appelés seulement si un autre donne un résultat précis.

Et j'ai a peine commencé à écrire le premier algorithme que je me rends compte que pour l'instant je ne suis pas capable de gérer un seul algorithme de façon adéquate.

alors 75...

Je voudrai demander si il existe des méthodes/modèles, purement théoriques, de gestion/recherche aussi complexe. Ou savoir si vous connaissez une "structure séquentielle" ?

Je ne sais pas trop exprimer mes idées et mes question, et c'est bien pour cela que j'ai besoin de conseils. Merci

A avoir jeter un coup d'oeil a la faq algo, je peut dire qu'une majoriter ecrasante des algorithme fonctionne comme "un tri en place". Sauf que ce n'est pas un tri mais une recherche.
Autrement dit, a part le resultat des recherche precedente (et encore..), je n'utilise que des calcule, pas de variable globale, ou apelle pour savoir si tel ou tel constante blalbabla... bref tous est calculer, et recaluler.


Si il vous manque des information pour y voire claire, n'esiter pas.

[pseudocode]

Tu aurais un exemple "simple" à nous donner. J'avoue ne pas trop voir ce que tu appelles "recherche de plusieurs entrées en même temps sur un flux".

[neismarspra]

flux:
2,-1,0,2,1,-1,-2,1,0,-2

sur ce flux

al1:
cherche plus grand que 1.
si trouver verifi si element suivant est egal a 1
dans ces cas si troisieme element egal xxx
renvoi au serveur dddddd

al2:
cherche 0
si trouver verifier que element precedent et suivant son oposer
(2 et -2)
si tel est le cas....

j'apele une "entre", un algorithme. Bien sur c'est bcp plus complexe que dans l'exemple.
les al1 et al2 doivent etre execure le plus vite possible apres reception de chaque nouvelle element sur le flux.
et par exemple si al2 rempli toute les condition, et les variable revoyer on des valeur
souhaiter (algorithme centrale, qui gere le tous, choisis les algorithme a apeler et gere les lien entre les different flux, et les resultat), alors al3 est apeler.

pour pas s'y perdre totalement je travail que sur un flux pour l'instant, et l'algorithme "central" n'existe pas encore.
ce flux est representer par une class, qui est la class principale du programme
identifier par un id et une map, qui "contient" le flux.

pour vous decrire mon probleme, c'est surtout le faite que je commence a programmer sans pouvoir
controler, verifier, executer du code, du moins, justqu'a ce que un voir deux algorithme et la structure de controle central ne soit terminer.

ce qui ne coresspond absolument pas au methode de programmation que j'utiliser jusqu'a ce jour. (autodidacte )

[plegat]

Salut,

Va falloir sortir la feuille et le stylo... ou le poster et le marqueur!

Met ça sur papier auparavant, écrit, dessine quelles doivent être les relations entre tes "algos", tu devrais pouvoir en sortir une certaine logique temporelle, sur laquelle tu pourras baser ta manière de coder. Sépare tous tes algorithmes, de manière à ce que ce soit le plus modulaire possible (il ne s'agirait pas de devoir tout recoder si en fin de compte l'algo74 doit passer avant l'algo61...). EN prime, si chaque algorithme est bien cloisonné, tu pourras plus facilement faire tes recherches de goulot d'étranglement pour optimiser la rapidité au final.

En gros, divise ton gros problème en plusieurs petits avec une bonne gestion des appels.

[neismarspra]

recherches de goulot d'étranglement

??? ca veus dire quoi??

la modulariter des algo est determinante, car moi je fait les algorithme, et une partie de la gestion des appelle, mais apres c'est le programme quichoisi, combine, apelle, envoi e\des instruction au serveur ect...


Mais ma question se dirige plus vers .................

bon, je vais essayer d'en terminer un, et on verra bien.

merci

[plegat]

??? ca veus dire quoi??

Tu parles de vitesse d'exécution dans tes posts...
Un goulot d'étranglement, c'est les 0.1% de code où l'application passe 99% du temps (en gros, pour simplifier).
En gros, en faisant cette analyse, tu sais dans quel algo ton application passe le plus de temps, et ralentit donc toute la chaine de traitement. Il ne tereste plus ensuite qu'à optimiser l'algo en question.
Mais ce n'est pas ton problème immédiat pour le moment.

mais apres c'est le programme quichoisi

Euh.. non, pas vraiment, le programme ne fait que ce que le progammeur lui a dit de faire. C'est à toi de choisir quoi faire en fonction de quoi.

Mais ma question se dirige plus vers .................

vers....................???

Si c'est un problème d'organisation des appels, fait un graphe sur le papier.
Tu mets deux algos... puis trois... puis 4... etc

[pseudocode]

les al1 et al2 doivent etre execure le plus vite possible apres reception de chaque nouvelle element sur le flux.
et par exemple si al2 rempli toute les condition, et les variable revoyer on des valeur souhaiter (algorithme centrale, qui gere le tous, choisis les algorithme a apeler et gere les lien entre les different flux, et les resultat), alors al3 est apeler.

En gros, ton "algorithme centrale" est un moteur de workflow et tes "sous algorithmes" sont des activités du workflow, qui peuvent être implémentées sous forme d'automates d'état.

[neismarspra]

oui, en simplifiant un max c'est ca.
Mais y'a pas d'etat binaire par exemple.
C'est pas oui ou non suite au resultat precedent. Ca devrait etre: oui, peu etre dans ces condition, mais a coter ca pourai etre mieux si tu fait ca et ca....

[pseudocode]

oui, en simplifiant un max c'est ca.
Mais y'a pas d'etat binaire par exemple.
C'est pas oui ou non suite au resultat precedent. Ca devrait etre: oui, peu etre dans ces condition, mais a coter ca pourai etre mieux si tu fait ca et ca....

Ca c'est du domaine du workflow. Tu peux examiner plusieurs chemins (split), chacun avec ses propres sous-algorithmes, et attendre les différents résultats (join) pour décider quel chemin tu prendras ensuite.

[Jean-Marc.Bourguet]

Si j'ai bien le compris, je ferai qqch comme ceci:

1/ a chacun de tes algo correspond un objet (qui maintient entre autre l'etat necessaire qu'il faut entre l'arrivee d'echantillons)

2/ lors de l'initialisation on indique les dependances entre algos leur dépendances a un ordonnanceur.

3/ l'ordonnanceur trouve un ordre valide d'execution des algos (c'est un simple tri topologique sur base des dependances declarees en 2) ou donne une erreur s'il n'y en a pas

4/ a chaque arrivee d'echantillon, les algos sont executes dans l'ordre determine en 3.

Tu peux prevoir un petit langage specialise pour decrire les dependances, et peut-etre meme les algos (ca peut faire peur mais un interpreteur bien concu pourrait etre meme plus rapide que du code compile parce qu'au total plus dense et que tout tient dans le cache).

Tu peux prevoir des dependances dynamiques (qui sont crees et detruites suivant l'etat des algos) mais il faut prevoir alors la possibilite de retrouver l'ordre et savoir quand ca doit se faire (entre deux echantillons ou des que les dependances sont changees?)