4:29 p.m.
Hi,
maybe this is of interest to some of you: "Which programming language is
best for economic research: Julia, Matlab, Python or R?"
https://voxeu.org/article/which-programming-language-best-economic-resear...
It's a pitty that people did not consider the gretl project. I am
wondering whether "we" may re-run the same experiments for gretl for
getting an idea how gretl would position.
https://www.modelsandrisk.org/appendix/speed_2020/
Artur
6:29 p.m.
Am 22.08.2020 um 18:29 schrieb Artur Tarassow:
maybe this is of interest to some of you: "Which programming
language is
best for economic research: Julia, Matlab, Python or R?"
https://voxeu.org/article/which-programming-language-best-economic-resear...
It's a strange article in some places: They claim that Python has clumsy
syntax for matrix multiplication, but they seem to have missed that the
@ operator was introduced just for that in Python 3.5 two years ago or
so. This is especially strange since that post is supposed to be an
update to the current state of affairs.
It's a pitty that people did not consider the gretl project. I am
wondering whether "we" may re-run the same experiments for gretl for
getting an idea how gretl would position.
https://www.modelsandrisk.org/appendix/speed_2020/
Having comparisons is of course good, but personally I don't think that
gretl/hansl really wants to be a competitor for the "best programming
language to do economic research" (in general). In my view the scope is
much more focussed on econometrics.
I'm a little afraid that otherwise there might be misunderstandings and
disappointments. But of course we know that in some areas gretl is
extremely competitive.
cheers
sven
7:45 p.m.
On Sat, 22 Aug 2020 at 19:29, Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 22.08.2020 um 18:29 schrieb Artur Tarassow:
> maybe this is of interest to some of you: "Which programming language is
> best for economic research: Julia, Matlab, Python or R?"
>
https://voxeu.org/article/which-programming-language-best-economic-resear...
>
It's a strange article in some places: They claim that Python has clumsy
syntax for matrix multiplication, but they seem to have missed that the
@ operator was introduced just for that in Python 3.5 two years ago or
so. This is especially strange since that post is supposed to be an
update to the current state of affairs.
There are several other candidate packages that are strong programming
languages
that are missing from the review e.g.
1. GAUSS
2. Scilab (and the very underrated Grocer econometrics package)
3. Ox
The commercial packages RATS and Stata have both GUI and a command language
similar to gretl. I am sure that other users could add other packages .
>
> It's a pitty that people did not consider the gretl project. I am
> wondering whether "we" may re-run the same experiments for gretl for
> getting an idea how gretl would position.
> https://www.modelsandrisk.org/appendix/speed_2020/
Having comparisons is of course good, but personally I don't think that
gretl/hansl really wants to be a competitor for the "best programming
language to do economic research" (in general). In my view the scope is
much more focussed on econometrics.
I'm a little afraid that otherwise there might be misunderstandings and
disappointments. But of course we know that in some areas gretl is
extremely competitive.
I have recommended gretl to users who were required to use stata or eviews
and
feedback as a second package. Such users reported that results
obtained using gretl were easier to understand. I would be very reluctant
to use R, Julia, Python, in introductory or intermediate econometrics
courses. I might recommend Matlab in an intermediate course. The process
of learning Matlab often helps with the understanding of the use of linear
algebra in econometrics.
Where gretl excels is in its ease of use, great presentation of output,
good graphics, ability to output to WP or Latex, and good manuals. It is
econometrics for econometricians (and economists). If you do want to do
comparisons it should be with packages such as RATS or Stata and you will
come out well. I have heard gretl compared to EVIEWS but replication
problems with EVIEWS (unless one uses the completely separate EVIEWS
command line) are serious enough, in my opinion, to rule EVIEWS out of
contention.
John C Frain
3 Aranleigh Park
Rathfarnham
Dublin 14
Ireland
www.tcd.ie/Economics/staff/frainj/home.html
mailto:frainj@tcd.ie
mailto:frainj@gmail.com
5:29 p.m.
On Sat, 22 Aug 2020, Artur Tarassow wrote:
Hi,
maybe this is of interest to some of you: "Which programming language is best
for economic research: Julia, Matlab, Python or R?"
https://voxeu.org/article/which-programming-language-best-economic-resear...
It's a pitty that people did not consider the gretl project. I am wondering
whether "we" may re-run the same experiments for gretl for getting an idea
how gretl would position.
https://www.modelsandrisk.org/appendix/speed_2020/
I think we should prepare hansl version of the little code snippets that
are on the webpage you linked. This would give us at least the perception
of where we stand. Then, we may perhaps tell Agiuirre & Danielsson that
hansl code is available.
Federico Giri adapted the Matlab RBC benchmark code by JFV to hansl
(Federico delivered a presentation about this back at the Berlin
conference), we sent it to them and it's now listed at
https://github.com/jesusfv/Comparison-Programming-Languages-Economics
-------------------------------------------------------
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:40 p.m.
On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
> It's a pitty that people did not consider the gretl project.
I am wondering
> whether "we" may re-run the same experiments for gretl for getting an idea
> how gretl would position.
> https://www.modelsandrisk.org/appendix/speed_2020/
I think we should prepare hansl version of the little code snippets that are
on the webpage you linked.
Sorry for replying to myself: I now see that one of the tests is based on
reading a gzipped csv file. At present, I don't think we can do such a
thing, although it shouldn't be difficult to add IMO. Would it be
worthwhile?
-------------------------------------------------------
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:50 p.m.
Am 29.08.2020 um 19:40 schrieb Riccardo (Jack) Lucchetti:
On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
>> It's a pitty that people did not consider the gretl project. I am
>> wondering whether "we" may re-run the same experiments for gretl for
>> getting an idea how gretl would position.
>> https://www.modelsandrisk.org/appendix/speed_2020/
>
> I think we should prepare hansl version of the little code snippets
> that are on the webpage you linked.
Sorry for replying to myself: I now see that one of the tests is based
on reading a gzipped csv file. At present, I don't think we can do such
a thing, although it shouldn't be difficult to add IMO. Would it be
worthwhile?
I guess for the "open" command the standard reaction in the past would
have been: why not use any of the many free third-party tools to unzip
the file first?
Not denying that it would be a "nice to have", as always.
But perhaps for "join" it could be a sensible option?
cheers
sven
6:06 p.m.
Am 29.08.20 um 19:50 schrieb Sven Schreiber:
Am 29.08.2020 um 19:40 schrieb Riccardo (Jack) Lucchetti:
> On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
>
>>> It's a pitty that people did not consider the gretl project. I am
>>> wondering whether "we" may re-run the same experiments for gretl
for
>>> getting an idea how gretl would position.
>>> https://www.modelsandrisk.org/appendix/speed_2020/
>>
>> I think we should prepare hansl version of the little code snippets
>> that are on the webpage you linked.
>
> Sorry for replying to myself: I now see that one of the tests is based
> on reading a gzipped csv file. At present, I don't think we can do such
> a thing, although it shouldn't be difficult to add IMO. Would it be
> worthwhile?
I guess for the "open" command the standard reaction in the past would
have been: why not use any of the many free third-party tools to unzip
the file first?
Not denying that it would be a "nice to have", as always.
But perhaps for "join" it could be a sensible option?
Some while ago (half a year?) I asked for this feature. I had a use-case
at this time with many (>100) csv.gz files which I wanted to join.
Unzipping "outside" the gretl script then required a separate
shell-script before doing loading things to gretl. The "csv.gz" format
is quite standard when working with large data sets (for instance Spark
data frames can be stored as csv.gz).
As gretl does not support wide-spread binary formats such as "pickle
files" or the "Parquet" format, being able to read/ write csv.gz is
definitely useful.
By the way, when I wrote a shell-script half a year ago I've found this
very useful and reliable tool called "pigz"
(https://linux.die.net/man/1/pigz) for parallel (de-)compression.
Artur
9:03 p.m.
On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
>> It's a pitty that people did not consider the gretl project. I am
>> wondering whether "we" may re-run the same experiments for gretl for
>> getting an idea how gretl would position.
>> https://www.modelsandrisk.org/appendix/speed_2020/
>
> I think we should prepare hansl version of the little code snippets that
> are on the webpage you linked.
Sorry for replying to myself: I now see that one of the tests is based on
reading a gzipped csv file. At present, I don't think we can do such a thing,
although it shouldn't be difficult to add IMO. Would it be worthwhile?
Maybe so. A bit of a pain to revise all FILE-related function calls
in csvdata.c to use the gzFile API, but certainly feasible.
Allin
6:32 p.m.
On Sat, 29 Aug 2020, Allin Cottrell wrote:
On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
> On Sat, 29 Aug 2020, Riccardo (Jack) Lucchetti wrote:
>
>>> It's a pitty that people did not consider the gretl project. I am
>>> wondering whether "we" may re-run the same experiments for gretl
for
>>> getting an idea how gretl would position.
>>> https://www.modelsandrisk.org/appendix/speed_2020/
>>
>> I think we should prepare hansl version of the little code snippets that
>> are on the webpage you linked.
>
> Sorry for replying to myself: I now see that one of the tests is based on
> reading a gzipped csv file. At present, I don't think we can do such a
> thing, although it shouldn't be difficult to add IMO. Would it be
> worthwhile?
Maybe so. A bit of a pain to revise all FILE-related function calls in
csvdata.c to use the gzFile API, but certainly feasible.
There's now a csv_gz branch in git, with support for reading
*.csv.gz, and also writing gzipped CSV if the output file has
extension .csv.gz. On the writing side I guess we need to decide if
the --gzipped option should be supported for CSV, and if so what
exactly to do with the filename: add ".gz" is it's not already
there?
I haven't made the changes in master at this point just in case
any problem emerges with reading non-gzipped CSV (though I think
we're OK in that regard).
Allin
1335
days inactive
1343
days old
8 comments
5 participants
participants (5)
-
Allin Cottrell -
Artur Tarassow -
John C Frain -
Riccardo (Jack) Lucchetti -
Sven Schreiber