5:32 a.m.
Hi,
before getting to the issues list I put together during my last
semi-serious gretl session, I want to support the idea of a more formal
bug collection & management approach that came up recently. Among other
reasons, I think one gets a nice feeling of job satisfaction when
looking at resolved bugs...
If you want I could do the maintenance of the bug list/database at least
initially. I mean not on my computer at home or by setting up a server,
but just by verifying, classifying, and hopefully closing bug reports
that are stored in some sourceforge/bugzilla/trac/whatever instance.
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?)
What do you think?
--
Ok, here's the list (on gretl windows snapshot from 9/19, so not the
most recent I'm afraid):
1) the VAR model window doesn't have a close box (apart from the window
manager thing) -- actually I guess all windows that have a menu bar
instead of a toolbar... I know I'm partly responsible because I
requested removing redundant close buttons at the bottom, and this thing
actually isn't a problem, but it caught my attention.
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?)
3) a big wishlist item or question: how to modify an existing model
instead of starting always from scratch???
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")
5) also observed that saving a subset of variables to a new datafile
doesn't update the variable list/view, but does change the datafile
name above the variable listing. Not sure which part of this
behavior is intended and which is a bug.
Oh BTW, I'm sorry but I won't have time to take another look at de.po
before next week. But if needed for release I can promise Tuesday.
thanks,
sven
9:48 a.m.
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
"previous".
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.)
thanks,
sven
9:57 a.m.
On Fri, 26 Oct 2007, Sven Schreiber wrote:
I want to support the idea of a more formal bug collection &
management approach that came up recently. Among other reasons,
I think one gets a nice feeling of job satisfaction when looking
at resolved bugs...
If you want I could do the maintenance of the bug list/database at least
initially. I mean not on my computer at home or by setting up a server,
but just by verifying, classifying, and hopefully closing bug reports
that are stored in some sourceforge/bugzilla/trac/whatever instance.
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?)
Thanks very much for the offer. I tend to agree that using SF
might be acceptable, at least for now. Personally, I don't have
time to set up something better. Other thoughts?
Ok, here's the list (on gretl windows snapshot from 9/19, so not
the most recent I'm afraid):
1) the VAR model window doesn't have a close box (apart from the window
manager thing)
That's an oversight -- it should have a File/Close item like the
regular model window. I'll fix that.
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.
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?
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.
5) also observed that saving a subset of variables to a new
datafile doesn't update the variable list/view, but does change
the datafile name above the variable listing. Not sure which
part of this behavior is intended and which is a bug.
That seems inconsistent. We probably need to pop up the "Do you
want to switch to the reduced dataset?" dialog.
Oh BTW, I'm sorry but I won't have time to take another look
at
de.po before next week. But if needed for release I can promise
Tuesday.
Tuesday would be fine; probably the end of the week would be fine.
Allin.
11:13 a.m.
On Fri, 26 Oct 2007, Sven Schreiber wrote:
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?
Hmm, I've poked around on the site, and I don't see any obvious
option of that sort.
>> 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?)
OK. I think I've found and fixed the problem with that.
>> 3) a big wishlist item or question: how to modify an
existing
>> model instead of starting always from scratch???
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?
Yes, that sounds like a good idea, but probably after 1.6.6. Any
suggestions for the best placement of this? Maybe in the model
window have an item "Revise specification" or "New specification
based on this model" (too verbose?) -- or some such -- under the
File or Edit menu?
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.
Granted. I'm not even sure what counts as "100% right", though
I'm open to suggestions as to what would be "more right" than the
current situation.
Since gretl already has session management, maybe it should
adopt the Eviews approach and enforce the use of sessions?
I wouldn't favour that personally. _Perhaps_ there should be some
sort of mode switch the user can set, though it would not be very
easy to explain briefly to the user exactly what such a switch
would do.
Allin.
6188
days inactive
6188
days old
3 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber