Specifying /nirs(i)/probe/momentOrders as string as opposed to numeric array

[Zahra-M-Aghajan]

At the moment, in the specifications, the momentOrders are required to be specified as 1D numeric arrays. However, this could easily lead to confusion and, as a results, I was wondering this could be changed to strings? As an example, consider the following scenarios:

1. Some groups might provide 3 moments (sum, mean ToF, variance ToF) but encode them in alphabetical order (so 1: mean, 2: sum, and 3: var; numbers will correspond to the dataTypeIndex).
2. Some groups might provide only 2 moments: sum and mean in some of those, and mean and var in the others.. and both cases will be represented as 1 and 2.

I hope these example were helpful in demonstrating the clarity that the usage of strings can bring.

[dboas]

@zahraaghajani , I recall that the original thinking was that the numeric number would be the power of the moment. Moments are calculated as \integral t^n I(t) dt. So n=0 is the mean, n=1 is the mean time of flight, and n=2 is the variance.In your example above, if some groups use sum and mean then their momentOrders would be a 1x2 numeric array with [0 1]. And another group uses mean and variance and their momentOrders would be [0 2]. The first group could choose momentOrders to be [1 0] if they wanted. They just have to make sure that their data.measurementList.dataTypeIndex properly references the correct value in the momentOrders.

So, it seems to me we only have to clarify the momentOrders spec to indicated that the numeric value is the power of time in the moment integral. From what you describe, I think this would be a better solution than changing momentOrders to a string.

Let me know if this makes sense or if I misunderstood your issue.

Thanks

[Zahra-M-Aghajan]

@dboas This is perfect and the clarification of what the array should be (in the specs page) will address everything that I mentioned. Thank you!

[dboas]

I have now clarified the definition of momentOrders as suggested above

[dboas]

I am reopening this issue because we need to be more clear in the definition of the moment order. The text we just added to the spec is accurate for the n=0 moment (i.e. the sum) and the n=1 moment (i.e the mean time of flight). Although actually for n=1 we need to indicate that it is normalized by the n=0 moment. But the n=2 moment that is commonly used in the literature is the Variance, and this is not accurately described in the specification since the way Variance is described in the literature is the central moment (t-)^2 and not the moment t^2. Note that as with n=1, the second and higher moments are all normalized by the Sum moment.

What is the nest way to describe this in the spec?

Given that the literature is stable on using Sum, MTOF, and Var, I am inclined to modify the spec to explicitly define these 3 moments and indicate they are n=0, 1, and 2 respectively. If people every use higher order moments, then the spec can say that it is expected that these would be the central moments. I can not expect that people would save the non-central moments for n>=2.

Any other thoughts on this?

[Zahra-M-Aghajan]

I agree that the definitions can be clarified further, namely that all moments (n>=1) are normalized by the sum (n=0), and that for n>=2, centralized moments are used. It is possible to spell out the formulas in the attached figure in the specs or add references to Liebert et al, 2003 or Wabnitz et al, 2020. What do you think?

[dboas]

i agree. Can you make a pull request with these edits?

From: Zahra M. Aghajan @.> Date: Friday, August 6, 2021 at 12:31 PM To: fNIRS/snirf @.> Cc: Boas, David @.>, State change @.> Subject: Re: [fNIRS/snirf] Specifying /nirs(i)/probe/momentOrders as string as opposed to numeric array (#54)

I agree that the definitions can be clarified further, namely that all moments (n>=1) are normalized by the sum (n=0), and that for n>=2, centralized moments are used. It is possible to spell out the formulas in the attached figure in the specs or add references to Liebert et al, 2003 or Wabnitz et al, 2020. What do you think?

[image]https://user-images.githubusercontent.com/4925224/128540448-161ba45c-a913-47c5-9a1e-774d329e1357.png

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/fNIRS/snirf/issues/54#issuecomment-894376146, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHFCP5DOSCX2DJYOVPY5UOTT3QE5ZANCNFSM5AXI5SNA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[Zahra-M-Aghajan]

Absolutely! I will do so shortly.

[dboas]

@rob-luke and @fangq , this is just clarifying the spec for time domain moments and won't break anything, so I will just go ahead and accept this PR when it comes in

[rob-luke]

@Zahra-M-Aghajan was this sufficiently addressed? If there are any outstanding issues could you please list them so we can tick them off. Cheers

[julien-dubois-k]

This issue seems sufficiently addressed and could be closed. cc @Zahra-M-Aghajan