6:30 p.m.
Hi,
I have been using gretl in my teaching, and it has worked well. The
students seem to like the software.
However, I have a few suggestions for improvements of gretl, making
it possible for me to use it in other courses:
1. A possibility to generate random binomial variables, for example
by adding a menu entry Add > Random variable > Binomial
2. For frequency plots of continual data (i.e., histograms), amke it
possible for the user to
a). Choose bin width
b). Choose number of bins
3. For discrete data, make it possible to create pie charts
These are the most important improvements. What are the chances of
these suggestions being implemented soon?
Some other suggestions, not necessary for using in the courses I am
thinking about, but which would be quite useful and nice to have in
gretl (in order of importance):
1. Support for Multinomial logistic regression
2. Forward/backward stepwise selection for regressions
3. Direct import of R format, SPSS format and OpenOffice.org Calc format files
4. Quantile regression
5. Ordinal logistic regression
Are there any chances of these suggestions being implemented?
Best regards,
Andreas
8:10 p.m.
On Wed, 20 Dec 2006, Andreas Karlsson wrote:
I have a few suggestions for improvements of gretl, making it
possible for me to use it in other courses:
1. A possibility to generate random binomial variables, for
example by adding a menu entry Add > Random variable > Binomial
That would be easy enough. Also easy to do manually, for example
* add normal random variable, u
* genr binrand = u > 0
2. For frequency plots of continual data (i.e., histograms), amke it
possible
for the user to
a). Choose bin width
b). Choose number of bins
Not hard at the basic coding level. A bit more time-consuming to
construct a good user interface.
3. For discrete data, make it possible to create pie charts
Pie charts are evil, and are not supported by gnuplot. That one
probably won't happen soon, though obviously it's not hugely
difficult.
These are the most important improvements. What are the chances of
these
suggestions being implemented soon?
1 and 2 are candidates for fairly quick attention, though I can't
promise just how soon.
Some other suggestions, not necessary for using in the courses I am thinking
about, but which would be quite useful and nice to have in gretl (in order of
importance):
1. Support for Multinomial logistic regression
2. Forward/backward stepwise selection for regressions
3. Direct import of R format, SPSS format and OpenOffice.org Calc
format
files
These formats all quite time-consuming propositions. Is there an
open spec for the SPSS format?
4. Quantile regression
5. Ordinal logistic regression
Ordered logit is in current CVS.
The estimators you mention are good candidates for inclusion at
some point, but I don't know how soon -- there are lots of things
to be done and only two of us actually coding on gretl.
Allin.
9:13 p.m.
At 21:10 2006-12-20, you wrote:
On Wed, 20 Dec 2006, Andreas Karlsson wrote:
>
>Some other suggestions, not necessary for using in the courses I am
>thinking about, but which would be quite useful and nice to have in
>gretl (in order of importance):
>1. Support for Multinomial logistic regression
>2. Forward/backward stepwise selection for regressions
>3. Direct import of R format, SPSS format and OpenOffice.org Calc
>format files
These formats all quite time-consuming propositions. Is there an
open spec for the SPSS format?
Well, since R can import SPSS format files easily (with
spss.get(Hmisc)) the R importer could probably be used to find
specifications for the SPSS format.
Regards,
Andreas
9:25 p.m.
On Wed, December 20, 2006 21:10, Allin Cottrell wrote:
On Wed, 20 Dec 2006, Andreas Karlsson wrote:
> I have a few suggestions for improvements of gretl, making it
> possible for me to use it in other courses:
>
> 1. A possibility to generate random binomial variables, for
> example by adding a menu entry Add > Random variable > Binomial
That would be easy enough. Also easy to do manually, for example
* add normal random variable, u
* genr binrand = u > 0
Actually, that would be a Bernoulli r.v. If I'm not mistaken, a binomial r.v.
is one for which (in LaTeX notation)
P(x=k) = n \choose k p^k (1-p)^{n-k}
It can be added quite easily. However, a little script will give you what you
want too:
scalar n = 10
scalar p = 0.4
series x = 0
loop n
x += (uniform()>p)
end loop
now x is binomial. True, this may be inelegant when n is big, but in that case
a binomial rv is practically Gaussian.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
12:54 p.m.
Allin Cottrell schrieb:
The estimators you mention are good candidates for inclusion at some
point, but I don't know how soon -- there are lots of things to be done
and only two of us actually coding on gretl.
Allin.
I am certainly not against including new features in gretl, but given
the scarce resources, maybe Jack and you should think of a policy that
determines when a new feature should be implemented via the great new
function package mechanism (i.e. doable by many others), and when it has
to be coded (in C) in gretl itself (i.e. Allin or Jack have to do it).
<Shameless plug:> Of course, allowing shell commands in functions would
greatly expand the scope of function packages by using existing
algorithms in R etc. But it sounded like I already got your "okay" on
that...
-sven
2:14 p.m.
On Thu, December 21, 2006 13:54, Sven Schreiber wrote:
Allin Cottrell schrieb:
>
> The estimators you mention are good candidates for inclusion at some
> point, but I don't know how soon -- there are lots of things to be done
> and only two of us actually coding on gretl.
>
> Allin.
>
I am certainly not against including new features in gretl, but given
the scarce resources, maybe Jack and you should think of a policy that
determines when a new feature should be implemented via the great new
function package mechanism (i.e. doable by many others), and when it has
to be coded (in C) in gretl itself (i.e. Allin or Jack have to do it).
I'm personally inclined to say that from now on everything that can reasonably
done via a user function should be done that way. I say "reasonably" because
our scripting infrastructure is, as of now, not sophisticated enough to
support computationally demanding methods. For example, there is now in CVS a
pretty decent implementation of Arellano & Bond's estimator for dynamic
panels, which would have been impossible to do via a script. But in the end,
it's a bit of a chicken-and-egg problem; gretl's scripting capabilities have
increased enormously in a year or so exactly because we started using
user-level functions for doing things and discovered what was missing during
the process. The other day, I wrote a little function to extract long-run
coefficients from an ADL model (attached for those interested), which exposed
a bug in the matrix code, now fixed in CVS.
The more people write functions, the more enhancements and bug fixes are
likely to come in the future -> the easier it becomes to rely on user-level
functions for doing stuff.
<Shameless plug:> Of course, allowing shell commands in
functions would
greatly expand the scope of function packages by using existing
algorithms in R etc. But it sounded like I already got your "okay" on
that...
This is already in CVS.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
9:33 p.m.
At 15:14 2006-12-21, you wrote:
Content-Type: text/plain; charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by mta01.univpm.it id
kBLEE8tS009798
On Thu, December 21, 2006 13:54, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>
>>
>> The estimators you mention are good candidates for inclusion at some
>> point, but I don't know how soon -- there are lots of things to be done
>> and only two of us actually coding on gretl.
>>
>> Allin.
>>
>
> I am certainly not against including new features in gretl, but given
> the scarce resources, maybe Jack and you should think of a policy that
> determines when a new feature should be implemented via the great new
> function package mechanism (i.e. doable by many others), and when it has
> to be coded (in C) in gretl itself (i.e. Allin or Jack have to do it).
I'm personally inclined to say that from now on everything that can reasonably
done via a user function should be done that way. I say "reasonably" because
our scripting infrastructure is, as of now, not sophisticated enough to
support computationally demanding methods.
Hi,
When I use gretl in my teaching for students in statistics or
econometrics at a basic level, it is as a replacement for Minitab or
EViews. To let them do the tasks I am giving them, it would be to
hard for them to write scripts and use other programming
skills. They want to have a point-and-click GUI like the one in
EViews or Minitab, which I think the gretl GUI can be compared with
in usability. For this purpose, script based user function is thus
not enough, but it has to be a GUI for these tasks. That's why I have
asked for inclusion of some features.
Best regards, and thanks for a great software
Andreas
9:50 p.m.
Andreas Karlsson schrieb:
Hi,
When I use gretl in my teaching for students in statistics or
econometrics at a basic level, it is as a replacement for Minitab or
EViews. To let them do the tasks I am giving them, it would be to hard
for them to write scripts and use other programming skills. They want
to have a point-and-click GUI like the one in EViews or Minitab, which I
think the gretl GUI can be compared with in usability. For this purpose,
script based user function is thus not enough, but it has to be a GUI
for these tasks. That's why I have asked for inclusion of some features.
Best regards, and thanks for a great software
Andreas
What we meant is that you or me or somebody else that knows the
scripting stuff can write function packages that can be loaded (e.g. by
your students) and used point-and-click-wise. Users then would not have
to write (or even look at) scripts for that.
AFAIR there's a section in the user guide about this.
-sven
10:21 p.m.
On Thu, 21 Dec 2006, Sven Schreiber wrote:
Andreas Karlsson schrieb:
> When I use gretl in my teaching for students in statistics or
> econometrics at a basic level, it is as a replacement for Minitab or
> EViews. To let them do the tasks I am giving them, it would be to hard
> for them to write scripts and use other programming skills.
What we meant is that you or me or somebody else that knows the
scripting stuff can write function packages that can be loaded (e.g. by
your students) and used point-and-click-wise. Users then would not have
to write (or even look at) scripts for that.
AFAIR there's a section in the user guide about this.
Yes, this is somewhat experimental at present, but I think it's a
promising avenue for future development. As Jack mentioned, we
have been trying to shake the bugs out of the more advanced
scripting facilities, with the idea that "function authors" -- who
know their gretl but don't necessarily want to mess with
programming in C -- can contribute substantial functionality.
Allin.
6329
days inactive
6330
days old
8 comments
4 participants
participants (4)
-
Allin Cottrell -
Andreas Karlsson -
Riccardo (Jack) Lucchetti -
Sven Schreiber