Re: [Gretl-users] specific lags in arima
by Allin Cottrell
On Wed, 26 Jan 2011, Allin Cottrell wrote:
> On Tue, 25 Jan 2011, Bob McCall wrote:
>
> > I'm using gretl 1.9.3 and the dataset chomage.gdt. I tried to
> > set specific ar lags to 1 4 5 but Gretl added 10 ma terms at
> > lags 1 thru 10 in addition to the ar terms at lags 1 4 5.
>
> Thanks for the report. You're right, something has gone wrong with
> the parsing of ARIMA input when specific AR lags are requested. In
> particular, as you say, if you specify d=1 (differencing) in that
> context, you instead get a slew of MA lags.
It seems this problem has been sitting there since we introduced
the "specific lags" mechanism, but to date nobody has triggered it
(by trying to use specific lags + differencing).
The fix was a simple one-liner, but unfortunately I can't commit
it to gretl CVS or put it out in a snapshot right now, since the
business end of the sourceforge site is out of action. Hopefully
that will be resolved soon.
Allin Cottrell
12 years, 4 months
Re: [Gretl-users] specific lags in arima
by Allin Cottrell
On Tue, 25 Jan 2011, Bob McCall wrote:
> I'm using gretl 1.9.3 and the dataset chomage.gdt. I tried to
> set specific ar lags to 1 4 5 but Gretl added 10 ma terms at
> lags 1 thru 10 in addition to the ar terms at lags 1 4 5.
Thanks for the report. You're right, something has gone wrong with
the parsing of ARIMA input when specific AR lags are requested. In
particular, as you say, if you specify d=1 (differencing) in that
context, you instead get a slew of MA lags.
It's the differenced version that's broken: if you specify AR lags
as in
arima {1 4 5} 0 1 ; y
you get the expected results, while
arima {1 4 5} 1 1 ; y
does not work correctly. I'll make a priority of fixing this.
Allin Cottrell
12 years, 4 months
specific lags in arima
by Bob McCall
I'm using gretl 1.9.3 and the dataset chomage.gdt. I tried to set specific
ar lags to 1 4 5 but Gretl
added 10 ma terms at lags 1 thru 10 in addition to the ar terms at lags 1 4
5. I couldn't clear the model
by clearing the dataset. Also, the first difference spinner was not picked
up. I tried specific
lags (1 12 13 ma lags) using bjg.gdt and there were problems with that as
well. (command has insufficient args)
Bob
12 years, 4 months
Ralph M Rodriguez/PO/KAIPERM is out of the office.
by Ralph.M.Rodriguez＠kp.org
I will be out of the office starting 01/24/2011 and will not return until
01/27/2011.
Hi All, I will be out of the office on business from Jan 24 through Jan 26,
returning to the office Jan 27. Please, if you have an immediate concern
regarding Cost Model or Construction Economics, please email or contact
Bradley A Njus, 510 625 4595, with your questions.
Best Regards, and have a prosperous 2011,
Ralph
12 years, 4 months
Re: [Gretl-users] About gretl with the Traditional Chinese version (zh_TW)
by Allin Cottrell
On Wed, 12 Jan 2011, yinung at Gmail wrote:
> I know that the default fixed font of the current gretl version for windows
> with Traditional Chinese is set to "MS Gothic"
> Would this setting be changed to "NSimsun," because I found that it is
> better than "MS Gothic"
OK, we can change that.
Allin
12 years, 4 months
Re: [Gretl-users] Phillips-Perron Test
by Allin Cottrell
On Thu, 20 Jan 2011, Henrique Andrade wrote:
> Em 20 de janeiro de 2011 Allin escreveu:
>
> (...)
> > I think I see what's happening here. If I'm right, the problem is
> > that the R folks have once again messed with the directory
> > structure under Program Files/R on Windows: this changed from
> > R 2.9 to R 2.11, and now it's changed again with 2.12. Also if I'm
> > right, the Phillips-Perron script should now work OK with current
> > R (in the gretl snapshot for Windows).
>
> Dear Allin, at first I would like to thank you for your efforts trying to
> solve this problem.
>
> Now I'm testing my script with the latest snapshot but nothing different
> happens. The problem persists.
In that case, if you have the patience, you could try the test
build of gretl at
http://ricardo.ecn.wfu.edu/pub/gretl/gretl_test.exe This will
produce debugging statements relating to the R link on stderr. You
can see these if you start gretl with the --debug option:
gretlw32.exe --debug. This might enable us to see what's
happening.
I might say: I tested your pp script on Vista using the current
gretl snapshot with R 2.12.1 and it ran OK. So I'm out of ideas on
the problem you're seeing.
Allin Cottrell
12 years, 4 months
Re: [Gretl-users] variable types in different scripts
by Allin Cottrell
On Fri, 21 Jan 2011, Sven Schreiber wrote:
> I'm having a problem with what may be called variable "lifetime" or
> scope. Consider the two trivial scripts:
>
> <script1>
> scalar temp = 1
> </script1>
>
> <script2>
> matrix temp = muniform(2,1)
> </script2>
>
> If I run both of them in this order, the second one gives an error,
> apparently because gretl doesn't like to put a matrix result into the
> scalar variable temp...
>
> (BTW, I know that the 'open' command clears gretl's workspace, which
> would probably be the solution here. But I find myself doing more and
> more with gretl's nice matrix language without opening datafiles. So
> maybe a 'clear' command is needed?)
"dataset clear" will do the job.
Allin Cottrell
12 years, 4 months
variable types in different scripts
by Sven Schreiber
Hi,
I'm having a problem with what may be called variable "lifetime" or
scope. Consider the two trivial scripts:
<script1>
scalar temp = 1
</script1>
<script2>
matrix temp = muniform(2,1)
</script2>
If I run both of them in this order, the second one gives an error,
apparently because gretl doesn't like to put a matrix result into the
scalar variable temp.
Is this a reasonable behavior? If the commands were executed in a single
console session or in a single file (including further called files or
functions), I think yes. But if the commands live in separate script
files that just happen to be executed in the same gretl session, I tend
to think that gretl should do some sort of garbage collection when the
end of a (main driver) script is reached. Or is it the official policy
that the user should do a 'delete temp' at the end of any such script?
(BTW, I know that the 'open' command clears gretl's workspace, which
would probably be the solution here. But I find myself doing more and
more with gretl's nice matrix language without opening datafiles. So
maybe a 'clear' command is needed?)
thanks,
sven
12 years, 4 months
help with gretl
by Kahkashan Shaukat
Hi, Folks,
I am new to gretl. I need to use the gretl libraries within my C++ codes to
be able to get ARMA estimations. However, whatever dataset that I try, the
model returns an error code of 3 corresponding to finding a singular matrix,
or an error code 5. Could someone please help me figure out what I am doing
wrong? I am pasting my code here. Thanks in advace.
extern "C" {
#include </usr/local/include/gretl/libgretl.h>
}
int main ()
{
char *fname;
int err;
MODEL *mymodel=NULL;
const int *list, *pqlags;
const double **Z = NULL;
double **data = NULL;
DATAINFO *pdinfo;
gretlopt opt;
PRN *prn = NULL;
const char *arma_spec = "1 1 1 ; 0";
const char *arma_pq_lags = "1 1 1 ; 0";
fname = "ar1.gdt";
putenv("GRETL_PLUGIN_PATH=/usr/local/lib/gretl-gtk2/");
libgretl_init();
//prn = gretl_print_new(GRETL_PRINT_STDOUT, NULL);
pdinfo = datainfo_new();
list = gretl_list_from_string(arma_spec, &err);
if(err){
printf("%dError forming list...\n", err);
}
else{
printf("Successfully formed list...\n");
}
pqlags = gretl_list_from_string(arma_pq_lags, &err);
if(err){
printf("%dError setting pqlags...\n", err);
}
else{
printf("Successfully set pqlags...\n");
}
double d[100] =
{14.00506,11.88694,15.84804,16.51717,14.55883,18.91454,15.56367,18.95697,21.16984,23.70920,
26.51456,25.02122,24.67900,24.57805,27.53288,26.16876,25.97866,28.77978,27.00108,26.31299,
23.90812,28.09266,27.59627,28.99814,27.25777,21.54126,24.70151,29.98875,28.83029,30.92882,
33.13654,31.92837,32.16757,35.21054,36.53613,35.32862,36.95167,35.64065,33.83243,35.97180,
37.06993,40.31979,40.41081,41.82210,41.57343,41.89816,36.40815,37.99717,39.21328,38.22750,
39.87281,39.07015,38.82488,41.02295,40.33261,38.38574,34.24121,34.99200,34.66115,36.47538,
38.15541,38.16863,36.70234,35.50128,30.94532,30.10700,29.89030,26.38155,28.98603,30.92539,
30.58638,34.29289,32.15656,33.86830,37.14510,32.88388,31.34332,34.36881,35.96956,36.14701,
37.06460,34.94625,36.38298,37.88554,36.18585,35.67232,38.44046,38.32361,35.27670,39.22223,
38.74319,38.24741,38.20142,36.89593,36.60553,39.88735,39.64674,36.07956,34.86294,29.09646};
double *mydataarr[100];
for(int i = 0; i < 100; i++){
d[i] = i;
mydataarr[i] = &d[i];
}
Z = (const double **)mydataarr;
double **pZ = (double **)mydataarr;
mymodel = gretl_model_new();
pdinfo = datainfo_new();
pdinfo = create_new_dataset(&pZ,1,100,1);
const DATAINFO *info = (const DATAINFO *)pdinfo;
printf("Before mymodel=%lu\n",mymodel);
(*mymodel)= arma(list,pqlags,Z,pdinfo,OPT_NONE,NULL);
if(mymodel->errcode)
{
printf("ARMA model error: %d\n", mymodel->errcode);
}
else
{
printf("%f",mymodel->uhat[0]);
}
destroy_dataset(pZ, pdinfo);
gretl_print_destroy(prn);
libgretl_cleanup();
return 0;
}
--
Kahkashan.
12 years, 4 months
