Solving problem of `uq_print_uq_inversion.m` on dealing with quantiles if the situation is very simple

Dear @paulremo, dear all,

it seems that I observed a further well-hidden bug, i.e. a bug that only shows up if only one parameter is unknown and also the error distribution is given. In this situation, in the report generated by uq_print_uq_inversion.m the value for the 0.05 Quantile is also printed as value for the 0.95 Quantile, see the output
SCR_BI_to_2261_to_send-out.zip (2.0 KB) of
SCR_BI_to_2261_to_send.m (1.8 KB) .

According to my investigations, it seems that this incorrect output is created from the line 166 in uq_print_uq_inversion.m. There it is excepted that percentiles(1,mm) is the value for for the 0.05 Quantile for the mm-th unkown parameter/Error and percentiles(2,mm) is the value for the corresponding 0.95 Quantile., which seems to satisfied in most situations, but not in the simple one under considerations.

Since percentiles is copied from module.Results.PostProc.Percentiles.Values in uq_print_uq_inversion.m the corresponding field is printed in my test file, showing that in the special situation that there is only one unknown parameter and no unknown error size it holds that one can find the value for the 0.95 Quantile in
module.Results.PostProc.Percentiles.Values (1,2) and not in
module.Results.PostProc.Percentiles.Values (2,1) as expected somehow by uq_print_uq_inversion.m.
The content of module.Results.PostProc.Percentiles.Values is copied
in uq_postProcessInversion.m from percentiles containing the output of uq_inversion_percentiles(Sample3D, perc_probabilities), which is an output of the matlab funtion quantile.

So, I suggest that somewhere during one of this coping of data processes it should be to checked if one is in the spacial situation that the (copied) output of quantile is a (1,2) field and to create then a copy that is the transposed (2,1) field, such that the report generated by uq_print_uq_inversion.m is also correct in simple situations.

To decide where this should be done requires some more knowledge on the UQLab programming style then I have.

Greetings
Olaf

1 Like

Hi @olaf.klein

Thanks for finding this well-hidden bug. As you correctly point out, the root of the problem is inside the uq_inversion_percentiles function. It can also be traced to the defaults for the percentiles that are specified inside uq_postProcessInversion as a row vector, when they should be a column vector.

To fix this bug, I changed the default and added an input check to uq_inversion_percentiles to convert the probabilities input to a column vector, if passed as a row vector.

Thanks again for catching this!

3 Likes