Well, it is base on TRAMO-SEATS and X12-ARIMA, see https://github.com/jdemetra/jdemetra-core It should not be that hard to adapt from Java to C. On Tue, Nov 16, 2021 at 4:35 PM Sven Schreiber <svetosch(a)gmx.net&gt; wrote:

On Tue, 16 Nov 2021, Sven Schreiber wrote: What we do in gretl is _not_ implementing either X12/X13 nor TRAMO/SEATS independently. That would be far too complex. For some time, Francesca di Iorio and me toyed with the idea of rewriting TRAMO/SEATS in hansl. Eventually, we gave up: it's just too complicated and it's not worth the effort. We should have listened to the advice Gabriele Fiorentini (probably one of the 5 people on earth who knows what actually goes on in the TRAMO/SEATS FORTRAN source) had given us: "you're crazy", he had said. What we do is provide a transparent interface to the corresponding binaries (and IMO we're quite good at that). Now it seems that The JDemetra+ guys have done the crazy thing. From the reference manual: [...] Eurostat took an initiative to create new software [...] The resulting program is called JDemetra+. [...] the most critical innovation is the re-writing of the original FORTRAN codes of X12-ARIMA/X-13ARIMA-SEATS and TRAMO/SEATS in JAVA, following a real object-oriented approach. (taken from https://ec.europa.eu/eurostat/cros/system/files/jdemetra_reference_manual...) I'm saying "it seems" bacause after navigating the GitHub repo Hélio linked, I can't find any numerical code, and there should be A LOT of that: for example, if JDemetra+ actually implemented X13, it should contain a complete implementation of ARIMA modelling, that I can't find anywhere. Maybe I'm just looking in the wrong place. Oh well. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Am 16.11.2021 um 18:25 schrieb Riccardo (Jack) Lucchetti: OK, back to the original question: Do I understand correctly that that's a graphical interface and there's no way to do that by hansl scripting? thanks sven

On Fri, 19 Nov 2021, Allin Cottrell wrote: This would be an _excellent_ idea. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Am 19.11.2021 um 19:46 schrieb Rigoberto Perez Suarez: Thanks, Rigoberto. But to avoid any misunderstanding, let me be clear that I wasn't suggesting to port or adapt anything from JDemetra+. And since it is a Java program, I believe it would also be a bit more difficult to call it from gretl than it currently is to call X12/X13 or Tramo. If I understand correctly, that is what Allin's idea would do; you would get an option to request the Trend-Cycle thing just like you can in the GUI. @Allin and @jack, there's the complication that when you request several series (components) as output, how should those be returned? Inside the options bundle in pointer form? We don't want to necessitate several redundant calls to deseas, I guess. thanks sven

Am 19.11.2021 um 16:11 schrieb Allin Cottrell: Thanks, Allin, for reminding us (me) of this function, which wasn't really on my radar. Two comments about the doc: - This is another example where X13 isn't mentioned yet. Do I understand correctly that for the default settings X12 and X13 should produce identical results? - It's not clear from the doc what it means that the function will fail. Or to put it differently, if it's a hard error and the script cannot continue, then it's a bit of a problem, I'd say. But I'm not sure whether "catch" can be used, since it's a function and not a command. OK, some testing with an artificially constant series: <hansl> nulldata 200 setobs 4 1:1 --time-series series x = 2 series xSA = deseas(x)    # no error, series is produced </hansl> Hm, since I'm not getting an error even there, it's a bit hard to analyze... Could it be that the doc is not up to date? I agree with Jack, this sounds very desirable... thanks sven

Am 20.11.2021 um 23:34 schrieb Allin Cottrell: The x13as.exe file in the path where gretl is pointed to has a date stamp from 2017, basically when this machine/system was set up I guess. The doc says v1.1, don't know which build. OK. What would be great, is if all those options could be included as user-settable which then allow to replicate the presets in the following table: https://jdemetradocumentation.github.io/JDemetra-documentation/pages/refe... I mean primarily RSA0...RSA5. If deseas() accepts an options bundle, putting together the bundles for those presets would be mostly trivial. thanks sven

On Tue, 23 Nov 2021, Sven Schreiber wrote: I'm beginning to think that we could put together a function package for Demetra-like processing. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On Tue, 23 Nov 2021, Riccardo (Jack) Lucchetti wrote: Possibly, but I think this might more easily be done as built-in functionality. Allin

Am 23.11.2021 um 15:05 schrieb Allin Cottrell: Hi, I've taken a look at current git master to see what's the status quo there. AFAICS, the new bundle argument is being passed around internally already, for example in seasonally_adjust_series() in lib/src/genfuncs.c or in adjust_series() in plugin/tramo-x12a.c. However, nothing is done with that bundle yet -- this is not a criticism but just to clarify where we are, and so that we don't forget. For example, if te choice between X13 and Tramo is given in the new bundle (as opposed to the old string argument), the check in seasonally_adjust_series needs to honor that. (lines 1337 and 1341, for example) And the same for adjust_series (line 1997 in tramo-x12a.c). Next, in the underlying adjust_series we have already the line (1999): x13a_opts xopt = {3, 0, 0, 0, 0, 0, 0, 0, NADBL}; So it looks as if transferring any user options from the new options bundle would be quite easy, the infrastructure is already there (for x13). This in turn suggests that we need to specify the recognized or admissible option names for the new bundle, right? Do you want me to come up with suggestions? thanks sven

Am 04.01.2022 um 19:02 schrieb Sven Schreiber: Still learning here... I think I forgot the 'seats' switch in my previous suggestions. Also, the specs RSA2, RSA4, RSA5 only seem to apply to TRAMO which isn't covered here anyway, so that was wrong on my side as well. But then there are the additional specs X11, RSA2c, RSA4c, RSA5c which do apply to X13. (Actually, RSA4c and RSA5c are the recommended things to do per default.) So here's another attempt: bundle X11_opts = _(seats=FALSE, logtrans=0, trading_days=0, \ easter=FALSE, outlier_correction=FALSE, airline=TRUE) bundle RSA0_opts = _(seats=TRUE, logtrans=0, trading_days=0, \ easter=FALSE, outlier_correction=FALSE, airline=TRUE) bundle RSA1_opts = _(seats=TRUE, logtrans=2, trading_days=0, easter=FALSE, outlier_correction=TRUE, airline=TRUE) bundle RSA3_opts = _(seats=TRUE, logtrans=2, trading_days=0, \ easter=FALSE, outlier_correction=TRUE, airline=FALSE) bundle RSA5c_opts = _(seats=TRUE, logtrans=2, trading_days=2, \ easter=TRUE, outlier_correction=TRUE, airline=FALSE) OK, what about RSA2c_opts and RSA4c_opts? - RSA2c: This requires a "working day" adjustment. AFAICS, in contrast to "trading days" that one does not differentiate between the various weekdays, but only separates weekends (plus maybe holidays) and non-weekends. From the X13 documentation at https://www2.census.gov/software/x-13arima-seats/x-13-data/documentation/... (Table 7.28) I think what's needed is the 'td1coef' keyword that would replace 'td' as part of the included predefined variables, but that doesn't seem to be covered by gretl's wrapper so far. - RSA4c: This is the same as RSA2c, only that it doesn't impose the airline model. It also remains to be seen whether the leap year handling that is implicit in X13's 'td' and 'td1coef' variants is really equivalent to what Jdemetra calls "pre-adjustment for leap year". Bottom line: Apart from the needed general comparisons and checks, it would be nice if we could add the td1coef option for working days adjustment to the gretl wrapper for X13. This actually doesn't look so difficult, I might even try it myself... (If I do, it would be in a new branch.) Any comments or feedback welcome thanks sven --- Footnote about RSA5c: (BTW, I'm assuming that there's a typo in the table at: https://jdemetradocumentation.github.io/JDemetra-documentation /pages/reference-manual/sa-specifications.html, because at the bottom it says RSA5 without c, which doesn't correspond to the GUI screenshot and would contradict the other RSA5 entry in the table.)

On 05.01.22 19:29, Sven Schreiber wrote: I've now had a go at this in the new branch x13workingdays. There's a new recognized option key "working_days" for the options bundle to the deseas() function, just like there was "trading_days", with the values 0 (off), 1 (on), 2 (auto). (If the trading_days option is also present and not set to off/zero, then the working_days option will be ignored, currently without a warning.) It compiles and actually seems to work for me; trivial test script: <hansl> open bjg series aha_t = deseas(log(g), _(trading_days=1)) series aha_w = deseas(log(g), _(working_days=1)) series aha_check = deseas(log(g)) </hansl> The three variants produce three slightly different results. (And since trading_days=2 (auto) is the implicit default, this must mean that no trading days effect is found for aha_check, otherwise it would have produced the same result as aha_t.) So far so good, I'd say! It would be nice if some gretl C master eventually could take a look at my edits in the x13workingdays branch. (BTW, is there a special reason why plugin/tramo_x12.h is written with an underscore but plugin/tramo-x12.c with a hyphen?) thanks sven