[REDMINE1D-60] [RM-5973] use inverse variance instead of variance Created: 04/Jun/21  Updated: 19/Sep/23  Resolved: 19/Sep/23

Status: Won't Fix
Project: 1D Redmine
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: Redmine-Jira Migtation Assignee: Redmine-Jira Migtation
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Created on 2020-09-17 15:50:28 by Didier Vibert. % Done: 0

à l'intérieur de la libraire, changer le vecteur d'erreur (dans la classe FluxAxis)

pour contenir l'inverse de la variance au lieu de sqrt(variance)

intérêt:

  • ne pas accepter de variance nulle (c'est déjà testé dans la méthode validnoise)
  • pouvoir traiter des variances infinies (ie inv variance nulle) et donc des samples flaggé autrement qu'en les supprimant du spectre au niveau du client.
    c'est une nécessité dans le cas du log-lambda (Fourrier), il faut conserver tous les samples régulièrement espacés en log

(à regarder s'il vaut mieux prendre la racine carrée ou non...)

note: le vecteur d 'erreur est actuellement inclu en "perruque" à l'intérieur du FluxAxis, peut être intéressant d’écrire une classe spécifique (dérivée de FluxAxis ou FluxAxis itself ?) aggrgée dans CSpectrum. ticket refactor spécifique ?



 Comments   
Comment by Redmine-Jira Migtation [ 19/Sep/23 ]

Comment by Pierre-yves Chabaud on 2020-09-17 15:59:50:
Didier VIBERT wrote:
> note: le vecteur d 'erreur est actuellement inclu en "perruque" à l'intérieur du FluxAxis, peut être intéressant d’écrire une classe spécifique (dérivée de FluxAxis ou FluxAxis itself ?) aggrgée dans CSpectrum. ticket refactor spécifique ?

Je ne connais pas les raisons historiques (ou de conception) qui ont amené l'erreur a se retrouver dans la classe FluxAxis. Cela dit, peut-on imaginer une classe mere FluxAxis et des classes filles FluxAxisErr, FluxAxisVar, FluxAxisInvVar... qui permettraient de s'affranchir de la "nature" de l'erreur ?

Comment by Redmine-Jira Migtation [ 19/Sep/23 ]

Comment by Didier Vibert on 2020-09-17 16:54:36:
Pierre-yves CHABAUD wrote in #note-1:
> Didier VIBERT wrote:
> > note: le vecteur d 'erreur est actuellement inclu en "perruque" à l'intérieur du FluxAxis, peut être intéressant d’écrire une classe spécifique (dérivée de FluxAxis ou FluxAxis itself ?) aggrgée dans CSpectrum. ticket refactor spécifique ?
>
> Je ne connais pas les raisons historiques (ou de conception) qui ont amené l'erreur a se retrouver dans la classe FluxAxis. Cela dit, peut-on imaginer une classe mere FluxAxis et des classes filles FluxAxisErr, FluxAxisVar, FluxAxisInvVar... qui permettraient de s'affranchir de la "nature" de l'erreur ?

sur le plan de la structure des objets, ça me parait bien. Après le but d'avoir InvVar c'est de pouvoir y mettre 0 si le sample doit être masqué. Sinon il faut utliser l'IEEE inf. On peut imaginer que le client ait accès à ces différentes classes possible et qu'on sache convertir vers l'InvVar pour l'utiliser en interne, du coup le mieux est peut être d'avoir une classe FluxInvVar avec différents constructeurs qui puissent convertir directement en InvVar ?

Comment by Redmine-Jira Migtation [ 19/Sep/23 ]

Comment by Pierre-yves Chabaud on 2020-09-17 17:03:36:
Didier VIBERT wrote in #note-2:
> sur le plan de la structure des objets, ça me parait bien. Après le but d'avoir InvVar c'est de pouvoir y mettre 0 si le sample doit être masqué. Sinon il faut utliser l'IEEE inf. On peut imaginer que le client ait accès à ces différentes classes possible et qu'on sache convertir vers l'InvVar pour l'utiliser en interne, du coup le mieux est peut être d'avoir une classe FluxInvVar avec différents constructeurs qui puissent convertir directement en InvVar ?

Oui, ca me semble une bonne idée. On fonctionne en interne avec de l'inverse variance et l'API permet l'exploitation d'erreur/variance de différentes "natures" en faisant la conversion.

Comment by Redmine-Jira Migtation [ 19/Sep/23 ]

Comment by Vincent Le Brun on 2023-08-29 16:08:01:
toujours intéressant ?

Generated at Sat Feb 10 15:28:54 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.