headers
Allin Cottrell | 2 Jan 2011 20:03
Picon
Favicon

Re: bug getting the ecm term from a restr vecm vial console??

On Fri, 31 Dec 2010, Artur Tarassow wrote:

> I've got a problem obtaining the ECM-term from a restricted VECM via the
> console.
>
> Consider the following example:
>
> ----------------------------------------
> open denmark
>
> 1 <- vecm 2 1 LRM LRY IBO
> ecm = $ec
>
> 2 <- restrict --full
> b[1]=-1
> b[3]=0
> a[3]=0
> end restrict
> ecm_r = $ec
>
> ecm = ecm ~ ecm_r
>
> The obtained ECM-term from the restricted model looks weird.

Yes, uninitialized rubbish, I'm afraid. The problem was specific
to VECMs with restrictions on \alpha. This should now be fixed in
CVS (but not yet in snapshots since I'm not able to upload the
snapshots at present; that will follow next week).

Allin Cottrell
(Continue reading)

Permalink | Reply | 1 comment |
headers
Allin Cottrell | 2 Jan 2011 20:09
Picon
Favicon

Re: feature requests

On Fri, 31 Dec 2010, Artur Tarassow wrote:

> I have 2 feature requests which would be nice to have in gretl.
>
> 1. Plotting the error-correction-terms:  At the moment one has to save
> the ec-term(s) before one can plot them as series. It would be much more
> convenient to have the possibility to plot them out of the model menu as
> possible for IRFs or residuals. This could be implemented under the
> "Graphs" menu in the vecm model menu: "Graphs --> ECM-Plot" or "Graphs
> --> Combined ECM-Plot" -- of course if not too hard to implement.

That should be straightforward.
>
> 2. Also atm one can only compute the confidence intervals for an
> unrestricted VECM but not for a restricted one. In this case one has
> unfortunately to switch to different software programs.
>  <at> Riccardo: Are there intentions to implement this feature into your SVAR
> package?
> I am sure this is more difficult to program than the first request.

Yes, it's more difficult. The thing is that estimation of a
restricted VECM is already quite tricky even without wrapping it
in a replication loop. But of course it's doable in principle.

Allin Cottrell
Permalink | Reply | 1 comment |
headers
Bob McCall | 2 Jan 2011 20:17
Picon

building Lapack for Gretl

Which precisions and data types does Gretl use in Lapack? Is double real enough?
 
Thanks,
Bob
<div>
<div>Which precisions and data types does Gretl use in Lapack? Is double real enough?</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>Bob</div>
</div>
Permalink | Reply | 0 comments |
headers
Allin Cottrell | 3 Jan 2011 11:46
Picon
Favicon

Re: building Lapack for Gretl

On Sun, 2 Jan 2011, Bob McCall wrote:

> Which precisions and data types does Gretl use in Lapack? Is double real
> enough?

It's not really a matter of what gretl uses, but what lapack uses:
"integer" is a 32-bit int and "doublereal" a 64-bit
flotating-point type ("double").

Allin Cottrell
Permalink | Reply | 1 comment |
headers
Bob McCall | 3 Jan 2011 17:50
Picon

Re: building Lapack for Gretl

But do I need to build the the complex routines? Using your configure script (thanks!)
with: --disable-single --disable-complex
fails in "make check", there are unresolved references in the complex*16 routines.
Maybe I should build the whole thing? When Gretl calls a Lapack routine, it has to specify
s d c or z prefix, so if only the double real routines are used, I could build a smaller library.
I don't need Lapack for anything else, at least for right now. 
Bob 

On Mon, Jan 3, 2011 at 4:46 AM, Allin Cottrell <cottrell-SL7aeOxzxAQ@public.gmane.org> wrote:
On Sun, 2 Jan 2011, Bob McCall wrote:

> Which precisions and data types does Gretl use in Lapack? Is double real
> enough?

It's not really a matter of what gretl uses, but what lapack uses:
"integer" is a 32-bit int and "doublereal" a 64-bit
flotating-point type ("double").

Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users-npDYnXcwJHngpn9g0Uvcdg@public.gmane.org
http://lists.wfu.edu/mailman/listinfo/gretl-users

<div>
<div>But do I need to build the the complex routines? Using your configure script (thanks!)</div>
<div>with: --disable-single --disable-complex </div>
<div>fails in "make check",&nbsp;there are unresolved references in the complex*16 routines.</div>
<div>Maybe I should build the whole thing? When Gretl calls a Lapack routine, it has to specify</div>
<div>s d c or z prefix, so if only the double real routines are used, I could build a smaller library.</div>
<div>I don't&nbsp;need Lapack for anything else, at least for right now.&nbsp;</div>
<div>Bob&nbsp;<br><br>
</div>
<div class="gmail_quote">On Mon, Jan 3, 2011 at 4:46 AM, Allin Cottrell <span dir="ltr">&lt;<a href="mailto:cottrell@...">cottrell@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">On Sun, 2 Jan 2011, Bob McCall wrote:<br><br>&gt; Which precisions and data types does Gretl use in Lapack? Is double real<br>&gt; enough?<br><br>
</div>It's not really a matter of what gretl uses, but what lapack uses:<br>
"integer" is a 32-bit int and "doublereal" a 64-bit<br>flotating-point type ("double").<br><br>Allin Cottrell<br>_______________________________________________<br>Gretl-users mailing list<br><a href="mailto:Gretl-users@...">Gretl-users@...</a><br><a href="http://lists.wfu.edu/mailman/listinfo/gretl-users" target="_blank">http://lists.wfu.edu/mailman/listinfo/gretl-users</a><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply | 0 comments |
headers
Allin Cottrell | 3 Jan 2011 18:25
Picon
Favicon

Re: building Lapack for Gretl

On Mon, 3 Jan 2011, Bob McCall wrote:

> But do I need to build the the complex routines? Using your
> configure script (thanks!) with:
> --disable-single --disable-complex
> fails in "make check", there are unresolved references in the complex*16
> routines.

Sorry, I misunderstood your question. Yes, all gretl needs is the
double-precision real functionality from lapack. But, as you say,
the "check" routines can get tricky when you build lapack with a
subset of the supported types.

Allin Cottrell
Permalink | Reply | 0 comments |
headers
Artur Tarassow | 3 Jan 2011 20:02

Re: bug getting the ecm term from a restr vecm vial console??

Thank you for the quick correction, Allin!

Works fine in cvs now.

Cheers,
Artur

Am 02.01.2011 20:03, schrieb Allin Cottrell:
> On Fri, 31 Dec 2010, Artur Tarassow wrote:
>
>> I've got a problem obtaining the ECM-term from a restricted VECM via the
>> console.
>>
>> Consider the following example:
>>
>> ----------------------------------------
>> open denmark
>>
>> 1<- vecm 2 1 LRM LRY IBO
>> ecm = $ec
>>
>> 2<- restrict --full
>> b[1]=-1
>> b[3]=0
>> a[3]=0
>> end restrict
>> ecm_r = $ec
>>
>> ecm = ecm ~ ecm_r
>>
>> The obtained ECM-term from the restricted model looks weird.
> Yes, uninitialized rubbish, I'm afraid. The problem was specific
> to VECMs with restrictions on \alpha. This should now be fixed in
> CVS (but not yet in snapshots since I'm not able to upload the
> snapshots at present; that will follow next week).
>
> Allin Cottrell
> _______________________________________________
> Gretl-users mailing list
> Gretl-users@...
> http://lists.wfu.edu/mailman/listinfo/gretl-users
Permalink | Reply | 0 comments |
headers
Artur Tarassow | 3 Jan 2011 20:05

Re: feature requests


Am 02.01.2011 20:09, schrieb Allin Cottrell:
> On Fri, 31 Dec 2010, Artur Tarassow wrote:
>
>> I have 2 feature requests which would be nice to have in gretl.
>>
>> 1. Plotting the error-correction-terms:  At the moment one has to save
>> the ec-term(s) before one can plot them as series. It would be much more
>> convenient to have the possibility to plot them out of the model menu as
>> possible for IRFs or residuals. This could be implemented under the
>> "Graphs" menu in the vecm model menu: "Graphs -->  ECM-Plot" or "Graphs
>> -->  Combined ECM-Plot" -- of course if not too hard to implement.
> That should be straightforward.
Cool, this works well here in cvs! Thank you for the implementation, Allin!
>> 2. Also atm one can only compute the confidence intervals for an
>> unrestricted VECM but not for a restricted one. In this case one has
>> unfortunately to switch to different software programs.
>>  <at> Riccardo: Are there intentions to implement this feature into your SVAR
>> package?
>> I am sure this is more difficult to program than the first request.
> Yes, it's more difficult. The thing is that estimation of a
> restricted VECM is already quite tricky even without wrapping it
> in a replication loop. But of course it's doable in principle.
>
> Allin Cottrell
> _______________________________________________
I understand...  But thanks for considering the issue. Maybe it's 
possible to implement this at some point into gretl.Gretl-users mailing list

Best,
Artur
> Gretl-users@...
> http://lists.wfu.edu/mailman/listinfo/gretl-users
Permalink | Reply | 0 comments |
headers
Lawrence Boyd | 4 Jan 2011 01:12
Favicon

x11 problem

I am having a problem in using GRETL. I have successfully installed 
GRETL and the GTK+2.14 on my MAC. When I try to use GRETL I get 
Gretl.app requires Apple's X11. Downloading and installing X11 I get, 
"You cannot install X11 on this volume. Newer software already exists 
on your computor." Which sounds like I do have a version of x11 but it 
is more recent than the one Gretl would recognize. Has anyone else had 
this problem and how can I get Gretl to work?
Cheers

---------------------------------------------

Lawrence W. Boyd Ph.D.
Associate Specialist, Economist
Center for Labor Education 
and Research, University of Hawaii-West O'ahu
96-043 Ala Ike
Pearl City, HI 96782-3366
Phone: 808-454-4780\
Permalink | Reply | 1 comment |
headers
HuiChih Tsai | 4 Jan 2011 09:02
Picon

Further information about count data model

Dear all

I have some problem when estimating the count data model
Where can I find further information about count data models
ex. the description of QML and relative reference abt the robust
standard error in count data model

Thanks a lot.
Permalink | Reply | 0 comments |

Gmane