Discussion :

[bourgui78]

Bonjour,
je viens vers vous, car je préssens que mon programme va bugguer sans avoir eu le temps d'enregistrer les calculs dans le fichiers csv...
c'est tout de même 3200 boucles de 3200 boucles

je constate que le programme n'écrit pas à chque boucle dans le fichier destinataire, il le fait à la fin alors que j'ai bien mis la fonction d'écriture à l'intérieur de la boucle.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
print u"Période en Fréquence", Freq[len(Freq)-1]
Periode = 1/(float(Freq[len(Freq)-1])*1e9)  # Calcul de la période pour la correspondance en secondes
 
fileFFTinv.write("\n"+u"FFTinv"+"\n")
 
print u"longueur de la liste Signal", len(Freq)
 
fileFFTinv.write(u"t en s"+";"+u"valeur FFT inv"+"\n")
 
# Pour la formule de la FFT inv cf "Traitement du signal avec Scilab : la TFD" Denis Rabasté, IUFM Aix Marseille p4/16
for k in range(0, dimensionX):
    print u"k = ", k
    nz = 0
    FFTinv = (ListeSignal[nz]*np.exp(2*1j*pi*k*nz/dimensionX))    # point de continuité en (0;0)
    for nz in range(1, dimensionX-1):
        FFTinv = FFTinv+(ListeSignal[nz]*np.exp(2*1j*pi*k*nz/dimensionX))  # FFT inverse sans le rapport 1/N
    #print u"valeur de la FFT inverse", (FFTinv)
    FFTinv = FFTinv/float(dimensionX)
    IncFFTinv = u"UReFTTinv =%s, UImFTTinv = %s, r = %s" % as_std_uncertainty(std_covariance(FFTinv))
    #  Extraction de l'incertitude de la FFT
    fileFFTinv.write((str(float(k*Periode)) + ";" + str(value(FFTinv))) + ";" + str(IncFFTinv) + "\n")
    # k*periode = temps en secondes FFT inverse X le rapport 1/N

si vous avez une idée à mon problème, elle sera la bienvenue.

Autre question qui n'a rien à voir avec ce qui précède.
Faire tourner le programme avec la console pycharm ou en double cliquant sur le programme directement, a-t-il une incidence sur la rapidité d'execution et de capacité de méméoire ?

je vous remercie par avance pour votre aide.

Patricia

[wiztricks]

Salut,

Chaque opération d’écriture dans un fichier (disque dur "normal") prendra du temps (>1000 fois plus qu’écrire en mémoire).
Pour "optimiser", il est préférable de faire moins d’opérations en écrivant les données utilisateurs par paquet.
C'est ce qu'on appelle une fonctionnalité de cache. Elle est généralement réalisée par le "file system" (et non par le langage de programmation). Lorsque le programmeur souhaite forcer l’écriture de chaque ligne, il a la possibilité d'appeler .flush.

Faire tourner le programme avec la console pycharm ou en double cliquant sur le programme directement, a-t-il une incidence sur la rapidité d’exécution et de capacité de mémoire ?

Vous créez des programmes pour qu'ils puissent être exécutes directement lorsqu'ils sont au point.
Pour les mettre au point, un IDE comme PyCharm "coûtera" un peu (surtout en mode debug) mais c'est pour la bonne cause!
La question est: "Quel problème cherchez vous à résoudre?"

- W

[VinsS]

Salut,

Tu ne le vois peut-être pas s'écrire en continu, c'est possible et c'est un mécanisme normal.

Si tu veux forcer l'écriture sans attendre, et si c'est indispensable, ajoute ces lignes après le write()

Code :

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

1
2
3
 
    fileFFTinv.flush()
    os.fsync()

http://docs.python.org/2/library/std...h#file-objects



... deuxième, bonjour wiztricks.

[bourgui78]

merci pour vos réponses... ça me rassure en partie, car là ça fait 24h que ça tourne et je n'en suis qu'à la moitié.
en fait je me disais que si je passais à l’exécution je gagnerai réellement du temps.

VinsS tu dis que

Tu ne le vois peut-être pas s'écrire en continu, c'est possible et c'est un mécanisme normal.

mais si ça plante ça va écrire tout de même les résultats déjà obtenus ?

Merci encore à vous 2

Patricia

[psyphi]

Pour savoir si cela écrit regarde si la taille du fichier évolue. Si ce n'est pas le cas.
Comme dit précédement tu ne devrais pas faire d'accès disque à chaque itération.
Autre chose qui m'inquiète dans ton code tu ne gères pas les exceptions, c'est à dire qu'en cas de problème le comportement de ton programme n'est pas prévisible.

[bourgui78]

je viens de faire une copie du fichier d'enregistrement... et les résultats y sont

Par contre question bête, mais je pense connaitre la réponse... Faut que mon fichier d'enregistrement se trouve plutôt sur le disque local...que sur un serveur non ?

car dans ce cas, je sais déjà comment rendre plus rapide mon code

Patricia

[psyphi]

C'est certain!

[wiztricks]

mais si ça plante ça va écrire tout de même les résultats déjà obtenus ?

Avec un langage normal, on trappe l'erreur et/on on s'assure de la fin des trucs en cours avant de sortir du programme même dans les cas imprévus.
Je ne sais pas dans quelle mesure Python ne le fait pas automatiquement. Comme je suis plutôt genre "ceinture et bretelles", j'encapsule dans un try... except... Le must est de forcer le passage dans un exit handler, mais ça demande un peu de réflexion pour créer des objets adressables dans ces contextes la.

Ceci dit le 3200 * 3200 exprimes en secondes donne > 133 jours.
Il serait sage d'optimiser un peu voire de paralléliser, fractionner pour que le temps d’exécution soit raisonnable.
- W

[bourgui78]

de calcul... j'essaie en enregistrant sur le disque local

[wiztricks]

vous pourriez essayer de factoriser un peu:

Code :

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

1
2
3
    FFTinv = (ListeSignal[nz]*np.exp(2*1j*pi*k*nz/dimensionX))    # point de continuité en (0;0)
    for nz in range(1, dimensionX-1):
        FFTinv = FFTinv+(ListeSignal[nz]*np.exp(2*1j*pi*k*nz/dimensionX))  # FFT inverse sans le rapport 1/N

devrait pouvoir s’écrire:

Code :

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

1
2
3
4
    c = 2*1j*pi*k/dimensionX
    FFTinv = (ListeSignal[nz]*np.exp(c*nz))    # point de continuité en (0;0)
    for nz in range(1, dimensionX-1):
        FFTinv = FFTinv+(ListeSignal[nz]*np.exp(c*nz))  # FFT inverse sans le rapport 1/N

supprimer 5 opérations, vu le nombre d’opérations devrait se voir.
- W