You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have taken huge boundaries for the unit testing. I would think it is nicer to have more realistic/strict boundaries.
However, what is a realistic boundary will probably depend on:
SNR
f (for the boundaries of D and D*)
Moreover, now, the boundaries are defined per algorithm in the json file, which gives a lot of redundancy. The flexibility of changing boundaries per algorithm seems to me unneeded (unfair comparison).
Describe the solution
My initial suggestion would be something like:
rTol(f)=Tol * SNR
rTol(D)=Tol * SNR / (1-f+epsiolon)
rTol(D*)=Tol * SNR / (f+epsilon)
Although it is up to discussion.
Moreover, I think the Tol values could be stored centrally (not algorithm-dependent)
Describe alternatives
No response
Additional context
Are you working on this?
None
The text was updated successfully, but these errors were encountered:
Tolerances are difficult. To get them tight I think there would have to be slight differences for each algorithm. That's more of a testing viewpoint. But a more clinical view would be what parameter SNR is necessary? Maybe that's where you are going with your suggestion? I don't really have great answers for this but just trying it with some plots might be helpful.
In terms of code, it should be really easy. Right now the tolerances are being read from the algorithm section, data_ivim_fit_saved. We could include another global section that would be defaults for all of them. Or even something in the testing code that would override those with some other values.
Feature description
Currently, we have taken huge boundaries for the unit testing. I would think it is nicer to have more realistic/strict boundaries.
However, what is a realistic boundary will probably depend on:
Moreover, now, the boundaries are defined per algorithm in the json file, which gives a lot of redundancy. The flexibility of changing boundaries per algorithm seems to me unneeded (unfair comparison).
Describe the solution
My initial suggestion would be something like:
rTol(f)=Tol * SNR
rTol(D)=Tol * SNR / (1-f+epsiolon)
rTol(D*)=Tol * SNR / (f+epsilon)
Although it is up to discussion.
Moreover, I think the Tol values could be stored centrally (not algorithm-dependent)
Describe alternatives
No response
Additional context
Are you working on this?
None
The text was updated successfully, but these errors were encountered: