6:38 a.m.
Folks,
allow me to link a short and interesting read:
http://seanjtaylor.com/post/39573264781/the-statistics-software-signal
In short, this guy characterises software users of several math/stat
packages. I just have a few observations, on which I'd like to hear as
many opinions as possible:
1) We're not on the list. As I've been saying many times over the years,
gretl being listed as one of the mainstream alternatives must be one of
our priorites and we need to think hard on how to achieve greater and
greater visibility. We've come a long way since 2009
(http://ideas.repec.org/h/ehu/ehucha/01-03.html), but in the average guy's
percetption, we still are a minor player compared (say) to Stata. For
example, one of the thigs we need most badly is, IMO, the Hansl manual.
2) If we were on the list, what kind of comments would you expect to see?
-------------------------------------------------------
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
-------------------------------------------------------
7:43 a.m.
Gretl will not get the visibility with Hansl. Sure Hansl is great. One
can even argue that it is better than Stata, R, etc. but those already
have a huge share of the users, many developers, thousands of packages
etc. So this is like complaining everyone is using Windows (on the
desktop) while Linux is so great. It is the network effect, stupid!
Gretl has always had and still has the comparative advantage in the
area of easy to use, menu driven software complementary to R etc. As
can be seen from Eviews, SPSS... there is need for such programs and,
unlike programming languages, there are really no good and free
alternatives for such GUI based programs.
Unfortunately, gretl has not been doing well in improving its GUI
facilities. Sure there has been some work, most notably the tabbed
model output. However, there are many many missing features,
inconsistencies, an increasing feel of loss of intuitiveness due to
the lack of a general design direction. It is also looking
increasingly dated and convoluted. Moreover, the decision to unsupport
localized input was a big, big, big mistake. If a spreadsheet program
such as Excel, Calc, Gnumeric or Google Spread said they won't support
decimal comma inputs because that is not very useful and/or hard to
do, everyone would laugh. However, gretl decided somehow along the way
that such way would be acceptable for most users. Hah.
Anyway, if you want gretl to become more visible and popular, then you
have to see and remember its strengths, and where it needs to fit and
fill an important need in the world of scientific software. Those
areas are (1) a modern GUI based approach (supported by good
scripting) for doing modern econometric analysis, (2) excellent
localization and internationalization support, (3) a focus on teaching
econometrics at the both basic and advanced level.
Unless the above becomes a priority once again, the year of gretl is
not coming. No my friend. 'Nuff said.
Talha
On Mon, Jan 7, 2013 at 8:38 AM, Riccardo (Jack) Lucchetti
<r.lucchetti(a)univpm.it> wrote:
Folks,
allow me to link a short and interesting read:
http://seanjtaylor.com/post/39573264781/the-statistics-software-signal
In short, this guy characterises software users of several math/stat
packages. I just have a few observations, on which I'd like to hear as many
opinions as possible:
1) We're not on the list. As I've been saying many times over the years,
gretl being listed as one of the mainstream alternatives must be one of our
priorites and we need to think hard on how to achieve greater and greater
visibility. We've come a long way since 2009
(http://ideas.repec.org/h/ehu/ehucha/01-03.html), but in the average guy's
percetption, we still are a minor player compared (say) to Stata. For
example, one of the thigs we need most badly is, IMO, the Hansl manual.
2) If we were on the list, what kind of comments would you expect to see?
-------------------------------------------------------
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-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
9:17 a.m.
Gretl has always had and still has the comparative advantage in the
area of easy to use, menu driven software complementary to R etc. As
can be seen from Eviews, SPSS... there is need for such programs and,
unlike programming languages, there are really no good and free
alternatives for such GUI based programs.
Gretl?
Unfortunately, gretl has not been doing well in improving its GUI
facilities. Sure there has been some work, most notably the tabbed
model output. However, there are many many missing features,
inconsistencies, an increasing feel of loss of intuitiveness due to
the lack of a general design direction. It is also looking
increasingly dated and convoluted.
I kind of agree on this point. Even though I can always find what I am
looking for (which is a problem in OxMetrics) I find the GUI a little
unintuitive. Unfortunately a cannot really say what to change in order make
it more intuitive to me. Only, that I don't like the category "Nonlinear
models" as I think the categories should be positively defined (like the
story about the two animals of the world: Elephants and non-elephants). A
more real problem is GTK maybe. It just doesn't look good in general and in
particular not on Windows and Mac. Again, I have no idea about how to
change that as I guess it would take too much work without any
functionality gains.
Moreover, the decision to unsupport
localized input was a big, big, big mistake. If a spreadsheet program
such as Excel, Calc, Gnumeric or Google Spread said they won't support
decimal comma inputs because that is not very useful and/or hard to
do, everyone would laugh. However, gretl decided somehow along the way
that such way would be acceptable for most users. Hah.
This has been discussed before, but I think this criticism is just
mistaken. The support for decimal comma in Gretl is just as good as the
support in Excel. Also, you deliberately changed focus from statistical
packages to spreadsheets. Which statistical scripting languages support
localised inputs?
I have thought about what I think the obstacles for Gretl are in getting
more attention. The statistical functionalities in Gretl are really great.
Within my own area I think that the cointegration stuff is really great and
better than most of the commercial packages (but the unrestricted models
should still go :-)). At my department we teach SAS but faculty uses Stata
and I don't think it will change anytime soon. Maybe people like the idea
about a supporting institution (enterprise) for the software to ensure
continuity which is again a problem that is hard to deal with.
Best
Andreas
11:24 a.m.
This has been discussed before, but I think this criticism is just
mistaken.
The support for decimal comma in Gretl is just as good as the support in
Excel. Also, you deliberately changed focus from statistical packages to
spreadsheets. Which statistical scripting languages support localised
inputs?
“Let’s not kid ourselves: the most widely used piece of software for
statistics is Excel” –Ripley.
Not only that it is the most popular, but also there are many
textbooks for statistics as well as econometrics with Excel. So this
is a perfectly valid example and we do need to consider what makes
Excel, SPSS, Eviews popular if we are talking about how to make gretl
more popular.
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
2:21 p.m.
On Mon, 7 Jan 2013, Talha Yalta wrote:
> This has been discussed before, but I think this criticism is
just mistaken.
> The support for decimal comma in Gretl is just as good as the support in
> Excel. Also, you deliberately changed focus from statistical packages to
> spreadsheets. Which statistical scripting languages support localised
> inputs?
“Let’s not kid ourselves: the most widely used piece of software for
statistics is Excel” –Ripley.
Not only that it is the most popular, but also there are many
textbooks for statistics as well as econometrics with Excel. So this
is a perfectly valid example and we do need to consider what makes
Excel, SPSS, Eviews popular if we are talking about how to make gretl
more popular.
The key question here is "popular among who"? Popularity _per_se_ is not
something I personally care very much about. In my view, people who feel
ok doing statistics on Excel may very well keep doing so: even if they
adopted a modified version of gretl in which they could use their beloved
decimal comma, the project, in my not so humble opinion, would gain little
benefit, if any at all.
The reason why I would like gretl to be more widespread is because I would
like to have a larger pool of people who can give valuable contributions
to the project in terms of features. And the reason I feel this way is not
because I want to brag about the advanced stuff. It's because of what I
think the project's end goal should be.
As far as I'm concerned, the end goal is to provide a stats/econometrics
package which is (1) free; (2) advanced enough so that every conceivable
piece of applied economic research can be done by using it (at least in
principle); (3) friendly enough to be used in the widest possible range of
teaching situations. Please note: (3) would not be possible without (2):
the emphasis on math/stat functionality is a necessary condition to make
your package useable in teaching (past the undergraduate level). The
converse doesn't work.
A million users whose command of statistics and programming is near-zero
(and who, reasonably, find it odd that you can use the comma in excel but
not in gretl) are less important, to the reaching of the end goal, than a
dozen users who can find bugs and write meaningful bug reports, who follow
the recent trends in applied literature and ask the developers "could we
add this estimator/test/whatever?" or, better still, do it themselves and
upload a function package. The situation has improved over the years, but
the pool of contributors we have as of today is very small compared to,
say, the R project or even vintage stuff like RATS or TSP (yes, I'm
deliberately omitting Stata).
Sure, numbers are important, but then: can you provide any example of a
stat package which is *frendlier* than gretl is as of now?
-------------------------------------------------------
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:51 p.m.
You don't have a thousand developers (and thousands of function
packages) without that one million users. If you think that one
million is not important, then don't complain gretl is not becoming
"mainstream". Also, "a larger pool of people who can give valuable
contributions to the project in terms of features" surely includes
those people who contribute by translating and localizing. This is a
laborious effort which becomes less meaningful by those who want to
use gretl with "their beloved decimal comma", and who surprisingly
start finding out that, according to some developers' not-so-humble
opinions, gretl would gain little with their using of and
contributions to gretl.
On Mon, Jan 7, 2013 at 4:21 PM, Riccardo (Jack) Lucchetti
<r.lucchetti(a)univpm.it> wrote:
On Mon, 7 Jan 2013, Talha Yalta wrote:
>> This has been discussed before, but I think this criticism is just
>> mistaken.
>> The support for decimal comma in Gretl is just as good as the support in
>> Excel. Also, you deliberately changed focus from statistical packages to
>> spreadsheets. Which statistical scripting languages support localised
>> inputs?
>
> “Let’s not kid ourselves: the most widely used piece of software for
> statistics is Excel” –Ripley.
> Not only that it is the most popular, but also there are many
> textbooks for statistics as well as econometrics with Excel. So this
> is a perfectly valid example and we do need to consider what makes
> Excel, SPSS, Eviews popular if we are talking about how to make gretl
> more popular.
The key question here is "popular among who"? Popularity _per_se_ is not
something I personally care very much about. In my view, people who feel ok
doing statistics on Excel may very well keep doing so: even if they adopted
a modified version of gretl in which they could use their beloved decimal
comma, the project, in my not so humble opinion, would gain little
benefit, if any at all.
The reason why I would like gretl to be more widespread is because I would
like to have a larger pool of people who can give valuable contributions to
the project in terms of features. And the reason I feel this way is not
because I want to brag about the advanced stuff. It's because of what I
think the project's end goal should be.
As far as I'm concerned, the end goal is to provide a stats/econometrics
package which is (1) free; (2) advanced enough so that every conceivable
piece of applied economic research can be done by using it (at least in
principle); (3) friendly enough to be used in the widest possible range of
teaching situations. Please note: (3) would not be possible without (2): the
emphasis on math/stat functionality is a necessary condition to make your
package useable in teaching (past the undergraduate level). The converse
doesn't work.
A million users whose command of statistics and programming is near-zero
(and who, reasonably, find it odd that you can use the comma in excel but
not in gretl) are less important, to the reaching of the end goal, than a
dozen users who can find bugs and write meaningful bug reports, who follow
the recent trends in applied literature and ask the developers "could we add
this estimator/test/whatever?" or, better still, do it themselves and upload
a function package. The situation has improved over the years, but the pool
of contributors we have as of today is very small compared to, say, the R
project or even vintage stuff like RATS or TSP (yes, I'm deliberately
omitting Stata).
Sure, numbers are important, but then: can you provide any example of a stat
package which is *frendlier* than gretl is as of now?
-------------------------------------------------------
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-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
3 p.m.
On Mon, 7 Jan 2013, Talha Yalta wrote:
You don't have a thousand developers (and thousands of function
packages) without that one million users.
You have a point here. Numbers are important, but composition is important
too. Take a project like, say, gnuplot or gnumeric. Would you think
that, if their user base magically increased by 50%, the number of
contributors would automatically increase by 50%? What makes you think
that the elasticity is 1?
If you think that one
million is not important, then don't complain gretl is not becoming
"mainstream". Also, "a larger pool of people who can give valuable
contributions to the project in terms of features" surely includes
those people who contribute by translating and localizing.
This is absolutely true.
This is a laborious effort which becomes less meaningful by those who
want to use gretl with "their beloved decimal comma", and who
surprisingly start finding out that, according to some developers'
not-so-humble opinions, gretl would gain little with their using of and
contributions to gretl.
Talha, I am somewhat under the impression that you've developed a sort of
obsession with this comma thing. Could we try to bring the discussion to a
more general level?
-------------------------------------------------------
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
-------------------------------------------------------
3:28 p.m.
On 07/01/13 16:00, Riccardo (Jack) Lucchetti wrote:
Talha, I am somewhat under the impression that you've developed a sort
of obsession with this comma thing. Could we try to bring the
discussion to a more general level?
Hey, hey. Talha was citing you, Is not the obsessed an Italian boy?
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ehu.es/ignacio.diaz-emparanza/
www.ea3.ehu.es
3:34 p.m.
On Mon, 7 Jan 2013, Ignacio Diaz-Emparanza wrote:
On 07/01/13 16:00, Riccardo (Jack) Lucchetti wrote:
>
> Talha, I am somewhat under the impression that you've developed a sort of
> obsession with this comma thing. Could we try to bring the discussion to a
> more general level?
Hey, hey. Talha was citing you, Is not the obsessed an Italian boy?
It wasn't me who started it, daddy! Talha did!
-------------------------------------------------------
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:59 p.m.
2013/1/7 Riccardo (Jack) Lucchetti <r.lucchetti(a)univpm.it>
On Mon, 7 Jan 2013, Talha Yalta wrote:
This has been discussed before, but I think this criticism is just
>> mistaken.
>> The support for decimal comma in Gretl is just as good as the support in
>> Excel. Also, you deliberately changed focus from statistical packages to
>> spreadsheets. Which statistical scripting languages support localised
>> inputs?
>>
> “Let’s not kid ourselves: the most widely used piece of software for
> statistics is Excel” –Ripley.
> Not only that it is the most popular, but also there are many
> textbooks for statistics as well as econometrics with Excel. So this
> is a perfectly valid example and we do need to consider what makes
> Excel, SPSS, Eviews popular if we are talking about how to make gretl
> more popular.
>
The key question here is "popular among who"? Popularity _per_se_ is not
something I personally care very much about. In my view, people who feel ok
doing statistics on Excel may very well keep doing so: even if they adopted
a modified version of gretl in which they could use their beloved decimal
comma, the project, in my not so humble opinion, would gain little
benefit, if any at all.
The reason why I would like gretl to be more widespread is because I would
like to have a larger pool of people who can give valuable contributions to
the project in terms of features. And the reason I feel this way is not
because I want to brag about the advanced stuff. It's because of what I
think the project's end goal should be.
As far as I'm concerned, the end goal is to provide a stats/econometrics
package which is (1) free; (2) advanced enough so that every conceivable
piece of applied economic research can be done by using it (at least in
principle); (3) friendly enough to be used in the widest possible range of
teaching situations. Please note: (3) would not be possible without (2):
the emphasis on math/stat functionality is a necessary condition to make
your package useable in teaching (past the undergraduate level). The
converse doesn't work.
This is a good point to start the discussion from!
A million users whose command of statistics and programming is
near-zero
(and who, reasonably, find it odd that you can use the comma in excel but
not in gretl) are less important, to the reaching of the end goal, than a
dozen users who can find bugs and write meaningful bug reports, who follow
the recent trends in applied literature and ask the developers "could we
add this estimator/test/whatever?" or, better still, do it themselves and
upload a function package. The situation has improved over the years, but
the pool of contributors we have as of today is very small compared to,
say, the R project or even vintage stuff like RATS or TSP (yes, I'm
deliberately omitting Stata).
A great plus of RATS is not its programming language (at least from my
point of view), but its list of code contributions as well as its large
pool of procedures and replication examples. Some time ago it was discussed
here on the gretl list whether to publish replication procedures. I think
this could be an important feature to promote gretl. One could set up a
homepage where all function packages as well as replication codes are
publicly listed. Thus, if people 'google' for example the
'Breitung-Candelon test' they would say "Oh cool, that's already
implemented into a free software called gretl!"
I really doubt that making the GUI more shiny has any impact on the number
of users and contributors.
Artur
Sure, numbers are important, but then: can you provide any example of a
stat package which is *frendlier* than gretl is as of now?
-------------------------------------------------------
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-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
8:16 a.m.
On Mon, 7 Jan 2013, artur tarassow wrote:
A great plus of RATS is not its programming language (at least from
my
point of view), but its list of code contributions as well as its large
pool of procedures and replication examples. Some time ago it was discussed
here on the gretl list whether to publish replication procedures. I think
this could be an important feature to promote gretl. One could set up a
homepage where all function packages as well as replication codes are
publicly listed. Thus, if people 'google' for example the
'Breitung-Candelon test' they would say "Oh cool, that's already
implemented into a free software called gretl!"
This is a nice idea: we could use the wiki for that, in a "replication"
section. I've got a few things I could add. Anyone else?
I really doubt that making the GUI more shiny has any impact on the
number
of users and contributors.
Don't underestimate the power of bells and whistles...
-------------------------------------------------------
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
-------------------------------------------------------
11:49 p.m.
On Mon, Jan 7, 2013 at 5:24 AM, Talha Yalta <talhayalta(a)gmail.com> wrote:
> This has been discussed before, but I think this criticism is
just
mistaken.
> The support for decimal comma in Gretl is just as good as the support in
> Excel. Also, you deliberately changed focus from statistical packages to
> spreadsheets. Which statistical scripting languages support localised
> inputs?
“Let’s not kid ourselves: the most widely used piece of software for
statistics is Excel” –Ripley.
Not only that it is the most popular, but also there are many
textbooks for statistics as well as econometrics with Excel. So this
is a perfectly valid example and we do need to consider what makes
Excel, SPSS, Eviews popular if we are talking about how to make gretl
more popular.
The publisher John Wiley & Sons surveyed the users of Hill et. al.
Principles
of Econometrics for software choices. As many of you know this
is an advanced undergraduate book--though many like me use it for masters
level classes (the latter chapters in it are particularly good for this,
IMO). The vast majority of the book's users opt for Eviews (43%) followed
by Stata and Excel (about 21% each). 11% reported using gretl. SAS, R,
and SPSS all report less than 1% each. I think their sample size was
around 6000 or so.
My guess is that Excel is popular because the marginal cost of its use is
zero for most adopters. Everybody has it already and sort of knows how to
use it. Gretl's cost, though not zero, is very low. The biggest
difference is that you have to install it and learn something new to use
it. Gretl is much easier to use and more purpose specific in all other
ways, so it theoretically should have an advantage if product awareness was
that of the others. That's my take, anyway..
--
Lee Adkins
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com
7:50 a.m.
On Mon, 7 Jan 2013, Lee Adkins wrote:
The publisher John Wiley & Sons surveyed the users of Hill et.
al.
Principles of Econometrics for software choices. As many of you know this
is an advanced undergraduate book--though many like me use it for masters
level classes (the latter chapters in it are particularly good for this,
IMO). The vast majority of the book's users opt for Eviews (43%) followed
by Stata and Excel (about 21% each). 11% reported using gretl. SAS, R,
and SPSS all report less than 1% each. I think their sample size was
around 6000 or so.
These are extremely interesting figures. Frankly, gretl's share is larger
than I had expected. For a free software project, which is always burdened
by the old myth "you get what you pay for", passing the 10% mark is
vitally important, as it means that it has become a recognised player in
the field. Moreover, I have the impression that gretl's presence is even
larger in non-English speaking countries, for obvious reasons. Also, I
wouldn't have expected Eviews' dominance, particularly compared to Stata's
share, but that's another matter.
My guess is that Excel is popular because the marginal cost of its
use is
zero for most adopters. Everybody has it already and sort of knows how to
use it. Gretl's cost, though not zero, is very low. The biggest
difference is that you have to install it and learn something new to use
it. Gretl is much easier to use and more purpose specific in all other
ways, so it theoretically should have an advantage if product awareness was
that of the others. That's my take, anyway..
I repeat: excel users are the "low-end" segment of the market. I don't
mean to diss these people, but my guess is that you'll never manage to
have them switch to anything else, nor that it's particularly important
for the project to do so.
-------------------------------------------------------
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
-------------------------------------------------------
1:55 p.m.
On Mon, 7 Jan 2013, Andreas Noack Jensen wrote:
Even though I can always find what I am looking for (which is a
problem in OxMetrics) I find the GUI a little unintuitive.
Unfortunately a cannot really say what to change in order make it
more intuitive to me. Only, that I don't like the category
"Nonlinear models" as I think the categories should be positively
defined (like the story about the two animals of the world:
Elephants and non-elephants).
That's a fair point, and easy enough to fix, or at least improve.
Having a "Limited dependent variable" category in the model menu
might help?
A more real problem is GTK maybe. It just doesn't look good in
general and in particular not on Windows and Mac. Again, I have no
idea about how to change that as I guess it would take too much
work without any functionality gains.
Using a toolkit other than GTK for the GUI would be a huge amount of
work and not something I personally would undertake. But GTK 3 has a
more "modern" look, and as it matures we can consider switching for
the Windows and Mac packages. As I've mentioned before, using the
Quartz-based variant of GTK would (in principle) make gretl much
more Mac-like.
I have thought about what I think the obstacles for Gretl are in
getting
more attention. The statistical functionalities in Gretl are really great.
Within my own area I think that the cointegration stuff is really great and
better than most of the commercial packages (but the unrestricted models
should still go :-)). At my department we teach SAS but faculty uses Stata
and I don't think it will change anytime soon. Maybe people like the idea
about a supporting institution (enterprise) for the software to ensure
continuity which is again a problem that is hard to deal with.
True, we can't do the "enterprise" thing. But we could perhaps think
about a more formal release process, with more systematic and
widespread pre-testing -- and more "advertising", if we can think of
a way of doing that. Maybe do one "LTS" release per year, in which
case we could maybe reinstate automated updates for such releases.
Not sure how much this would help, but one thing I've noticed with
colleagues who use gretl in their teaching is that they and their
students tend to be using rather dated versions of gretl at most
points in time.
Allin
10:50 a.m.
As for the main topic... I fully agree with Dr. Kelly and others about
the GUI. As I have also mentioned, the GUI and the menu structure
needs some serious attention based on a modern and consistent design
direction. LaTeX output and graph pages need to work in all cases
since such are the things that make gretl so "cool" to use. Also, it
would be nice to add a few items for easily performing what applied
people do nowadays. For example, it would be nice to have Peseran's
ARDL bounds testing in addition to gretl's nice VAR, VEC, Johansen GUI
facilities.
The above are the sort of things that most people love, use, and will
start using gretl for. It is not some super duper matrix programming
language that no one has heard of or care about. I am increasingly
thinking that Hansl is a bad idea. There are already good free
alternatives with dozens of developers. Why compete with R?
I am a serious follower of gretl since 2005 (which is not as long as
some people on this list but still pretty long) and I see how design
direction has changed over the years. Initially, gretl was about
combining the various nice and available open source technologies such
as ESL, GTK, gnu MP, gnuplot, x12arima - tramo/seats in an intuitive
little package that can deliver. This is something that can be done by
a single dedicated individual namely you (and a small number of
contributors), who along this purpose added over time popular methods
as well as very very nice databases, example scripts, textbook data
sets, and translations; which has attracted many people on this list
to gretl in the first place.
In the last 4 years, however, it has become more and more about Hansl
and developing the most elegant scripting language ever. This is a too
big task even for you. It is not even that important. Much less work
would go into adopting R for scripting (just like how gretl adopted
gnuplot and GTK before) and that would put the program in a much more
advantageous position today. Just imagine being able to use some 4200
packages in CRAN.
As for today... Well, R is devouring everything and that is a good
thing. So what gretl needs to do is to position itself as
complementary to R so that it will remain relevant in the foreseeable
future. On future, Google Chief Economist Hal Varian says (New York
Times, 25 February 2008)
"So what’s getting ubiquitous and cheap? Data. And what is
complementary to data? Analysis. So my recommendation is to take lots
of courses about how to manipulate and analyze data: databases,
machine learning, econometrics, statistics, visualization, and so on."
What this means is that there is and will be a hugely increased demand
for good and easy-to-use GUI based econometric packages such as Eviews
and SPSS. Gretl really has a shot here because it is already
comparable to these programs in terms of ease of use and functionality
(although it still has considerable catching up to do). Plus, the
commercial programs are expensive and hard to use in terms of the
installation, registration, upgrade hassles. On the other hand, gretl
cannot and doesn't have to compete with R to become the platform on
which new methods will be developed. So the future of gretl lies with
students as well as corporate and government people, so deal with it.
Accordingly, the development has to shift focus on future trends: (1)
Intuitive GUI based modern econometric analysis, (2) localization, (3)
teaching, (4) portability.
As you know, I am writing all this because I really care about gretl.
I know about software, I have research on it, and I am saying now so
that, if gretl becomes a footnote in scientific software history (such
as EAL, ESP, DAMSEL, EPS), noone will say "if you knew, why didn't you
tell?"
Sincerely
Talha
On Mon, Jan 7, 2013 at 3:55 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Mon, 7 Jan 2013, Andreas Noack Jensen wrote:
> Even though I can always find what I am looking for (which is a
> problem in OxMetrics) I find the GUI a little unintuitive.
> Unfortunately a cannot really say what to change in order make it
> more intuitive to me. Only, that I don't like the category
> "Nonlinear models" as I think the categories should be positively
> defined (like the story about the two animals of the world:
> Elephants and non-elephants).
That's a fair point, and easy enough to fix, or at least improve.
Having a "Limited dependent variable" category in the model menu
might help?
> A more real problem is GTK maybe. It just doesn't look good in
> general and in particular not on Windows and Mac. Again, I have no
> idea about how to change that as I guess it would take too much
> work without any functionality gains.
Using a toolkit other than GTK for the GUI would be a huge amount of
work and not something I personally would undertake. But GTK 3 has a
more "modern" look, and as it matures we can consider switching for
the Windows and Mac packages. As I've mentioned before, using the
Quartz-based variant of GTK would (in principle) make gretl much
more Mac-like.
> I have thought about what I think the obstacles for Gretl are in getting
> more attention. The statistical functionalities in Gretl are really great.
> Within my own area I think that the cointegration stuff is really great and
> better than most of the commercial packages (but the unrestricted models
> should still go :-)). At my department we teach SAS but faculty uses Stata
> and I don't think it will change anytime soon. Maybe people like the idea
> about a supporting institution (enterprise) for the software to ensure
> continuity which is again a problem that is hard to deal with.
True, we can't do the "enterprise" thing. But we could perhaps think
about a more formal release process, with more systematic and
widespread pre-testing -- and more "advertising", if we can think of
a way of doing that. Maybe do one "LTS" release per year, in which
case we could maybe reinstate automated updates for such releases.
Not sure how much this would help, but one thing I've noticed with
colleagues who use gretl in their teaching is that they and their
students tend to be using rather dated versions of gretl at most
points in time.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
2:10 p.m.
While I strongly believe that usability is currently the most imperative issue for Gretl
(though not necessarily the most important), I do not agree with Dr. Yalta that Hansel is
a mistake. I could not do the research I do with a GUI based stats package. It would take
hours. R is a fine package, so is Ox and Matlab, etc. I use each, but Gretl's matrix
programing and scripting language is nothing to sneeze at and like each of the others is a
great tools for the jobs it does. I see these packages as complements, not substitutes.
I did not mean that the development of Gretl needs to change directions. I only meant
that more focus for the short-term needs to be placed on making Gretl easier to adopt.
I would like to suggest a few simple steps to start
1. Adopt a consistent citation standard something like Ox:
Ox should be cited whenever it is used. For example you could say in the text:
the results are generated using Ox version 6.10 (see Doornik, 2007) and the Arfima
package version 1.00 (Doornik and Ooms, 2003)
and then give the references:
Doornik, J.A. (2007), Object-Oriented Matrix Programming Using Ox, 3rd ed. London:
Timberlake Consultants Press and Oxford: www.doornik.com.
Doornik, J.A. and M. Ooms, M. (2003). Computational Aspects of Maximum Likelihood
Estimation of Autoregressive Fractionally Integrated Moving Average Models, Computational
Statistics and Data Analysis, 41, 333-348. Also see www.doornik.com.
Perhaps you could have people cite the user guide (or a review of the software coauthored
by the main developers) and the wiki site
2. Move the help documentation to the wiki. (Also, let those of us too new to Gretl to be
of much use in development know how to help with this)
3. Depreciate the email lists in favor of a forum based Q&A like TeX Exchange. (I know
this is a sensitive topic, but the wiki will not succeed until it is the main place to
look for information.)
Cheers,
Logan
-----Original Message-----
From: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel-bounces@lists.wfu.edu] On
Behalf Of Talha Yalta
Sent: Tuesday, January 08, 2013 2:50 AM
To: Gretl development
Subject: Re: [Gretl-devel] Signalling
As for the main topic... I fully agree with Dr. Kelly and others about the GUI. As I have
also mentioned, the GUI and the menu structure needs some serious attention based on a
modern and consistent design direction. LaTeX output and graph pages need to work in all
cases since such are the things that make gretl so "cool" to use. Also, it would
be nice to add a few items for easily performing what applied people do nowadays. For
example, it would be nice to have Peseran's ARDL bounds testing in addition to
gretl's nice VAR, VEC, Johansen GUI facilities.
The above are the sort of things that most people love, use, and will start using gretl
for. It is not some super duper matrix programming language that no one has heard of or
care about. I am increasingly thinking that Hansl is a bad idea. There are already good
free alternatives with dozens of developers. Why compete with R?
I am a serious follower of gretl since 2005 (which is not as long as some people on this
list but still pretty long) and I see how design direction has changed over the years.
Initially, gretl was about combining the various nice and available open source
technologies such as ESL, GTK, gnu MP, gnuplot, x12arima - tramo/seats in an intuitive
little package that can deliver. This is something that can be done by a single dedicated
individual namely you (and a small number of contributors), who along this purpose added
over time popular methods as well as very very nice databases, example scripts, textbook
data sets, and translations; which has attracted many people on this list to gretl in the
first place.
In the last 4 years, however, it has become more and more about Hansl and developing the
most elegant scripting language ever. This is a too big task even for you. It is not even
that important. Much less work would go into adopting R for scripting (just like how gretl
adopted gnuplot and GTK before) and that would put the program in a much more advantageous
position today. Just imagine being able to use some 4200 packages in CRAN.
As for today... Well, R is devouring everything and that is a good thing. So what gretl
needs to do is to position itself as complementary to R so that it will remain relevant in
the foreseeable future. On future, Google Chief Economist Hal Varian says (New York Times,
25 February 2008)
"So what's getting ubiquitous and cheap? Data. And what is complementary to data?
Analysis. So my recommendation is to take lots of courses about how to manipulate and
analyze data: databases, machine learning, econometrics, statistics, visualization, and so
on."
What this means is that there is and will be a hugely increased demand for good and
easy-to-use GUI based econometric packages such as Eviews and SPSS. Gretl really has a
shot here because it is already comparable to these programs in terms of ease of use and
functionality (although it still has considerable catching up to do). Plus, the commercial
programs are expensive and hard to use in terms of the installation, registration, upgrade
hassles. On the other hand, gretl cannot and doesn't have to compete with R to become
the platform on which new methods will be developed. So the future of gretl lies with
students as well as corporate and government people, so deal with it.
Accordingly, the development has to shift focus on future trends: (1) Intuitive GUI based
modern econometric analysis, (2) localization, (3) teaching, (4) portability.
As you know, I am writing all this because I really care about gretl.
I know about software, I have research on it, and I am saying now so that, if gretl
becomes a footnote in scientific software history (such as EAL, ESP, DAMSEL, EPS), noone
will say "if you knew, why didn't you tell?"
Sincerely
Talha
On Mon, Jan 7, 2013 at 3:55 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Mon, 7 Jan 2013, Andreas Noack Jensen wrote:
> Even though I can always find what I am looking for (which is a
> problem in OxMetrics) I find the GUI a little unintuitive.
> Unfortunately a cannot really say what to change in order make it
> more intuitive to me. Only, that I don't like the category "Nonlinear
> models" as I think the categories should be positively defined (like
> the story about the two animals of the world:
> Elephants and non-elephants).
That's a fair point, and easy enough to fix, or at least improve.
Having a "Limited dependent variable" category in the model menu might
help?
> A more real problem is GTK maybe. It just doesn't look good in
> general and in particular not on Windows and Mac. Again, I have no
> idea about how to change that as I guess it would take too much work
> without any functionality gains.
Using a toolkit other than GTK for the GUI would be a huge amount of
work and not something I personally would undertake. But GTK 3 has a
more "modern" look, and as it matures we can consider switching for
the Windows and Mac packages. As I've mentioned before, using the
Quartz-based variant of GTK would (in principle) make gretl much more
Mac-like.
> I have thought about what I think the obstacles for Gretl are in
> getting more attention. The statistical functionalities in Gretl are really great.
> Within my own area I think that the cointegration stuff is really
> great and better than most of the commercial packages (but the
> unrestricted models should still go :-)). At my department we teach
> SAS but faculty uses Stata and I don't think it will change anytime
> soon. Maybe people like the idea about a supporting institution
> (enterprise) for the software to ensure continuity which is again a problem that is
hard to deal with.
True, we can't do the "enterprise" thing. But we could perhaps think
about a more formal release process, with more systematic and
widespread pre-testing -- and more "advertising", if we can think of a
way of doing that. Maybe do one "LTS" release per year, in which case
we could maybe reinstate automated updates for such releases.
Not sure how much this would help, but one thing I've noticed with
colleagues who use gretl in their teaching is that they and their
students tend to be using rather dated versions of gretl at most
points in time.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
"Blessed are the young for they shall inherit the national debt." - Herbert C.
Hoover (1874-1964)
--
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3:10 p.m.
On Tue, Jan 8, 2013 at 4:10 PM, Logan Kelly <logan.kelly(a)uwrf.edu> wrote:
While I strongly believe that usability is currently the most
imperative issue for Gretl (though not necessarily the most important), I do not agree
with Dr. Yalta that Hansel is a mistake. I could not do the research I do with a GUI based
stats package. It would take hours. R is a fine package, so is Ox and Matlab, etc. I use
each, but Gretl's matrix programing and scripting language is nothing to sneeze at and
like each of the others is a great tools for the jobs it does.
OK, I agree. Hansl is so good that it is hard to believe that just one
person developed it (with some limited help from a small community of
people). The fact remains that gretl has always been pretty much a one
man operation and it is not a good use of resources to undertake the
colossal task of developing a matrix programing and scripting
language, especially when there is already excellent free
alternatives.
Allin has been working with great dedication on gretl for about 14
years now. That is a long time. What will happen when he eventually
wants to step back? He probably wants to do that now but cannot. Gretl
quickly needs to position itself as the link between Excel and R,
which will be increasingly important. In the next 5 years it has to
make some important inroads into the corporations, universities and
government agencies. If it can start dominating those areas, it is
quite possible that the program will start receiving support and
resources from some places with deep pockets. Allin would be like
Linus, if you will. Gretl would go from success to success and we
would brag about being there during history in the making. Don't
underestimate those who Jack calls the "low end segment of the
market".
Otherwise, I see a bleak future for gretl. Time is ticking. Mark my words.
Talha
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
3:53 p.m.
On Tue, 8 Jan 2013, Talha Yalta wrote:
On Tue, Jan 8, 2013 at 4:10 PM, Logan Kelly
<logan.kelly(a)uwrf.edu> wrote:
> While I strongly believe that usability is currently the most
> imperative issue for Gretl (though not necessarily the most
> important), I do not agree with Dr. Yalta that Hansel is a
> mistake. I could not do the research I do with a GUI based stats
> package. It would take hours. R is a fine package, so is Ox and
> Matlab, etc. I use each, but Gretl's matrix programing and
> scripting language is nothing to sneeze at and like each of the
> others is a great tools for the jobs it does.
OK, I agree. Hansl is so good that it is hard to believe that just one
person developed it (with some limited help from a small community of
people).
I have to say: not one but two-plus. At present I'm the only one who
codes the gretl GUI, but where the development of hansl is concerned
Jack is an equal partner (and a few others have made useful
contributions). To expand on this just a little: Jack and I have had
summer working sessions in Ancona several times over the last 7
years. Without Jack's contribution -- both at those sessions and
throughout the year -- hansl (and gretl more generally) would have
made nothing like the progress we've seen over that period. And
without Jack's stimulus, I suspect my own interest might have waned
some time ago.
The fact remains that gretl has always been pretty much a one
man operation and it is not a good use of resources to undertake the
colossal task of developing a matrix programing and scripting
language, especially when there is already excellent free
alternatives.
The trouble is that the "resources" in question have their own
preferences, and they like working on hansl. It would not be
attractive to me to devote myself to "perfecting" the GUI for
teaching purposes -- though I'm happy to spend some of my time on
fixing/improving specific aspects of the GUI. In addition, I think
that producing a "nice teaching GUI" and nothing more is a dead end.
Those who teach econometrics will in general want their students to
use software that they can continue to use in their professional
lives.
Allin has been working with great dedication on gretl for about 14
years now. That is a long time. What will happen when he eventually
wants to step back? He probably wants to do that now but cannot.
Actually, not so. There will come a time, of course, but right now
working on gretl + hansl is still something I like doing and want to
continue doing.
Allin
4:47 p.m.
W dniu 08.01.2013 16:53, Allin Cottrell pisze:
> Allin has been working with great dedication on gretl for about
14
> years now. That is a long time. What will happen when he eventually
> wants to step back? He probably wants to do that now but cannot.
Actually, not so. There will come a time, of course, but right now
working on gretl + hansl is still something I like doing and want to
continue doing.
This is maybe a little OT, but we've talked about it at the 1st
and
later at the 2nd Gretl Conference: documentation the C code. We agreeded
(togeather with Jack) that I would start from very early pieces of C
and... Allin I asked you last year: where to start?
Marcin
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Marcin Błażejowski
GG: 203127
4:59 p.m.
On Tue, 8 Jan 2013, Marcin Błażejowski wrote:
This is maybe a little OT, but we've talked about it at the 1st
and
later at the 2nd Gretl Conference: documentation the C code. We agreeded
(togeather with Jack) that I would start from very early pieces of C
and... Allin I asked you last year: where to start?
I'd say a good starting point is the big "switch" statement in
the function gretl_cmd_exec(), in lib/src/interact.c. That's the
jumping-off point for the code that implements most gretl commands.
Allin
9:22 p.m.
New subject: Some basic info on the gretl source [was:Signalling]
On Tue, 8 Jan 2013, Allin Cottrell wrote:
On Tue, 8 Jan 2013, Marcin Błażejowski wrote:
> This is maybe a little OT, but we've talked about it at the 1st and later
> at the 2nd Gretl Conference: documentation the C code. We agreeded
> (togeather with Jack) that I would start from very early pieces of C and...
> Allin I asked you last year: where to start?
I'd say a good starting point is the big "switch" statement in
the function gretl_cmd_exec(), in lib/src/interact.c. That's the jumping-off
point for the code that implements most gretl commands.
Roughly, here's how the C source is organised: the most important
subdirectory is "lib/src", which contains the source to the dynamic
library. Then you have "plugin", where you find all the stuff that is not
contained in the library, but is used by the clients: mainly advanced
statistical methods (like eg vecm or dpanel), but also other things, like
the importers from foreign file formats. Then, in the "cli" and "gui2"
directories, you have the source for the CLI and GUI clients,
respectively.
Inside the lib/src/ subdirectory, as Allin said, the first thing to look
at is probably interact.c and the function gretl_cmd_exec(): the main idea
of both the CLI and GUI clients is that they run a huge endless loop which
examines user input and translates it into gretl "actions" as appropriate.
So for example the command "nulldata", given at the CLI or GUI console, or
the action "File > New data set" in the GUI client translate into the
NULLDATA internal gretl command. You'll find a complete list of such
commands in the file lib/src/gretl_commands.h.
Of course, the most important command of all is "genr", so there's a good
deal of C code which deals exclusively with it. If you want to have a look
at how things are done in that department, be aware that it's one of the
most complicated parts of the gretl source, and it's not useless to have
an idea of how the main techniques for lexing/parsing/evaluating
expressions work in compilers. Basically, however, the "lexer" (genlex.c)
translates a string like, say, "scalar a = exp(2+1)" into a "parse
tree",
which is then "evaluated" by the eval() function (geneval.c), which is
typically called recursively and calls the number-crunching functions
(which may be in geneval.c itself, or, in other cases, in dedicated files
like genfuncs.c).
As for estimation techniques, something that is probably useful to get you
started is that practically all of them work by filling up a container
called a MODEL. The description of what a MODEL is can be found in
lib/src/libgretl.h at about line 300, but suffice it to say that it's not
unlike a hansl bundle, that you fill up with numbers as you compute them.
So for example, when you estimate a probit model, you first set up an
empty MODEL, then you fill up the "coeff" array with the estimated
coefficients, etcetera. Once the container is properly filled with all the
good stuff, it gets printed and is put somewhere (the "stack") where
the client program can find it if needed.
Actually, probit/logit models are a nice place to start to get the hang of
how things are typically done: you'll find those in the function
binary_model() in lib/src/discrete.c (don't start from OLS: the code in
there is decidedly harder to follow; but if you have to, look at ar1_lsq()
in lib/src/estimate.c).
Sorry for the long message, but you asked for 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
-------------------------------------------------------
6:54 a.m.
New subject: Some basic info on the gretl source [was:Signalling]
W dniu 08.01.2013 22:22, Riccardo (Jack) Lucchetti pisze:
On Tue, 8 Jan 2013, Allin Cottrell wrote:
> On Tue, 8 Jan 2013, Marcin Błażejowski wrote:
>
>> This is maybe a little OT, but we've talked about it at the 1st and
>> later at the 2nd Gretl Conference: documentation the C code. We
>> agreeded (togeather with Jack) that I would start from very early
>> pieces of C and... Allin I asked you last year: where to start?
>
> I'd say a good starting point is the big "switch" statement in
> the function gretl_cmd_exec(), in lib/src/interact.c. That's the
> jumping-off point for the code that implements most gretl commands.
Sorry for the long message, but you asked for it! :)
The message is great!!! Now I
know from where to start and what to learn
(a lot of).
Regards,
Marcin
-------------------------------------------------------
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-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Marcin Błażejowski
GG: 203127
4:55 p.m.
On Tue, Jan 8, 2013 at 5:53 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
I have to say: not one but two-plus. At present I'm the only one
who
codes the gretl GUI, but where the development of hansl is concerned
Jack is an equal partner (and a few others have made useful
contributions). To expand on this just a little: Jack and I have had
summer working sessions in Ancona several times over the last 7
years. Without Jack's contribution -- both at those sessions and
throughout the year -- hansl (and gretl more generally) would have
made nothing like the progress we've seen over that period. And
without Jack's stimulus, I suspect my own interest might have waned
some time ago.
I can never forget or underestimate what Jack has contributed and
still is so generously providing to gretl. Of course, plus the handful
of people myself included. But I think you are being so nice and
modest, as usual.
The trouble is that the "resources" in question have their
own
preferences,
Unfortunately that is a well known limitation of open source
software,
especially when the number of developers are small. But you surely see
the vicious cycle here, due to not yet being able to conquer that huge
segment of "low end users" that is full of potential and nice
surprises.
that producing a "nice teaching GUI" and nothing more is a
dead end.
Those who teach econometrics will in general want their students to
use software that they can continue to use in their professional
lives.
I have never advocated "producing a nice teaching GUI and nothing
more". But I do advocate a shiny, modern, consistent, and rock solid
GUI for applied research, as well as teaching.
Actually, not so. There will come a time, of course, but right now
working on gretl + hansl is still something I like doing and want to
continue doing.
And we are all grateful for that. God bless you, Jack, and all who
have made gretl possible. But I stand by my analysis and predictions.
Sincerely
Talha
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
9:48 p.m.
On Tue, 8 Jan 2013, Talha Yalta wrote:
> that producing a "nice teaching GUI" and nothing more
is a dead end.
> Those who teach econometrics will in general want their students to
> use software that they can continue to use in their professional
> lives.
I have never advocated "producing a nice teaching GUI and nothing
more". But I do advocate a shiny, modern, consistent, and rock solid
GUI for applied research, as well as teaching.
Others may disagree, but I find it very unrealistic that in 2013 someone
could produce applied research (at the level you'd expect to find in a
reputable scientific journal) without relying on a solid, flexible and
comprehensive scripting language. If you prefer R over hansl, that's fine:
use R. But the fact is, that many in the economic/econometric profession
find R not fun to work with, and much prefer (say) Matlab or GAUSS. I
believe most of these people find themselves to be much more productive
with hansl than R.
-------------------------------------------------------
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
-------------------------------------------------------
12:06 a.m.
"Others may disagree, but I find it very unrealistic that in 2013 someone
could produce applied research (at the level you'd expect to find in a
reputable scientific journal) without relying on a solid, flexible and
comprehensive scripting language. If you prefer R over hansl, that's fine:
use R. But the fact is, that many in the economic/econometric profession
find R not fun to work with, and much prefer (say) Matlab or GAUSS. I
believe most of these people find themselves to be much more productive
with hansl than R."
What Jack said! I don't claim to speak for 'most people' in econometrics, but
hansl is a big reason why I've been using gretl more for research, as opposed to
'just' teaching, over the past few years. I've played around with R a bit, and
have said to myself "I really should sit down and learn this" for years. But
making the switch from Matlab to R has always been (for me) way too much work. Matlab to
hansl, while not trivial, is much much easier.
FWIW,
PS
________________________________________
From: gretl-devel-bounces(a)lists.wfu.edu [gretl-devel-bounces(a)lists.wfu.edu] on behalf of
Riccardo (Jack) Lucchetti [r.lucchetti(a)univpm.it]
Sent: Tuesday, January 08, 2013 4:48 PM
To: Gretl development
Subject: Re: [Gretl-devel] Signalling
On Tue, 8 Jan 2013, Talha Yalta wrote:
> that producing a "nice teaching GUI" and nothing more
is a dead end.
> Those who teach econometrics will in general want their students to
> use software that they can continue to use in their professional
> lives.
I have never advocated "producing a nice teaching GUI and nothing
more". But I do advocate a shiny, modern, consistent, and rock solid
GUI for applied research, as well as teaching.
Others may disagree, but I find it very unrealistic that in 2013 someone
could produce applied research (at the level you'd expect to find in a
reputable scientific journal) without relying on a solid, flexible and
comprehensive scripting language. If you prefer R over hansl, that's fine:
use R. But the fact is, that many in the economic/econometric profession
find R not fun to work with, and much prefer (say) Matlab or GAUSS. I
believe most of these people find themselves to be much more productive
with hansl than R.
-------------------------------------------------------
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
-------------------------------------------------------
4:05 p.m.
Talha wrote:
> Moreover, the decision to unsupport localized input was a big,
> big, big mistake. If a spreadsheet program decimal comma inputs
> because that is not very useful and/or hard to do, everyone would
> laugh.
And Andreas wrote:
This has been discussed before, but I think this criticism is just
mistaken. The support for decimal comma in Gretl is just as good as the
support in Excel.
I'm not going to spend long on this, but I think Andreas is right on
the factual point, and I don't really know what Talha means by a
"decision to unsupport localized input". We support the local
decimal character in the GUI to the extent possible without breaking
the hard-and-fast decision that we are not going to support anything
other than the decimal point in scripting. The latter point is just
a given and there's no profit in discussing it.
Allin
8:40 a.m.
I'm not going to spend long on this, but I think Andreas is right
on
the factual point, and I don't really know what Talha means by a
"decision to unsupport localized input". We support the local
decimal character in the GUI to the extent possible
Not true, although I was
surprised to see that inputting numbers with
comma indeed works in some GUI options in which it didn't a few months
ago. (or maybe I am mistaken because it sometimes works and sometimes
don't, which is very annoying.) Anyway, I still see problems in the
following cases.
1)- Define matrix (initial fill value)
2)- Model window->Save->Define new variable
3)- Main window descriptive labels (decimal dot is used for displayed numbers)
4)- Gnuplot controls->Lines (formula lines show dots)
5)- Gnuplot controls-> Labels, Arrows
These _need_ to be fixed. Only this way gretl can say it supports
different languages, and mean it.
... without breaking
the hard-and-fast decision that we are not going to support anything
other than the decimal point in scripting. The latter point is just
a given and there's no profit in discussing it.
It is a relief to see Riccardo
and I are not the only obsessed people
here. Seriously though, is it really that hard, in comparison to all
the effort and what is already in there, to provide this feature? I
mean, all that is needed is a clever interpretation layer that will
switch commas with dots. It is probably a bit more complicated than
that but still it cannot be like designing a system like Unicode
involving rules and properties to support dozens of different writing
systems.
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
9:36 a.m.
I still see problems in the
following cases.
1)- Define matrix (initial fill value)
Decimal comma works for me here
2)- Model window->Save->Define new variable
Confirmed, but I get a very informative error message.
3)- Main window descriptive labels (decimal dot is used for
displayed
numbers)
Confirmed
4)- Gnuplot controls->Lines (formula lines show dots)
Confirmed
5)- Gnuplot controls-> Labels, Arrows
Decimal comma works for me here
It is a relief to see Riccardo and I are not the only obsessed people
here. Seriously though, is it really that hard, in comparison to all
the effort and what is already in there, to provide this feature? I
mean, all that is needed is a clever interpretation layer that will
switch commas with dots. It is probably a bit more complicated than
that but still it cannot be like designing a system like Unicode
involving rules and properties to support dozens of different writing
systems.
I think you are really alone on this one. Again, can you give a name of a
programming/scripting language supporting this? Anyway, Riccardo and Allin
have been pretty clear on their views on this but you could try to program
such an interpretation layer and show its merits.
--
Med venlig hilsen
Andreas Noack Jensen
10:29 a.m.
On Tue, 8 Jan 2013, Andreas Noack Jensen wrote:
> It is a relief to see Riccardo and I are not the only obsessed
people
> here. Seriously though, is it really that hard, in comparison to all
> the effort and what is already in there, to provide this feature? I
> mean, all that is needed is a clever interpretation layer that will
> switch commas with dots. It is probably a bit more complicated than
> that but still it cannot be like designing a system like Unicode
> involving rules and properties to support dozens of different writing
> systems.
>
>
I think you are really alone on this one. Again, can you give a name of a
programming/scripting language supporting this? Anyway, Riccardo and Allin
have been pretty clear on their views on this but you could try to program
such an interpretation layer and show its merits.
I think that Talha's suggestion refer to the GUI elements only, and
(unless I'm mistaken) he's not proposing to change anything
scripting-related. Because otherwise, you'd have to deal with problems
like the interpretation of
<hansl>
matrix boo = { 1,2 }
</hansl>
which would obviously be a nightmare.
-------------------------------------------------------
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
-------------------------------------------------------
10:55 a.m.
I think that Talha's suggestion refer to the GUI elements only,
and (unless
I'm mistaken) he's not proposing to change anything scripting-related.
Yes,
I see and accept scripting has to use just one consistent way in
terms of mathematical notation as well as command names.
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
5:25 p.m.
New subject: decimal comma in GUI (was Re: Signalling)
On Tue, 8 Jan 2013, Andreas Noack Jensen wrote, following Talha:
> I still see problems in the following cases.
> 1)- Define matrix (initial fill value)
Decimal comma works for me here
And for me too.
> 2)- Model window->Save->Define new variable
Confirmed, but I get a very informative error message.
That's now fixed: the model "genr" dialog behaves the same way as
the regular one.
> 3)- Main window descriptive labels (decimal dot is used for
displayed
> numbers)
Confirmed
Yes. What's shown is the canonical formula for generating the
variable in question. I'm not inclined to change that.
> 4)- Gnuplot controls->Lines (formula lines show dots)
Confirmed
Same comment as on the last one: that's the canonical version, what
you actually have to use with gnuplot. Note that the "legend"
version uses the decimal comma (in the relevant locales).
> 5)- Gnuplot controls-> Labels, Arrows
Decimal comma works for me here
And for me too.
Allin
7:14 a.m.
New subject: decimal comma in GUI (was Re: Signalling)
Surprisingly, and unlike my yesterday build, I can now also confirm
what you confirm. Just one thing though: I can understand the formula
line for gnuplot (it is not very visible anyway) but could you please
reconsider showing decimal comma in the main window descriptions, if
it is not very hard to do? It looks ugly and inconsistent. We do not
perceive it as a formula but and explanation.
On Tue, Jan 8, 2013 at 7:25 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Tue, 8 Jan 2013, Andreas Noack Jensen wrote, following Talha:
>> I still see problems in the following cases.
>> 1)- Define matrix (initial fill value)
>
> Decimal comma works for me here
And for me too.
>> 2)- Model window->Save->Define new variable
>
> Confirmed, but I get a very informative error message.
That's now fixed: the model "genr" dialog behaves the same way as
the regular one.
>> 3)- Main window descriptive labels (decimal dot is used for displayed
>> numbers)
>
> Confirmed
Yes. What's shown is the canonical formula for generating the
variable in question. I'm not inclined to change that.
>> 4)- Gnuplot controls->Lines (formula lines show dots)
>
> Confirmed
Same comment as on the last one: that's the canonical version, what
you actually have to use with gnuplot. Note that the "legend"
version uses the decimal comma (in the relevant locales).
>> 5)- Gnuplot controls-> Labels, Arrows
>
> Decimal comma works for me here
And for me too.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Blessed are the young for they shall inherit the national debt.” –
Herbert C. Hoover (1874-1964)
--
3:44 p.m.
Going to the start of the debate,
What your statistical software says about you (to me):
*Gretl*: there are two different types of users,
1) those who use *only* the GUI and many of them think gretl is not
sophisticated enough for doing serious calculus, and
2) those (not many, indeed) who use the gretl scripting language (no yet
registered as HANSL in the web page).
We have two problems: increase the number of type 1) or 2) users, and
convince people from 1) that it is possible to go 2), i.e. you may do
now with gretl what you want.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ehu.es/ignacio.diaz-emparanza/
www.ea3.ehu.es
1:54 a.m.
Hello all,
As one of the new users you would like to recruit, I would like to add some feed back on
this topic. First, let me season my comments by saying that I went from skeptic to fanatic
in about a month. Gretl is simply one of the best packages available (pay or free).
If the goal is to make Gretl more popular, then more time needs to be focussed on
usability. Even if that comes at the short-term expense of developing new capabilities.
First, the GUI, whether you stick to the menus or are a coder, is your first impression of
the software. And the GUI really understates this "grader" of Gretl. I would
love to see a more integrated GUI with docked windows like STATA or Matlab.
Second, the documentation. While the user guid is a good start, parts are incomplete and I
have thus found myself asking simple question on the email forum. (Thank you for
graciously putting up with me as I am learning). Also, why is there a function reference
and a command reference? I am continuously looking thing up twice because I do not know if
I need a function or a command. Simply combining these documents in some way that makes
sense would be helpful.
What I would love to see is that
1. The user guid and help files be put in HTML so that like STATA I can Google a method
and quickly find a help file, e.g. googling "Gretl ols" returns a help page on
running ols in Gretl.
2. The email forum is good, but there are several forum type q&a projects that would
(i) be easier for new users to search and access and (ii) show up in search engine
results. This would require manually coping content to the new forum, but that is
something new comers like me could contribute to the community. (I know this is a topic
that has been raised before, but I think it is very worth consideration).
3. More video tutorials of basic GUI functionality. This would (i) make adoption in stats
courses easer and (ii) increase search engine visibility. (Note: I am planning on making a
series of tutorial for an MBA course I teach.)
Finally, I think citing the use of Gretl should be at least strongly suggested in exchange
for using the package, similar to Ox.
Cheers,
Logan
--
Logan J. Kelly, Ph.D.
Assistant Professor, Department of Economics
Director, UWRF Center for Economic Research
http://www.uwrf.edu/cer
23 D South Hall
College of Business and Economics
University of Wisconsin - River Falls
410 S. Third Street
River Falls, WI 54022-5001
8:02 a.m.
On Tue, 8 Jan 2013, Logan Kelly wrote:
Hello all,
As one of the new users you would like to recruit, I would like to add
some feed back on this topic. First, let me season my comments by saying
that I went from skeptic to fanatic in about a month. Gretl is simply
one of the best packages available (pay or free).
Nie to hear :)
If the goal is to make Gretl more popular, then more time needs to be
focussed on usability. Even if that comes at the short-term expense of
developing new capabilities.
First, the GUI, whether you stick to the menus or are a coder, is your
first impression of the software. And the GUI really understates this
"grader" of Gretl. I would love to see a more integrated GUI with docked
windows like STATA or Matlab.
This has been discussed several times over the years. People from a
windows background (of course the majority) tend to like applications
which show as a big "container" of "subitems". Maybe we should revisit
this topic once more.
Second, the documentation. While the user guid is a good start, parts
are incomplete and I have thus found myself asking simple question on
the email forum. (Thank you for graciously putting up with me as I am
learning). Also, why is there a function reference and a command
reference? I am continuously looking thing up twice because I do not
know if I need a function or a command. Simply combining these documents
in some way that makes sense would be helpful.
Yeah, this is a bit of a sore point. Trouble is, writing docs takes time,
an awful lot of time. IMO, if Allin and I and anyone who's willing to help
could find the time to finally have the hansl manual done, the situation
would improve drastically, in that you'd have:
1) a short user's guide, for beginners and gui-only people
2) the hansl manual, for scripters
3) a separate "Econometric methods" guide, for those who want to know
_exactly_ how gretl does things without perusing the C source (a bit à la
"Methods and Formulas" sections in the Stata docs)
4) The Reference manual
and this arrangement would probably be less confusing.
What I would love to see is that
1. The user guid and help files be put in HTML so that like STATA I can
Google a method and quickly find a help file, e.g. googling "Gretl ols"
returns a help page on running ols in Gretl.
Nice idea. The source is in xml already, so this could be done pretty
quickly (at least in thoery).
2. The email forum is good, but there are several forum type q&a
projects that would (i) be easier for new users to search and access and
(ii) show up in search engine results. This would require manually
coping content to the new forum, but that is something new comers like
me could contribute to the community. (I know this is a topic that has
been raised before, but I think it is very worth consideration).
The wiki experiment hasn't been a success, to put it mildly. We may try.
3. More video tutorials of basic GUI functionality. This would (i)
make
adoption in stats courses easer and (ii) increase search engine
visibility. (Note: I am planning on making a series of tutorial for an
MBA course I teach.)
Great!
Finally, I think citing the use of Gretl should be at least strongly
suggested in exchange for using the package, similar to Ox.
This is another point what hasn't been resolved for years: we need to find
a way to cite gretl in such a way that is consistent and shows up on the
major engines, such as Econpapers/IDEAS, and IMO we need this badly.
-------------------------------------------------------
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
-------------------------------------------------------
4118
days inactive
4120
days old
34 comments
10 participants
participants (10)
-
Allin Cottrell -
Andreas Noack Jensen -
artur tarassow -
Ignacio Diaz-Emparanza -
Lee Adkins -
Logan Kelly -
Marcin Błażejowski -
Riccardo (Jack) Lucchetti -
Summers, Peter -
Talha Yalta