1:56 p.m.
Hi all,
I am currently working on a rather large cross-sectional data set.
Overall I have data comprising around half a Million individuals, about
225000 households and 26 countries.
I tried to merge the different datasets, after dropping irrelevant
variables before. But merging households (identified by HID) and
countries (country) by "join" really takes a lot of time. Actually,
joining one variable takes 25 minutes on my linux machine (2.6GHz). If I
use STATA it may take a minute or so.
Why does it take that long here? I am surprised because typically gretl
operates pretty fast.
Also, is there a way to merge all cross-sectional variables from the
"outside" dataset with the "inner" one by a single command? At the
moment one has to specify a join command for each variable separately,
right? I am just asking out of curiosity as I am fine with the way it is
currently implemented.
Artur
2:23 p.m.
On Fri, 13 Sep 2013, Artur T. wrote:
Hi all,
I am currently working on a rather large cross-sectional data set.
Overall I have data comprising around half a Million individuals, about
225000 households and 26 countries.
I tried to merge the different datasets, after dropping irrelevant
variables before. But merging households (identified by HID) and
countries (country) by "join" really takes a lot of time. Actually,
joining one variable takes 25 minutes on my linux machine (2.6GHz). If I
use STATA it may take a minute or so.
Why does it take that long here? I am surprised because typically gretl
operates pretty fast.
I find this very surprising. "join" is, normally, quite fast. Which
options are you using?
Also, is there a way to merge all cross-sectional variables from the
"outside" dataset with the "inner" one by a single command? At the
moment one has to specify a join command for each variable separately,
right? I am just asking out of curiosity as I am fine with the way it is
currently implemented.
No, that's by design. However, you can use a foreach loop as in
<hansl>
loop foreach i foo bar baz
join outer.csv $i <... your options...>
end loop
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
2:41 p.m.
Am 13.09.2013 16:23, schrieb Riccardo (Jack) Lucchetti:
On Fri, 13 Sep 2013, Artur T. wrote:
> Hi all,
>
> I am currently working on a rather large cross-sectional data set.
> Overall I have data comprising around half a Million individuals, about
> 225000 households and 26 countries.
>
> I tried to merge the different datasets, after dropping irrelevant
> variables before. But merging households (identified by HID) and
> countries (country) by "join" really takes a lot of time. Actually,
> joining one variable takes 25 minutes on my linux machine (2.6GHz). If I
> use STATA it may take a minute or so.
>
> Why does it take that long here? I am surprised because typically gretl
> operates pretty fast.
I find this very surprising. "join" is, normally, quite fast. Which
options are you using?
The command I use is quiet standard I guess:
<hansl>
join "(a)WD/hfile.csv" hhgr --ikey=country,hid
</hansl>
> Also, is there a way to merge all cross-sectional variables from the
> "outside" dataset with the "inner" one by a single command? At
the
> moment one has to specify a join command for each variable separately,
> right? I am just asking out of curiosity as I am fine with the way it is
> currently implemented.
No, that's by design. However, you can use a foreach loop as in
<hansl>
loop foreach i foo bar baz
join outer.csv $i <... your options...>
end loop
</hansl>
That's also the way I've used it.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
Artur
2:57 p.m.
On Fri, 13 Sep 2013, Artur T. wrote:
I am currently working on a rather large cross-sectional data set.
Overall I have data comprising around half a Million individuals, about
225000 households and 26 countries.
The command I use is quiet standard I guess:
<hansl>
join "(a)WD/hfile.csv" hhgr --ikey=country,hid
</hansl>
[ and join takes a long time ]
Can you tell us the dimensions of the two datasets -- the "left-hand" one
that you're joining onto and the "right-hand" one that's the source for
join? How many rows on the left, and how many rows and columns on the
right?
I'd like to try to simulate this and see what's going on.
Allin Cottrell
3:25 p.m.
Am 13.09.2013 16:57, schrieb Allin Cottrell:
On Fri, 13 Sep 2013, Artur T. wrote:
> I am currently working on a rather large cross-sectional data set.
> Overall I have data comprising around half a Million individuals, about
> 225000 households and 26 countries.
> The command I use is quiet standard I guess:
> <hansl>
> join "(a)WD/hfile.csv" hhgr --ikey=country,hid
> </hansl>
[ and join takes a long time ]
Can you tell us the dimensions of the two datasets -- the "left-hand" one
that you're joining onto and the "right-hand" one that's the source for
join? How many rows on the left, and how many rows and columns on the
right?
I'd like to try to simulate this and see what's going on.
The dimensions are as follows:
LH:
rows(country) = 577049
rows(hid) = 577049
RH:
rows(country) = 228691
rows(hid) = 228691
rows(hhgr) = 228691
Allin Cottrell
Artur
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
4:47 p.m.
The following script will generate two testfiles whose size depends on the
two parameters ncountries and mean_n_hh (mean number of people per
household). In order to get nearly the same size as your real data, you
could set ncountries to 30 and mean_n_hh to 7500 (roughly). Then, a "join"
will be performed and the time taken.
On my pc this takes about half a second with mean_n_hh=200, nearly a
minute with mean_n_hh=4000 and about 8 minutes with mean_n_hh=10000. From
some experimenting, it would seem that time is approximately quadratic; I
suppose we could try something to make it less convex (although I suspect
it won't be easy to make it linear).
<hansl>
set echo off
set messages off
set seed 123456
ncountries = 30
mean_n_hh = 10000
n = 0
# generate the outer dataset
printf "generating outer file\n"
outfile "outer.csv" --write
printf "cntry, hid, x\n"
loop i=1..ncountries --quiet
nind = ceil(randgen1(z,mean_n_hh,10))
n += nind
loop j=1..nind --quiet
printf "%d,%d,%12.5f\n", i, j, randgen1(z,0,1)
endloop
end loop
outfile "outer.csv" --close
open outer.csv --quiet --preserve
# generate the inner dataset
printf "generating inner file\n"
outfile "inner.csv" --write
printf "hid, iid, cntry, y\n"
loop i=1..$nobs --quiet
nh = randgen1(i,1,4)
loop j=1..nh --quiet
printf "%d,%d,%d,%12.5f\n", hid[i], j, cntry[i], randgen1(z,0,1)
endloop
end loop
outfile "inner.csv" --close
# do the join
open inner.csv --preserve
printf "performing join\n"
set stopwatch
join outer.csv x --ikey=hid,cntry
printf "individuals = %d (%d countries, %d households); time = %g
seconds\n", \
$nobs, ncountries, n, $stopwatch
smpl 1 30
print -o
smpl full
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:34 p.m.
Am 13.09.2013 18:47, schrieb Riccardo (Jack) Lucchetti:
The following script will generate two testfiles whose size depends on
the two parameters ncountries and mean_n_hh (mean number of people per
household). In order to get nearly the same size as your real data, you
could set ncountries to 30 and mean_n_hh to 7500 (roughly). Then, a
"join" will be performed and the time taken.
On my pc this takes about half a second with mean_n_hh=200, nearly a
minute with mean_n_hh=4000 and about 8 minutes with mean_n_hh=10000.
From some experimenting, it would seem that time is approximately
quadratic; I suppose we could try something to make it less convex
(although I suspect it won't be easy to make it linear).
The "mean_n_hh=10000" case takes around 20 min. here. But interestingly,
I ran the following on STATA 11 using this "10000" case:
<STATA>
insheet using "outer.csv", clear
sort cntry hid
save "Z:\home\artur\gretl\outer.dta", replace
insheet using "inner.csv", clear
merge cntry hid using "outer.dta" /// Didn't work with cvs
</STATA>
On STATA it only takes about 3 seconds or so.
Artur
5:44 p.m.
On Fri, 13 Sep 2013, Artur T. wrote:
Am 13.09.2013 18:47, schrieb Riccardo (Jack) Lucchetti:
>
> The following script will generate two testfiles whose size depends on
> the two parameters ncountries and mean_n_hh (mean number of people per
> household). In order to get nearly the same size as your real data, you
> could set ncountries to 30 and mean_n_hh to 7500 (roughly). Then, a
> "join" will be performed and the time taken.
>
> On my pc this takes about half a second with mean_n_hh=200, nearly a
> minute with mean_n_hh=4000 and about 8 minutes with mean_n_hh=10000.
> From some experimenting, it would seem that time is approximately
> quadratic; I suppose we could try something to make it less convex
> (although I suspect it won't be easy to make it linear).
>
The "mean_n_hh=10000" case takes around 20 min. here. But interestingly,
I ran the following on STATA 11 using this "10000" case:
<STATA>
insheet using "outer.csv", clear
sort cntry hid
save "Z:\home\artur\gretl\outer.dta", replace
insheet using "inner.csv", clear
merge cntry hid using "outer.dta" /// Didn't work with cvs
</STATA>
On STATA it only takes about 3 seconds or so.
Yeah. As Jack said it seems quadratic and that should not be the case. I'm
working on it.
Allin
7:44 p.m.
On Fri, 13 Sep 2013, Riccardo (Jack) Lucchetti wrote:
From some experimenting, it would seem that time is approximately
quadratic; I suppose we could try something to make it less convex [...]
I've committed a change to CVS which should help a lot with the speed for
big data. But it may be a bit rough around the edges; I (or others) need
to do some more testing to make sure I haven't broken anything.
Allin
4:37 p.m.
Thank you for working on it. I'll let you know if I find some bugs or so.
Artur
Am 13.09.2013 21:44, schrieb Allin Cottrell:
On Fri, 13 Sep 2013, Riccardo (Jack) Lucchetti wrote:
> From some experimenting, it would seem that time is approximately
> quadratic; I suppose we could try something to make it less convex [...]
I've committed a change to CVS which should help a lot with the speed for
big data. But it may be a bit rough around the edges; I (or others) need
to do some more testing to make sure I haven't broken anything.
Allin
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
4:50 p.m.
I just had an idea. As I am not a programmer, I do not know how
tricky/difficult such things are to program. But if one could implement
a multicore support for the join function, more than one variable could
be read in simultaneously which speeds up the process. Just an idea --
maybe worth thinking about it for future gretl projects.
Artur
Am 14.09.2013 18:37, schrieb Artur T.:
Thank you for working on it. I'll let you know if I find some
bugs or so.
Artur
Am 13.09.2013 21:44, schrieb Allin Cottrell:
> On Fri, 13 Sep 2013, Riccardo (Jack) Lucchetti wrote:
>
>> From some experimenting, it would seem that time is approximately
>> quadratic; I suppose we could try something to make it less convex [...]
>
> I've committed a change to CVS which should help a lot with the speed for
> big data. But it may be a bit rough around the edges; I (or others) need
> to do some more testing to make sure I haven't broken anything.
>
> Allin
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-users
>
11:52 p.m.
On Sat, 14 Sep 2013, Artur T. wrote:
I just had an idea. As I am not a programmer, I do not know how
tricky/difficult such things are to program. But if one could implement
a multicore support for the join function, more than one variable could
be read in simultaneously which speeds up the process.
Worth thinking about, but paralellizing join would be quite
complicated.
In the meantime, I think that you should find that the speed
improvement for join in current CSV is very substantial and makes it
feasible to use join in a loop for multiple series (even with big
data) without taking forever.
Allin
9:53 a.m.
Am 15.09.2013 01:52, schrieb Allin Cottrell:
On Sat, 14 Sep 2013, Artur T. wrote:
> I just had an idea. As I am not a programmer, I do not know how
> tricky/difficult such things are to program. But if one could implement
> a multicore support for the join function, more than one variable could
> be read in simultaneously which speeds up the process.
Worth thinking about, but paralellizing join would be quite
complicated.
In the meantime, I think that you should find that the speed
improvement for join in current CSV is very substantial and makes it
feasible to use join in a loop for multiple series (even with big
data) without taking forever.
Mmmhh, I couldn't figure out any substantial
speed improvement on my old
PC here. But I did some testing on more modern machines, and actually it
seems to works quite reasonable there. I guess my machine is just too
slow to expect some faster processing :-)
Allin
Artur
3:03 p.m.
Am 22.09.2013 11:53, schrieb Artur T.:
Am 15.09.2013 01:52, schrieb Allin Cottrell:
> On Sat, 14 Sep 2013, Artur T. wrote:
>
>> I just had an idea. As I am not a programmer, I do not know how
>> tricky/difficult such things are to program. But if one could implement
>> a multicore support for the join function, more than one variable could
>> be read in simultaneously which speeds up the process.
>
> Worth thinking about, but paralellizing join would be quite
> complicated.
>
> In the meantime, I think that you should find that the speed
> improvement for join in current CSV is very substantial and makes it
> feasible to use join in a loop for multiple series (even with big
> data) without taking forever.
Mmmhh, I couldn't figure out any substantial speed improvement on my old
PC here. But I did some testing on more modern machines, and actually it
seems to works quite reasonable there. I guess my machine is just too
slow to expect some faster processing :-)
Well, there is the Stata benchmark you mentioned which is a natural
competitor. I'd say if your machine is fast enough to do it with Stata
the goal should be that it also works reasonably well with gretl. So
how's that comparison now after the accelerations in gretl?
cheers,
sven
5:41 p.m.
Based on the code Jack provided before, it takes about 20 minutes to
join the outer.csv file in the case of mean_n_hh = 10000 on my machine.
I added some lines using R's merge function for a comparison (added to
Jack's original code). It takes only 29 seconds to merge the data files
here (with starting R out of gretl!). On STATA the merge process takes
about 10 seconds only.
Thus, the differences are still very significant.
Well, there is the Stata benchmark you mentioned which is a natural
competitor. I'd say if your machine is fast enough to do it with Stata
the goal should be that it also works reasonably well with gretl. So
how's that comparison now after the accelerations in gretl?
cheers,
sven
Artur
<hansl>
set echo off
set messages off
set seed 123456
ncountries = 30
mean_n_hh = 10000
n = 0
# generate the outer dataset
printf "generating outer file\n"
outfile "outer.csv" --write
printf "cntry, hid, x\n"
loop i=1..ncountries --quiet
nind = ceil(randgen1(z,mean_n_hh,10))
n += nind
loop j=1..nind --quiet
printf "%d,%d,%12.5f\n", i, j, randgen1(z,0,1)
endloop
end loop
outfile "outer.csv" --close
open outer.csv --quiet --preserve
# generate the inner dataset
printf "generating inner file\n"
outfile "inner.csv" --write
printf "hid, iid, cntry, y\n"
loop i=1..$nobs --quiet
nh = randgen1(i,1,4)
loop j=1..nh --quiet
printf "%d,%d,%d,%12.5f\n", hid[i], j, cntry[i], randgen1(z,0,1)
endloop
end loop
outfile "inner.csv" --close
# do the join
open inner.csv --preserve
printf "performing join\n"
set stopwatch
join outer.csv x --ikey=hid,cntry
printf "individuals = %d (%d countries, %d households); time = %g
seconds\n", \
$nobs, ncountries, n, $stopwatch
smpl 1 30
print -o
smpl full
# Do it with R
set stopwatch
foreign language=R
inner <- read.table("/home/artur/gretl/inner.csv",sep=",",
header=TRUE)
outer <- read.table("/home/artur/gretl/outer.csv",sep=",",
header=TRUE)
m = merge(inner, outer,by=c("cntry","hid"))
summary(m)
end foreign
printf "R: %.2f sec.\n", $stopwatch / 60
# Comparison of some descriptive stats
summary cntry hid iid y x
</hansl>
5:50 p.m.
Am 22.09.2013 19:41, schrieb Artur T.:
Based on the code Jack provided before, it takes about 20 minutes to
join the outer.csv file in the case of mean_n_hh = 10000 on my machine.
But wasn't the 20 minutes the result before anything was changed in
gretl (cvs version)? Please clarify.
-sven
5:53 p.m.
Am 22.09.2013 19:50, schrieb Sven Schreiber:
Am 22.09.2013 19:41, schrieb Artur T.:
> Based on the code Jack provided before, it takes about 20 minutes to
> join the outer.csv file in the case of mean_n_hh = 10000 on my machine.
But wasn't the 20 minutes the result before anything was changed in
gretl (cvs version)? Please clarify.
-sven
Concretely, it takes about 1 minute less after Allin's code improvement
now. Indeed this is not really a breakthrough if one compares the
performance of the two other programs.
Artur
6:17 p.m.
On Sun, 22 Sep 2013, Artur T. wrote:
> This is _very_ strange. Are you sure you're using the current
CVS
> version (or a corresponding snapshot)?
>
> -------------------------------------------------------
> Riccardo (Jack) Lucchetti
Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
issue? I am using an AMD CPU -- maybe some of the important processor
operations just work much slower on this machine.
Now, this is even more strange. Are you using a snapshot or compiling
from source? I'm asking because I'm beginning to think that something
could have gone wrong when updating your source code and you are indeed
using a 22-09 build, but from an older codebase.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:38 p.m.
On Sun, 22 Sep 2013, Riccardo (Jack) Lucchetti wrote:
On Sun, 22 Sep 2013, Artur T. wrote:
>> This is _very_ strange. Are you sure you're using the current CVS
>> version (or a corresponding snapshot)?
>>
>> -------------------------------------------------------
>> Riccardo (Jack) Lucchetti
>
> Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
> issue? I am using an AMD CPU -- maybe some of the important processor
> operations just work much slower on this machine.
Now, this is even more strange. Are you using a snapshot or compiling
from source? I'm asking because I'm beginning to think that something
could have gone wrong when updating your source code and you are indeed
using a 22-09 build, but from an older codebase.
Artur, I have the same doubt. I just tried Jack's test script with
mean_n_hh = 10000 and here's what I get:
gretl 1.9.12 release:
individuals = 750212 (30 countries, 300007 households); time = 177.326
seconds
current CVS:
individuals = 750212 (30 countries, 300007 households); time = 0.68443
seconds
(speed-up factor: 259)
Now the CPU here is Core i7, but the recent speed-up for join is very
generic, it doesn't depend on vectorization or multi-threading. So I'd
expect a roughly comparable speed improvement (in ratio terms) on any CPU
capable of running gretl.
Allin
7:28 p.m.
Am 22.09.2013 20:38, schrieb Allin Cottrell:
On Sun, 22 Sep 2013, Riccardo (Jack) Lucchetti wrote:
> On Sun, 22 Sep 2013, Artur T. wrote:
>
>>> This is _very_ strange. Are you sure you're using the current CVS
>>> version (or a corresponding snapshot)?
>>>
>>> -------------------------------------------------------
>>> Riccardo (Jack) Lucchetti
>>
>> Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
>> issue? I am using an AMD CPU -- maybe some of the important processor
>> operations just work much slower on this machine.
>
> Now, this is even more strange. Are you using a snapshot or compiling
> from source? I'm asking because I'm beginning to think that something
> could have gone wrong when updating your source code and you are indeed
> using a 22-09 build, but from an older codebase.
Artur, I have the same doubt. I just tried Jack's test script with
mean_n_hh = 10000 and here's what I get:
gretl 1.9.12 release:
individuals = 750212 (30 countries, 300007 households); time = 177.326
seconds
current CVS:
individuals = 750212 (30 countries, 300007 households); time = 0.68443
seconds
(speed-up factor: 259)
Now the CPU here is Core i7, but the recent speed-up for join is very
generic, it doesn't depend on vectorization or multi-threading. So I'd
expect a roughly comparable speed improvement (in ratio terms) on any CPU
capable of running gretl.
Allin
Yes, you were right. For some reason I missed to add "cvs update -d -P"
to the compilation command. This was my fault -- I am sorry.
The performance gain is really substantial now, compared to the former
state: Instead of 20 minutes Jack's code runs in 1.6 seconds! This is
really fast.
Thank you for this work.
Artur
7:35 p.m.
Just a note. Given this case I am wondered whether it makes more sense
to provide the "cvs date" instead of "build date" if one clicks on
the
menu item "about gretl" -- this may rule out such a confusion in future.
Artur
Am 22.09.2013 20:38, schrieb Allin Cottrell:
On Sun, 22 Sep 2013, Riccardo (Jack) Lucchetti wrote:
> On Sun, 22 Sep 2013, Artur T. wrote:
>
>>> This is _very_ strange. Are you sure you're using the current CVS
>>> version (or a corresponding snapshot)?
>>>
>>> -------------------------------------------------------
>>> Riccardo (Jack) Lucchetti
>>
>> Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
>> issue? I am using an AMD CPU -- maybe some of the important processor
>> operations just work much slower on this machine.
>
> Now, this is even more strange. Are you using a snapshot or compiling
> from source? I'm asking because I'm beginning to think that something
> could have gone wrong when updating your source code and you are indeed
> using a 22-09 build, but from an older codebase.
Artur, I have the same doubt. I just tried Jack's test script with
mean_n_hh = 10000 and here's what I get:
gretl 1.9.12 release:
individuals = 750212 (30 countries, 300007 households); time = 177.326
seconds
current CVS:
individuals = 750212 (30 countries, 300007 households); time = 0.68443
seconds
(speed-up factor: 259)
Now the CPU here is Core i7, but the recent speed-up for join is very
generic, it doesn't depend on vectorization or multi-threading. So I'd
expect a roughly comparable speed improvement (in ratio terms) on any CPU
capable of running gretl.
Allin
Yes, you were right. For some reason I missed to add "cvs update -d -P"
to the compilation command. This was my fault -- I am sorry.
The performance gain is really substantial now, compared to the former
state: Instead of 20 minutes Jack's code runs in 1.6 seconds! This is
really fast.
Thank you for this work.
Artur
10:10 p.m.
On Sun, 22 Sep 2013, Artur T. wrote:
Just a note. Given this case I am wondered whether it makes more
sense
to provide the "cvs date" instead of "build date" if one clicks on
the
menu item "about gretl" -- this may rule out such a confusion in future.
Nice idea, but in this context "cvs date" would have to mean (1) the
date on which a "cvs update" was last done in the local source tree,
or possibly (2) the modification date of the most recently modified
file in the local source tree (though that could give a false result
if someone were to edit their copy without committing the change
right away).
I'm afraid it's not a practical possibility for gretl to track
either of these things.
Allin
10:20 p.m.
Ok, I see your point. I guess that it is a less important issue since typically it should
be the case that the build date coincides with the cvs date if one does not forget to
update the source before compilation :-)
Artur
Allin Cottrell <cottrell(a)wfu.edu> schrieb:
On Sun, 22 Sep 2013, Artur T. wrote:
> Just a note. Given this case I am wondered whether it makes more
sense
> to provide the "cvs date" instead of "build date" if one clicks
on
the
> menu item "about gretl" -- this may rule out such a confusion in
future.
Nice idea, but in this context "cvs date" would have to mean (1) the
date on which a "cvs update" was last done in the local source tree,
or possibly (2) the modification date of the most recently modified
file in the local source tree (though that could give a false result
if someone were to edit their copy without committing the change
right away).
I'm afraid it's not a practical possibility for gretl to track
either of these things.
Allin
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
6 p.m.
On Sun, 22 Sep 2013, Artur T. wrote:
Based on the code Jack provided before, it takes about 20 minutes to
join the outer.csv file in the case of mean_n_hh = 10000 on my machine.
This is _very_ strange. Are you sure you're using the current CVS version
(or a corresponding snapshot)?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:07 p.m.
Am 22.09.2013 20:00, schrieb Riccardo (Jack) Lucchetti:
On Sun, 22 Sep 2013, Artur T. wrote:
> Based on the code Jack provided before, it takes about 20 minutes to
> join the outer.csv file in the case of mean_n_hh = 10000 on my machine.
This is _very_ strange. Are you sure you're using the current CVS
version (or a corresponding snapshot)?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Yes, the build date is 2013-09-22. I am also puzzled. Could it be an CPU
issue? I am using an AMD CPU -- maybe some of the important processor
operations just work much slower on this machine.
Artur
4113
days inactive
4122
days old
24 comments
4 participants
participants (4)
-
Allin Cottrell -
Artur T. -
Riccardo (Jack) Lucchetti -
Sven Schreiber