make fit_DoseResponseCurve() also return a De that can be negative in interpolation

[mcol]

I know this has already been discussed in the past, but the question has come out again: why don't we return a negative De with interpolation?

Besides mathematical/physical reasons why a negative De does not make sense, there is an application for which having it may be useful. If we run dose samples, we'd like to see that the De values produces are around zero. This could be done graphically or more formally via a statistical test. However, if all negative De values are set to NA, this is no longer possible.

For this purpose, we could return an additional De.raw field from fit_DoseResponseCurve() to store the raw fitted value. This will be ignored by all other functions, but it is available for the interested users.

[RLumSK]

No problem, I guess the question will always come up again and again. I am not really sure how to handle this. We should stay neutral towards what the user does, but if we have specialist software, the results should also make somewhat sense. And hence I am against calculating values from which we know that they are wrong, but perhaps I am overlooking something.

Regarding the argument, I guess I don't get the part "if all negative De values are set to NA, this is no longer possible." If we throw out NA values, we could still see values > 0; even values very close to it. Perhaps you could give an example?

Plus once more, it is never really a mathematical problem. If I had said that I was wrong, because if the numbers can be calculated they can.

• Values < 0 mean that the dose could not be determined with the system. (full stop) However, if we want to ignore this, for whatever reason, we have to go full circle and must logically include values that are Inf + values where the detector overloaded as valid too. Because these values could not be determined by the system either. The values < 0 are arbitrary. Or in other words < 0 is not different from -Inf; we simply do not have this information but add something of nothing because mathematically we can.

• And yes, there are rare cases where an equivalent dose would be negative but it can be clearly seen in the curves that this was a technical issue. It does not make it better though and the values should be discarded.

• The other problem is the used curves. If we interpolate, then the L_n/T_n is negative we somewhat throw overboard our model to determine the positive values. This can be done, but then we don't need the models in the first place or at least we should not contain them anymore.

• I, however, agree that the NA is technically very misleading, it should be more correctly written outside detection limit (also to catch the Inf values).

Additional thoughts:

The term De.raw is misleading. Because it seems that we filter values, while we don't. The opposite is true; we return all fitted values indeed, and the user is free to use the fitted parameter function to derive whatever the user wants.

To be more constructive, I should point out that we already return the "raw" fitted values in the element $Fit. This means the formula can be easily used to calculate whatever the user wants (on purpose, by the way, because it allows testing different Ln/Tn combinations, which indeed make sense).

[RLumSK]

@mcol. An update with a refined argument and a potential solution:

• You can keep (as already approved) the De.raw values as backup.
• However, we will need to derive them from the MC runs and report, for instance, them along with quantiles. Meaning, reported is then a data.frame not just a numeric vector. Ideally, we even report the distribution as a matrix. Likely too much data though, but this could be tackled with a parameter for "advanced analytics or so”.
• We have to considerably rework the implementation of the NA setting but use this as evidence for values that cannot be detected and then consequently implement the ISO approach (https://nvlpubs.nist.gov/nistpubs/sp958-lide/164-166.pdf).
• This can be done by estimating the L_c (see PDF) and only if Ln/Tn < 95% MDD we report NA otherwise we solve. This will, however, lead to even more NA values but this time justified.
• We will require asymmetric uncertainties per se.
• To avoid adding high-dose censorship as well, we should introduce L_c as rejection criteria. Then we will leave this entirely to the user because we have already a rejection criteria for the high-dose.

This will take, unfortunately, a little bit of extra work and the user will dislike the asymmetrical uncertainty; however, if we want to include it, it should be done correctly.

[RLumSK]

I've reopened that issue because we should indeed tackle the underlying cause correctly. Regardless of the PR that I had just approved. Thanks to your digging and insisting, I had (as written above) another look and we should implement this new rejection criteria into analyse_SAR.CWOSL() ... or we find another way of implementing this in more general terms. At least then it will be clean from a methodological standpoint, using a standardised procedure that was peer-reviewed and we can refer to.