9:26 a.m.
I have noted that it is now possible to define a list of variables to test
for parameter stability which is is really nice!
Nevertheless, even though the break date is provided in the print-out there
is possibility to access this break date. Given that it's possible to store
the test statistics and pvalue, why is it not possible to store the date?
Best,
Artur
8:42 p.m.
On Thu, 20 Nov 2014, Artur T. wrote:
I have noted that it is now possible to define a list of variables to
test
for parameter stability which is is really nice!
Nevertheless, even though the break date is provided in the print-out there
is possibility to access this break date. Given that it's possible to store
the test statistics and pvalue, why is it not possible to store the date?
Excuse me, Artur, but of course it's "possible" to store the break
date. It's merely a matter of:
1) Design decision: what shall we call the new accessor variable?
2) Design decision: can this cover any other "extra" information
that might be stored with other hypothesis tests?
3) With the design decisions taken, write 3 or 4 new C functions and
edit maybe half a dozen gretl source files.
4) With the new code added, document it.
5) Test the addition for bugs.
Meanwhile, the gretl developers have classes to teach and even
families to interact with. We're not sitting around watching TV and
eating chocolates!
Allin
2:56 a.m.
Dear Allin,
Excuse me if my former mail sounded to demanding. I was not demanding
the immediate implementation of this feature. Of course I know that
Jack, you and the other gretl developers are busy and have to take care
of family things etc.
My mail was rather intended as a suggestion or long-term feature
request. Maybe I was a bit naive thinking that its realization is rather
simple and straightforward.
Artur
On 21.11.2014 02:42, Allin Cottrell wrote:
On Thu, 20 Nov 2014, Artur T. wrote:
> I have noted that it is now possible to define a list of variables to test
> for parameter stability which is is really nice!
> Nevertheless, even though the break date is provided in the print-out there
> is possibility to access this break date. Given that it's possible to store
> the test statistics and pvalue, why is it not possible to store the date?
Excuse me, Artur, but of course it's "possible" to store the break
date. It's merely a matter of:
1) Design decision: what shall we call the new accessor variable?
2) Design decision: can this cover any other "extra" information
that might be stored with other hypothesis tests?
3) With the design decisions taken, write 3 or 4 new C functions and
edit maybe half a dozen gretl source files.
4) With the new code added, document it.
5) Test the addition for bugs.
Meanwhile, the gretl developers have classes to teach and even
families to interact with. We're not sitting around watching TV and
eating chocolates!
Allin
4:08 a.m.
Am 21.11.2014 um 08:56 schrieb Artur T.:
Dear Allin,
Excuse me if my former mail sounded to demanding. I was not demanding
the immediate implementation of this feature. Of course I know that
Jack, you and the other gretl developers are busy and have to take care
of family things etc.
My mail was rather intended as a suggestion or long-term feature
request. Maybe I was a bit naive thinking that its realization is rather
simple and straightforward.
Can you believe that after all those years with gretl I wasn't even
aware of this feature? It is nice indeed. Given that it is (of
course...) translated into German, either it must have been there
forever before I took over the translation, or I must have been sleeping
while I translated this. Or maybe Alzheimer showing up.
Anyway, while we're talking about medium- to long-term design issues,
let me add some thoughts on this:
1) IMHO this shows that naming/wording is important in the menus. Who
should guess what a "QLR test" in the testing menu of a model window is?
Perhaps the keyword "break" could be added, "QLR break test" or
something like that.
2) Perhaps this (as well as Chow?) could be a candidate for subsuming
under 'modtest'. At least I don't currently see the rationale (apart
from history/path-dependence) for which tests are in 'modtest' and which
have their own command.
3) This test seems to beg for a further option to set the amount of
trimming. (I.e. s.th. like --trimming=0.1.)
4) And I agree that Artur's suggestion also appears natural, perhaps it
could be called something like '$qlrdate'.
Actually, maybe (1), (3), and/or (4) are candidate projects for people
(like me) that want to contribute in principle but really have almost no
idea about all the interdependencies at the C level and also have
extremely limited experience with C. For example, (1) sounds pretty
straightforward once I have an idea where that code is located. (3) and
(4) are already quite a bit more demanding I guess, but still sound
doable in principle.
thanks,
sven
3649
days inactive
3650
days old
3 comments
3 participants
participants (3)
-
Allin Cottrell -
Artur T. -
Sven Schreiber