[Gretl-devel] some new gretl issues

Sven Schreiber svetosch at gmx.net
Fri Oct 26 09:48:51 EDT 2007

Allin Cottrell schrieb:
> On Fri, 26 Oct 2007, Sven Schreiber wrote:

>> Somebody said the sourceforge tool is not good, but I'd say we can
>> always switch to something better later. (Provided that at least the sf
>> tool has some usable export feature?)

Let me stress the question mark here, does anybody know if the bug
database can be exported from the sourceforge tracker in a practically
useful way?

>> 2) with T = 235 and 2 equ with about 20 coeffs each, gretl says it
>> doesn't have enough dofs for autocorrelation test of order 4 (or
>> even 1!) -- sometimes it even does that just for estimation! (maybe
>> triggered by repeatedly checking/un-checking the robust cov option,
>> which I did?)
> I'll take a look.  But if you could provide an explicit spec that 
> provokes the problem that would be helpful.

I know :-) I'm bound to come across this again and then I'll try to make
it more explicit.

>> 3) a big wishlist item or question: how to modify an existing 
>> model instead of starting always from scratch???
> Hmm.  The model spec is (mostly) remembered from one opening of 
> the model dialog to another, and you also have the add/omit test 
> entries in the model window.  Could you be a bit more explicit on 
> what you'd like to see?

Estimate variant 1, play around with variant 2 but turns out as a dead
end; want to go back to variant 1 and change something there again. --
In Eviews you would fork from variant 1 by copying the corresponding
equation object as many times as needed. PcGive remembers all previous
specifications and you can later choose from a list or just keep hitting

Since in the session view/model table the model is already saveable, I
imagine it would be possible to add the feature to open the
specification window in a state given by the saved model?

>> 4) bug recipe (not 100% sure which part is the bug though):
>> a) create new dataset
>> b) save dataset as "test1.gdt"
>> c) save as session "my1session.gretl"
>> d) close dataset
>> e) open above session file, and get the data named "data.gdt" (
>> instead of "test1.gdt")
> Ah well, that's supposed to be a feature.  When you save a 
> session, a snapshot of the data used in that session is stored as 
> data.gdt, inside the session zipfile.  Think about what might 
> happen if a session were not self-contained in that way, but 
> referenced an external data file.  The user could delete or modify 
> the datafile between saving and re-opening the session, in which 
> case the re-opened session would be badly broken.

Yes of course, but then why after step c) (but before step e) does it
still say "test1.gdt", although in principle we should be in the same
state just after c and just after e?

Or to put it differently: Eviews works only in session-mode (a workfile
in principle being a snapshot of everything, not just data), and Pcgive
works only in datafile mode (enhanced by the constant result log writing
and batch script writing which helps you replicate stuff and save
states). In contrast, gretl tries to support both approaches, and it is
difficult to get it 100% right, and sometimes it causes confusion.

Since gretl already has session management, maybe it should adopt the
Eviews approach and enforce the use of sessions? (I haven't thought
about this enough to really suggest this, though, so it's really just
thinking out loud and asking.)


More information about the Gretl-devel mailing list