Bug in series name created after X13 run
Posted: Mon Aug 29, 2022 4:26 am
by Fifis
Hello! The series generation after X13 is behaving strangely: it drops the letter Q from the adjusted variable name (_D11 after X13). Here is a MWE where a duplicate series is created:
Code: Select all
rndseed 1
pagecreate(page = Q) Q 1995 2027
series IPCH_ZE_OE_BASE_Q = nrnd
IPCH_ZE_OE_BASE_Q.x13(save = "d11", tol = 1e-7, iter = 2000, tf = auto) @reg(regs = "easter[8] td", aictest = "td easter", outtype = "tc ao ls") @tramo(maxdiff = "(1,1)", maxorder = "(3,1)")
The expected behaviour is just creating the IPCH_ZE_OE_BASE_Q_d11 series. However, it creates an extra series, IPCH_ZE_OE_BASE__d11. In a real script that we are using for forecasting, it is not even creating the IPCH_ZE_OE_BASE_Q_d11 series---only IPCH_ZE_OE_BASE__d11. The letter `Q' in the variable name is gobbled, and we cannot run loops properly because of the mangled name. What is the solution to this?
We are using EViews 12 build 2022-04-19.
Yours sincerely,
Andreï V. Kostyrka
Re: Bug in series name created after X13 run
Posted: Mon Aug 29, 2022 10:28 am
by EViews Gareth
X-13 has a 16 character limit for series names.
Re: Bug in series name created after X13 run
Posted: Tue Aug 30, 2022 12:50 am
by Fifis
Dear Gareth,
Thank you for your prompt reply. I have seen the Fortran sources of X13, and they are staying as they are, not fixed if it isn't broken.
However, I do believe that it is an EViews bug because EViews variable names can be longer, and using the X13-trimmed name and substituting it back into EViews is a mix of paradigms. We are no longer in the punch-card era where every byte costs a fortune and variable names better be short. We are not even in the 8.3 filename era ('C:\PROGRA~1' etc.). Modern programming languages support long and meaningful variable names, and this is why we are writing code that is easy to understand and debug. But X13 is using the EVX13TMP.DAT file in AppData\ev_temp anyway! The X13 Fortran procedure may enjoy variable names being as short as possible, but the naming conventions should not be broken in EViews. Other programming languages preserve the original call or attributes, strip the meta-data, pass the bare-bones numbers to X13, and then, restore the meta-data back. We are expecting the EViews names not to be allowed to be corrupted by external routines.
Simple users would benefit a lot if EViews honoured the original variable name and restored it upon X13 termination. It is not rare to construct variable names to make the code understandable. E.g. Eurostat is providing prc_hicp_ctrb (which is easy to read as 'percentage HICP contributions'), and we are merely adding prefixes to conduct analysis (e.g. prc_hicp_ctrb_m_base or prc_hicp_ctrb_m_sc1 for baseline and scenario). This is already quite parsimonious naming, and losing the 17th and further characters in high-level scripting languages should not be happening. JDemetra+ does not trim names. The R interface to X13 (the `seasonal` library) does not trim names, yet it relies on the same X13 binaries as EViews does.
Can we expect this undocumented behaviour to be fixed in EViews? I should be grateful if the next patch did it.
Yours sincerely,
Andreï V. Kostyrka
Re: Bug in series name created after X13 run
Posted: Tue Aug 30, 2022 6:26 am
by EViews Gareth
EViews 13 has such a feature
Re: Bug in series name created after X13 run
Posted: Tue Aug 30, 2022 9:35 am
by Fifis
Thanks! I shall upgrade and see if the issue disappears.