v2: Merge observable.noiseDistribution and observable.observableTransformation?

[dweindl]

Continuing the discussion from #613, which went a bit off-topic there:

Shall we merge observable.noiseDistribution and observable.observableTransformation in PEtab v2?

I.e. instead of {noiseDistribution=normal, observableTransformation=log}, one could just specify {noiseDistribution=log-normal}.

I am in favor. I think just saying that the measurement error is log-normally distributed is more understandable than talking about observable transformations.

The only downside I can see, is that instead of listing $n$ distributions and $m$ transformations, we'd have to list $n*m$ distributions in the specs.

Related question: do we need log10-type distributions (i.e. the current observableTransformation=log10)? I can see how those distributions are more interpretable in certain contexts (replications, orders of magnitude, ...), but I am not sure how relevant this is in the PEtab context. Do you have good use cases?

[matthiaskoenig]

• in favor of merging (i.e. removing observableTransformation)
• no use case for log10 from my side

[dilpath]

Also in favor of dropping the observable.observableTransformation column, for the same reasons as for why we are dropping the parameterScale parameter priors.

The only downside I can see, is that instead of listing n distributions and m transformations, we'd have to list n ∗ m distributions in the specs.

I would find it easier to comprehend if it's still described in the docs as n distributions and m transformations, which are combined into a transformation-distribution string (e.g. "log-normal") in the observable.noiseDistribution and parameter.prior columns.

Related question: do we need log10-type distributions (i.e. the current observableTransformation=log10)? I can see how those distributions are more interpretable in certain contexts (replications, orders of magnitude, ...), but I am not sure how relevant this is in the PEtab context. Do you have good use cases?

I am in favor of keeping log10 as an option for parameter priors. If I use that as a hint to the optimizer to optimize a parameter on log10 scale, then it makes debugging easier than log scale. But I don't see a reason to keep log10 for observables.

Unrelated: observable.noiseDistribution and parameter.prior will be exactly the same, right? And observable.noiseParameters will be the same as parameter.priorParameters. For that reason we could rename observable.noiseDistribution to observable.noise, or rather rename parameter.prior to parameter.priorDistribution.

[dweindl]

observable.noiseDistribution and parameter.prior will be exactly the same, right?

In terms of admissible values, not exactly, if we'd allow log10 for the one but not for the other.

And observable.noiseParameters will be the same as parameter.priorParameters.

No, because observable.noiseParameters contains only the scale parameter/expression, whereas parameter.priorParameters will contain both the location and the scale parameter. (Further differences might arise from #595 and #617).

For that reason we could rename observable.noiseDistribution to observable.noise, or rather rename parameter.prior to parameter.priorDistribution.

+1 for the latter, for coherence.

[matthiaskoenig]

+1 for the latter (i.e. parameter.priorDistribution) for consistency

[FFroehlich]

In favor of dropping observableTransformation.