5:30 p.m.
Hi,
two questions/comments:
Why isn't it possible to specify seasonal dummies for the KPSS test?
And secondly, when applying omission restrictions to OLS the message
about the information criteria seems to be wrong -- this could be a
translation error, I will check that, but mentioning it here just in case.
thanks,
sven
4:03 a.m.
On Sat, 9 Jul 2011, Sven Schreiber wrote:
two questions/comments:
Why isn't it possible to specify seasonal dummies for the KPSS test?
Are we assured that the distribution of the test statistic is
invariant with respect to seasonal dummies?
And secondly, when applying omission restrictions to OLS the message
about the information criteria seems to be wrong -- this could be a
translation error, I will check that, but mentioning it here just in case.
The English message is correct, I'm not sure about translations.
Example:
open data4-10
ols 1 0 2 3 4 5 6
omit 5 6
The omit command produces:
Test statistic: F(2, 45) = 0.66365, with p-value = 0.519935
Of the 3 model selection statistics, 3 have improved.
That is, the omission of variables 5 and 6 has improved (i.e.
reduced the values of -- see chapter 21 of the User's Guide) all
three model selection criteria. This is easily verified by
inspection of the printouts.
Allin
7:38 a.m.
On Sun, 10 Jul 2011, Allin Cottrell wrote:
On Sat, 9 Jul 2011, Sven Schreiber wrote:
> two questions/comments:
>
> Why isn't it possible to specify seasonal dummies for the KPSS test?
Are we assured that the distribution of the test statistic is
invariant with respect to seasonal dummies?
We are. PCB in person said so, so we should be safe:
Phillips, Peter C. B. & Jin, Sainan, 2002.
"The KPSS test with seasonal dummies," Economics Letters, Elsevier, vol.
77(2), pages 239-243, October.
(http://www.sciencedirect.com/science/article/pii/S0165176502001271)
I committed some modification to CVS so that the kpss command now accepts
a --seasonals option. As everyone knows, GTK mysteries elude me, so you'll
find no changes in the GUI client.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
8:58 a.m.
Am 10.07.2011 09:38, schrieb Riccardo (Jack) Lucchetti:
On Sun, 10 Jul 2011, Allin Cottrell wrote:
>
> Are we assured that the distribution of the test statistic is
> invariant with respect to seasonal dummies?
We are. PCB in person said so, so we should be safe:
Phillips, Peter C. B. & Jin, Sainan, 2002.
"The KPSS test with seasonal dummies," Economics Letters, Elsevier, vol.
77(2), pages 239-243, October.
(http://www.sciencedirect.com/science/article/pii/S0165176502001271)
Actually I thought it was already in the original KPSS article, but this
is also good to know.
I committed some modification to CVS so that the kpss command now
accepts a --seasonals option.
very nice, thanks.
-sven
2:54 a.m.
On Sun, 10 Jul 2011, Riccardo (Jack) Lucchetti wrote:
On Sun, 10 Jul 2011, Allin Cottrell wrote:
> On Sat, 9 Jul 2011, Sven Schreiber wrote:
>
>> two questions/comments:
>>
>> Why isn't it possible to specify seasonal dummies for the KPSS test?
>
> Are we assured that the distribution of the test statistic is
> invariant with respect to seasonal dummies?
We are. PCB in person said so, so we should be safe:
Phillips, Peter C. B. & Jin, Sainan, 2002.
"The KPSS test with seasonal dummies," Economics Letters, Elsevier, vol.
77(2), pages 239-243, October.
(http://www.sciencedirect.com/science/article/pii/S0165176502001271)
I committed some modification to CVS so that the kpss command now
accepts a --seasonals option. As everyone knows, GTK mysteries
elude me, so you'll find no changes in the GUI client.
Nice. This will be in the GUI in tomorrow's CVS.
Allin
9:02 a.m.
Am 10.07.2011 06:03, schrieb Allin Cottrell:
On Sat, 9 Jul 2011, Sven Schreiber wrote:
> And secondly, when applying omission restrictions to OLS the message
> about the information criteria seems to be wrong -- this could be a
> translation error, I will check that, but mentioning it here just in case.
The English message is correct, I'm not sure about translations.
Example:
open data4-10
ols 1 0 2 3 4 5 6
omit 5 6
The omit command produces:
Test statistic: F(2, 45) = 0.66365, with p-value = 0.519935
Of the 3 model selection statistics, 3 have improved.
ah ok, it's the German translation only, then -- it says "they have
risen" instead of "improved". I will correct that.
-sven
2:42 p.m.
New subject: Scalability problem
Hi,
I am facing a scalability problem when working with matrix elements.
Below is a fragment of the script I am working with.
</script>
nulldata 1000
scalar nobs_full = $nobs
scalar nmc = 400
...
# generate a matrix of zeros, with rows = number of obs, cols = number
of Monte Carlo runs
matrix M = zeros(nobs_full, nmc)
# outer loop for operations on rows (actually, series of data)
loop for j=1..nmc --progressive --quiet
# series-wise operations go here
...
genr y_new = constant + 0.5 * x1 + 0.5 * x2 # an example
...
#inner loop for operations on elements of matrix
loop for i=2..nobs_full --progressive --quiet
# element-wise operations go here
...
M[i,j] += exp(y_new[i]) * M[i-1,j] # an example
...
endloop
endloop
</script>
The amount of calculation is proportionate to matrix size (generate
series and perform element-wise operations), no regressions, no matrix
manipulations. I did some quick tests and here are the results:
* Create a matrix 1000x20, run 1000 iterations (inner loop) time 20
iterations (outer loop). Time: 7 seconds.
* Matrix 1000x40, 1000 iterations by 40 iterations. Time:33 seconds.
* Matrix 1000x100, 1000 iterations by 100 iterations. Time: 4 minutes 21
seconds.
It looks like the problem is not in the loops, but in the way gretl
handles matrices, because:
* Matrix 1000x40, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 15 seconds.
* Matrix 1000x60, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 24 seconds.
* Matrix 1000x100, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 41 second.
Actually, I was planning to test a matrix of size 1000x400, but it would
have taken too much time.
By the way, I found no way to forcibly terminate a running script
(self-compiled version 1.9.5 running on Ubuntu Linux). It would be nice
to have a button (or hotkey, or something similar) for this purpose.
Regards,
Vitalie CIUBOTARU
2:58 p.m.
New subject: Scalability problem
Am 10.07.2011 16:42, schrieb Vitalie Ciubotaru:
Hi,
I am facing a scalability problem when working with matrix elements.
Below is a fragment of the script I am working with.
</script>
nulldata 1000
scalar nobs_full = $nobs
scalar nmc = 400
...
# generate a matrix of zeros, with rows = number of obs, cols = number
of Monte Carlo runs
matrix M = zeros(nobs_full, nmc)
# outer loop for operations on rows (actually, series of data)
loop for j=1..nmc --progressive --quiet
# series-wise operations go here
...
genr y_new = constant + 0.5 * x1 + 0.5 * x2 # an example
...
#inner loop for operations on elements of matrix
loop for i=2..nobs_full --progressive --quiet
# element-wise operations go here
...
M[i,j] += exp(y_new[i]) * M[i-1,j] # an example
...
endloop
endloop
</script>
The amount of calculation is proportionate to matrix size (generate
series and perform element-wise operations), no regressions, no matrix
manipulations. I did some quick tests and here are the results:
* Create a matrix 1000x20, run 1000 iterations (inner loop) time 20
iterations (outer loop). Time: 7 seconds.
* Matrix 1000x40, 1000 iterations by 40 iterations. Time:33 seconds.
* Matrix 1000x100, 1000 iterations by 100 iterations. Time: 4 minutes 21
seconds.
It looks like the problem is not in the loops, but in the way gretl
handles matrices, because:
* Matrix 1000x40, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 15 seconds.
* Matrix 1000x60, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 24 seconds.
* Matrix 1000x100, 1000 iterations by 20 iterations (affecting only the
first 20 columns of the matrix). Time: 41 second.
Actually, I was planning to test a matrix of size 1000x400, but it would
have taken too much time.
I'm not sure I understand your point (but I admit I haven't looked very
carefully). As a first reaction, I would not always expect an operation
to take (only) 10 times longer when the size is 10 times bigger. For
example, maybe the latency and speed differences of various CPU caches
and RAM could be a factor. Your numbers do not look totally weird in the
sense of necessarily indicating a bug. But maybe I'm missing the point
(as I said).
cheers,
sven
6:05 p.m.
New subject: Scalability problem
On Sun, 10 Jul 2011, Sven Schreiber wrote:
Am 10.07.2011 16:42, schrieb Vitalie Ciubotaru:
>
> I am facing a scalability problem when working with matrix
> elements [...]
I'm not sure I understand your point (but I admit I haven't looked very
carefully). As a first reaction, I would not always expect an operation
to take (only) 10 times longer when the size is 10 times bigger. For
example, maybe the latency and speed differences of various CPU caches
and RAM could be a factor.
Vitalie might like to take a look at
http://ricardo.ecn.wfu.edu/~cottrell/tmp/gretl_speed.html
Allin Cottrell
10:09 p.m.
New subject: Scalability problem
On Sun, 10 Jul 2011, Vitalie Ciubotaru wrote:
Hi,
I am facing a scalability problem when working with matrix elements.
Below is a fragment of the script I am working with.
I have the feeling there's some key detail missing from your example.
Could you send me your complete script, please?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
4919
days inactive
4921
days old
9 comments
4 participants
participants (4)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Vitalie Ciubotaru