Forum Programmation.python numpy: Vecteur avec valeurs fausse après in ifft(fft())

Posté par Yuul B. Alwright le 03 mai 2023 à 04:08. Licence CC By‑SA.

Étiquettes :

mai

2023

Bonjour tout le monde.

Je rencontre un comportement étrange avec les fonctions fft() et ifft() de numpy.

Si je prends un vecteur de 1024 valeurs, que je lui applique une transformée de Fourrier discrète puis une transformée de Fourrier discrète inverse, je n'obtiens pas du tout les même valeurs.

Petit exemple de code:

# Lecture des valeurs d'un fichier audio
values = read_audio_file()

# Limitation du vecteur au 1024 premiers samples
values = values[0:1024]

# Application de fft puis ifft
values_t = np.fft.ifft(np.fft.fft(values)).real

Je n'obtiens pas les mêmes valeurs dans le vecteur values et le vecteur values_t.

Exemple avec les 30 premières valeurs:

values[0:30]
array([ 0,  0,  1, -2,  2, -2,  1,  1, -3,  4, -3,  0,  1,  0,  0,  0, -1,
        1,  0,  0,  0,  0, -1,  2, -2,  2, -1,  1, -3,  5], dtype=int16)

values_t[0:30]
array([-2.77555756e-16,  1.66533454e-16,  1.00000000e+00, -2.00000000e+00,
        2.00000000e+00, -2.00000000e+00,  1.00000000e+00,  1.00000000e+00,
       -3.00000000e+00,  4.00000000e+00, -3.00000000e+00,  2.22044605e-16,
        1.00000000e+00,  4.44089210e-16, -2.22044605e-16,  2.22044605e-16,
       -1.00000000e+00,  1.00000000e+00,  3.33066907e-16,  0.00000000e+00,
       -9.99200722e-16,  6.66133815e-16, -1.00000000e+00,  2.00000000e+00,
       -2.00000000e+00,  2.00000000e+00, -1.00000000e+00,  1.00000000e+00,
       -3.00000000e+00,  5.00000000e+00])

Même en indiquant n=1024 pour les fonctions fft() et ifft() j'ai le même résultat.

Une idée ?

# pas si different que ca

Posté par jemore le 03 mai 2023 à 07:53. Évalué à 5. Dernière modification le 03 mai 2023 à 08:55.
Salut.

En tant normal, ifft(fft(s)) doit être strictement égal à s mais tu dois certainement tomber dans des problèmes d'arrondis et de conversion de type (tes entrées sont des int16, mais tes sorties sont sans doute des float)

Je ne suis pas un spécialiste de numpy ni des opérations de transformées de Fourrier, mais tes valeurs de sorties ne sont pas si différentes des valeurs d'entrées. En tout cas, pour les 5 premieres valeurs et pour les 5 dernieres :
```
     0  ≈ -2.77555756e-16
     0  ≈ 1.66533454e-16
     1  ≈ 1.00000000e+00
    -2  ≈ -2.00000000e+00
    ...
```
De plus, la dynamique des tes valeurs d'entrées (l'écart entre la plus petite et la plus grande), est faible par rapport à la plage de valeur possible des echantillons. Si tes données sont des int16, il faut que tu utilises les valeurs possibles dans les int16, sinon tu perds en précisions. Dans l'exemple que tu indiques, si ce sont les vrais valeurs d'un fichier audio, ca parait cohérent d'avoir des valeurs entre -10 et +10 dans les premiers echantillons, alors que l'espace int16 est de -32000 à +32000.
- [^] # Re: pas si different que ca
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 03 mai 2023 à 07:59. Évalué à 5.
  
  J'abonde dans le même sens : à la précision machine près, les valeurs semblent bien identiques. Il suffirait de les convertir vers les entiers les plus proche pour retrouver exactement l'entrée.
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: pas si different que ca
    
    Posté par Yuul B. Alwright le 03 mai 2023 à 17:02. Évalué à 3.
    
    Yep, c'était ça.
    
    J'ai pas pensé à convertir les types.
    
    Merci à vous 2.
# numpy.allclose

Posté par fab le 07 mai 2023 à 11:35. Évalué à 3. Dernière modification le 07 mai 2023 à 11:35.

Sans faire plus de conversion, tu peux utiliser la fonction numpy.allclose pour vérifier que deux tableaux sont "égaux" à la précision numérique de leurs types (ou du type qui permet de les comparer).