Decomposition statistics in default print

[AQLT]

I propose to add some statistics on the decomposition (max 2 lines) in the default print

rjd3x13::x13_fast(rjd3toolkit::ABS$X0.2.09.10.M)
#> Model: X-13
#> Log-transformation: yes 
#> SARIMA model: (2,1,1) (0,1,1)
#> 
#> SARIMA coefficients:
#>    phi(1)    phi(2)  theta(1) btheta(1) 
#>    0.3474    0.2173   -0.6994   -0.4804 
#> 
#> Regression model:
#>              td          easter TC (2000-06-01) AO (2000-07-01) 
#>        0.002323        0.052011        0.159034       -0.290077 
#> 
#> Seasonal filter: S3X3; Trend filter: H-23 terms
#> M-Statistics: q Good (0.465); q-m2 Good (0.513)
#> QS test on SA: Severe (0.000); F-test on SA: Good (0.997)
#> 
#> For a more detailed output, use the 'summary()' function.

By default the threshold are the one of JDemetra+ but can be set with the option thresholds_pval

[TanguyBarthelemy]

Hi @AQLT,

In {JDCruncheR}, we created some options to customize the thresholds (applied to the demetra_m.csv matrix).

Do you think it's possible to unify these options (without having to redefine them in different places)?
Also, when you say

By default the threshold are the one of JDemetra+

This means that the thresholds used BY DEFAULT (in {rjd3x13} are the one defined in JDemetra+ BY DEFAULT and not the one customized by the user.
?

[AQLT]

Hi @TanguyBarthelemy,
Since the package are not linked to the local installation you cannot get the thresholds defined by users. Do we have some examples of countries which have changed those thresholds and why? When you update JDemetra+ you have to update your option so I don't think the user would troubled to set an option, for example using the .Renviron file. Since you also have the p-values I don't think the values are controversial.
The m-statistics are normalized to 1 so I think the only debate is on the threshold used for p-values: we can still remove them and only put the p-value and add stars as in the summary regression table.
On the harmonisation with JDCruncher, since you have in the package much more thresholds, if we keep the option in rjd3x13/rjd3tramoseats I think the easier would be to have several options in JDCruncher instead of one.

[TanguyBarthelemy]

Do we have some examples of countries which have changed those thresholds and why?

I don't agree (or maybe I didn't understand), customising thresholds is important even within the same country to adjust the different modalities (Good, Bad, Severe...).

When you update JDemetra+ you have to update your option so I don't think the user would troubled to set an option, for example using the .Renviron file.

I totally agree, putting it in a .Renviron or .Rprofile seems like a good solution.

The m-statistics are normalized to 1 so I think the only debate is on the threshold used for p-values

Once again, even when normalised to 1, it may be appropriate in some cases to change the acceptance values and push them to 1.1 or 1.3.

we can still remove them and only put the p-value and add stars as in the summary regression table.

Are you talking about the display? I'm in favour of leaving them in (except if there are too many elements?). Otherwise the information will still be available in the model.

I think the easier would be to have several options in JDCruncher instead of one.

That's a good idea. In {rjd3revisions}, the choice was made to declare as many options as thresholds.
This forces the user to define one option per test, but in the end it's no more of a handicap than having to use one large option for everything:
Example:

options(
    augmented_t_threshold = c(severe = 0.005, bad = 0.01, uncertain = 0.05),
    slope_and_drift_threshold = c(severe = 0.005, bad = 0.05, uncertain = 0.10),
    theil_u2_threshold = c(uncertain = .5, bad = .7, severe = 1)
)

instead of

options(rjd3revisions_threshold = list(
    augmented_t_threshold = c(severe = 0.005, bad = 0.01, uncertain = 0.05),
    slope_and_drift_threshold = c(severe = 0.005, bad = 0.05, uncertain = 0.10),
    theil_u2_threshold = c(uncertain = .5, bad = .7, severe = 1)
))

On the other hand, if you want to give the user the freedom to change the thresholds for a single function call (as done in {JDCruncheR}), this forces the developer to add a large number of arguments to his functions

[AQLT]

To summarise, removing the "Good"/"Bad" would be OK and more conventional?

On JDCruncheR, one solution could be to use the function get_thresholds() instead of getOption("jdc_thresholds") and the set_thresholds() would change the specific options?

[TanguyBarthelemy]

Thank you for your remarks on JDCruncheR, I'll raise some issues on this subject.