On 02/05/2024 11:00, Rigoberto Perez Suarez wrote: > ... > > This code does not work properly. It is necessary to include a new > parenthesis in the quotient (l.$x/l.$x(-1)) (which would not be > necessary) to perform the operation correctly. Uhm, the syntax above works fine here, with respect to the number of parentheses. However, it seems that we do have another problem: the script below produces bogus results, which are evident if you run it (the series "foo" and "ty1" should be identical). ... This is due to the fact that the "listname.$x" idiom is _not_ valid outside functions: it's a special provision to ensure that series names coming from the outside level of execution don't clash with locally-defined series. I think this should be intercepted somehow, and possibly an error should be flagged.

On 02/05/2024 11:57, Sven Schreiber wrote: > Well, I thought so, too. However, even inside a function there seems > to be a problem. Test case: [...] I managed to track down the problem somehow. It looks as if operator precedence might be the issue:

I guess that once this (and another issue the development team is aware, relative to the windows version) is fixed we should go for an emergency release, shouldn't we?

Dear All,

I was wondering whether there is a gretl script that does the wild bootstrap cointegration test in this fashion: https://rdrr.io/cran/VARtests/man/cointBootTest.html

Thanks for your report, Rigoberto! Clear and precise reports like yours, with an example script and an indication of the first release when working code got broken, make debugging much easier than it would otherwise be. I think the bug that you describe should be fixed in today's gretl snapshots. It sounds like you have a known workaround for the bug -- adding parentheses where they should not be needed -- so maybe your gretl usage is OK for now. Anyway, we'll make sure that this fix doesn't get broken before the next gretl release, 2024b. Allin Cottrell On Thu, May 2, 2024 at 5:00 AM Rigoberto Perez Suarez <rigo.perez.s(a)gmail.com&gt; wrote: > > Hello, > I have been a Gretl user for many years, and I would like to thank you for the important development you have promoted during this time. > We have observed a typo since 2023b version when calculating rates using a list. > More specifically, for the individual series we compute without problem: > T=round(10000*(x/x(-1)-1))/100 > > However, when we use a list: > > list l=y1 y2 y3 > list l_t=null > loop foreach x l > > genr t$x=round(10000*(l.$x/l.$x(-1)-1))/100 > > list l_t+= t$x > > endloop > > This code does not work properly. It is necessary to include a new parenthesis in the quotient (l.$x/l.$x(-1)) (which would not be necessary) to perform the operation correctly. > > Thank you and best regards > Rigoberto Pérez _______________________________________________ Gretl-users mailing list -- gretl-users(a)gretlml.univpm.it To unsubscribe send an email to gretl-users-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/

Am 02.05.2024 um 11:57 schrieb Sven Schreiber: > > Well, I thought so, too. However, even inside a function there seems > to be a problem. Test case: > > <hansl> > > open denmark > list L = LRM LRY > > function void checko(list L, series LRM) > > list Lt = deflist() > > loop foreach x L > series t$x = round(10000*(L.$x/L.$x(-1)-1))/100 > Lt += t$x > endloop > > # compare > series myt_LRM = round(10000*(LRM/LRM(-1)-1))/100 > > eval sum(abs(myt_LRM - Lt[1])) # should be zero > end function > > checko(L, LRM) > > </hansl> > > At first sight this looks pretty bad, to be honest. > OK, so with the latest and greatest gretl 2024b this works as expected again -- did anybody add this little script to the test collection somewhere? (Or an equivalent one.)