5:41 p.m.
Hi,
out of curiosity: what is still on the general to-do list for gretl 2.0?
I'm not talking about a wishlist for incremental features which will
always contain some items and will be added in point releases, but the
big picture -- I've heard there's ongoing work about multiprocessing
support, but apart from that I cannot think of anything fundamental that
is really missing, or is there?
Or actually maybe I do have a suggestion for further "modular extension"
interfaces. Namely: make user-defined functions callable by custom
command options.
Example: say somebody writes a function to do a new diagnostic test
after a model is estimated. Say the function is called
'modtest_mynewdiagtest' and the corresponding .inp file has been saved
in a standard (to be defined) place. Then I want the following hansl
code to work:
<hansl-proposed>
ols y 0 x
modtest --mynewdiagtest
</hansl-proposed>
The signature of the user-defined function would be:
'function void modtest_mynewdiagtest (bundle *modelbundle)'
So if gretl encounters an unknown command option, it would check whether
a user-supplied corresponding function definition/file exists, and it
would call that function with the argument of the standard bundle that
the previous estimation command created (if I understand correctly the
way it works now; the internal bundle may have to be exposed to hansl
for that, I don't know).
Then the user-supplied function would presumably print out some results,
and/or add new items to the input bundle which could be used afterwards.
That way gretl could be extended without touching the C source, but from
the point of view of users with the same syntax as the built-in options.
(I guess this would be a bit like do-files in Stata, but I'm not sure.)
Thanks, I wasn't planning to write such a long email....
Sven
6:16 p.m.
Three things that I would love to see in 2.0 (or possibly 3.0):
1. A loop structure like the parfor in Matlab, i. e. a parrell processed loop.
2. A special series data type that can hold text. This would be useful for labeling a
discreet variable, and could be used for making nice labes on factorized plots.
3. More integration of LaTeX. Maybe a LaTeX function like gnuplot().
Cheers,
Logan
-------- Original message --------
From: Sven Schreiber <svetosch(a)gmx.net>
Date: 11/27/2013 11:41 AM (GMT-06:00)
To: Gretl development <gretl-devel(a)lists.wfu.edu>
Subject: [Gretl-devel] remaining feature to-do list
Hi,
out of curiosity: what is still on the general to-do list for gretl 2.0?
I'm not talking about a wishlist for incremental features which will
always contain some items and will be added in point releases, but the
big picture -- I've heard there's ongoing work about multiprocessing
support, but apart from that I cannot think of anything fundamental that
is really missing, or is there?
Or actually maybe I do have a suggestion for further "modular extension"
interfaces. Namely: make user-defined functions callable by custom
command options.
Example: say somebody writes a function to do a new diagnostic test
after a model is estimated. Say the function is called
'modtest_mynewdiagtest' and the corresponding .inp file has been saved
in a standard (to be defined) place. Then I want the following hansl
code to work:
<hansl-proposed>
ols y 0 x
modtest --mynewdiagtest
</hansl-proposed>
The signature of the user-defined function would be:
'function void modtest_mynewdiagtest (bundle *modelbundle)'
So if gretl encounters an unknown command option, it would check whether
a user-supplied corresponding function definition/file exists, and it
would call that function with the argument of the standard bundle that
the previous estimation command created (if I understand correctly the
way it works now; the internal bundle may have to be exposed to hansl
for that, I don't know).
Then the user-supplied function would presumably print out some results,
and/or add new items to the input bundle which could be used afterwards.
That way gretl could be extended without touching the C source, but from
the point of view of users with the same syntax as the built-in options.
(I guess this would be a bit like do-files in Stata, but I'm not sure.)
Thanks, I wasn't planning to write such a long email....
Sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:39 p.m.
On Wed, 27 Nov 2013, Logan Kelly wrote:
Three things that I would love to see in 2.0 (or possibly 3.0):
1. A loop structure like the parfor in Matlab, i. e. a parrell
processed loop.
Actually, we're working on this. Our current idea is to introduce a
similar construct, but slightly different. Ideas are vague at this moment,
so leave us some time to have a few concepts solidify in our minds.
2. A special series data type that can hold text. This would be
useful
for labeling a discreet variable, and could be used for making nice
labes on factorized plots.
You're right, that would be very useful. To some extent, some of it is
already in. For example, try this:
(a) save the data below as a csv file named "mixed.csv"
<csv>
alpha,num
foo,3
foo,2
bar,3
foo,1
bar,3
baz,1
bar,2
foo,0
baz,1
</csv>
(b) run
<hansl>
open mixed.csv
freq alpha
xtab num alpha
</hansl>
Adding something similar to, say, factorized boxplots shouldn't be too
hard. However, you can't really operate on the labels yet. Allin and I
have thought we may introduce a new datatype (the string array), which
could then be used to establish a mapping values of a series and a
corresponding string representation in sach a way that this mapping can be
easy to manipulate by the end user. This is exactly the concept of "value
labels" in spss, or "label values" in stata.
3. More integration of LaTeX. Maybe a LaTeX function like gnuplot().
Allin and I weren't sure of what you meant exactly. We thought it might be
a nice idea to introduce a new function that, given a matrix, would return
a string with a complete LaTeX "tabular" environment. Would this be
similar to what you had in mind?
-------------------------------------------------------
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:42 p.m.
On Wed, 27 Nov 2013, Riccardo (Jack) Lucchetti wrote:
> 2. A special series data type that can hold text. This would be
useful for
> labeling a discreet variable, and could be used for making nice labes on
> factorized plots.
Now in cvs. See below.
(a) save the data below as a csv file named "mixed.csv"
<csv>
alpha,num
foo,3
foo,2
bar,3
foo,1
bar,3
baz,1
bar,2
foo,0
baz,1
</csv>
(b) run
<hansl>
open mixed.csv
freq alpha
xtab num alpha
</hansl>
Now you can also do "boxplot num alpha --factorized" and have nice labels
on the x axis.
-------------------------------------------------------
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:24 a.m.
> 3. More integration of LaTeX. Maybe a LaTeX function like
gnuplot().
Allin and I weren't sure of what you meant exactly. We thought it might be a
nice idea to introduce a new function that, given a matrix, would return a
string with a complete LaTeX "tabular" environment. Would this be similar to
what you had in mind?
Well, I not too clear myself. Or more accurately, I am not sure what I have in mind could
be put in a single function. Two things would be nice: (1) just as you have stated, a
function that takes a matrix and returns a LaTeX "tabular" environment, but it
should be able to "display" a pdf or save a file with only the tabular block,
i.e. no preamble/begin & end document. (2) A function that can output the results of
any model estimation as a tabular environment or an equation.
Below is an example of a function I wrote to publish the results of a Variance Decomp. It
would be nice not to need to hard code this, but I do not see how you could automate
something like this??? Note: I use a couple of packages including booktab and calc, so
some of the LaTeX code might look weird.
<hansl>
function void FEVDTAB(bundle bARG, matrix matHrzns, string strFileName[null])
strFile = isnull(strFileName) ? "(a)workdir\fevd.tex" : strFileName
outfile "@strFile" --write
string strPeriod
if $pd = 1
strPeriod = "Years"
elif $pd = 4
strPeriod = "Quarters"
elif $pd = 12
strPeriod = "Months"
endif
string strTEMP0
string strTEMP1
string strTEMP2
loop i = 1..cols(matHrzns) --quiet
sprintf strTEMP0 "@strTEMP0c"
sprintf strTEMP1 "@strTEMP1 & %d @strPeriod", matHrzns[i]
sprintf strTEMP2 "@strTEMP2 & Ahead"
end loop
printf "\\begin{tabular}{l@strTEMP0}\n\\addlinespace\n\\toprule\n"
printf "@strTEMP1\\\\\n@strTEMP2\\\\\n\\midrule\n"
strTEMP0 = null
strTEMP1 = null
strTEMP2 = null
scalar intNVAR = bARG["nvar"]
matrix matFEVD = bARG["FEVD"]
matFEVD = matFEVD*100
loop i = 1..intNVAR --quiet
strTEMP0 = bARG["label$i"]
strTEMP2 = strlen(strTEMP2)>strlen(strTEMP0)?strTEMP2:strTEMP0
strTEMP1 = null
loop j = 1..cols(matHrzns) --quiet
sprintf strTEMP0 "@strTEMP0 & %.2f ",
matFEVD[matHrzns[j],(i*3)-2]
sprintf strTEMP1 "@strTEMP1 & (%.2f, %.2f) ",
matFEVD[matHrzns[j],(i*3)-1], matFEVD[matHrzns[j],(i*3)]
end loop
printf "@strTEMP0\\\\\n"
printf "@strTEMP1\\\\\\addlinespace\n"
end loop
strTEMP1 = strsub(strTEMP1, "&", "D")
printf "\\bottomrule\n"
printf "\\multicolumn{%d}{p{\widthof{@strTEMP2@strTEMP1}}}{Note: Numbers in
parentheses are the boundaries of the associated %d percent confidence
interval.}\\\\\n", cols(matHrzns)+1, (1-bARG["alpha"])*100
printf "\\end{tabular}"
outfile "@strFile" --close
end function
</hansl>
Cheers,
Logan
10 a.m.
On Thu, 28 Nov 2013, Logan Kelly wrote:
(2) A function that can output the results of any model estimation as
a
tabular environment or an equation.
I take it you are aware of the "tabprint" command. For more general
stuff, well... I personally can't see how one could make things much
easier, compared to to your function... ideas, anyone?
-------------------------------------------------------
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
-------------------------------------------------------
9:16 p.m.
On Wed, 27 Nov 2013, Sven Schreiber wrote:
Hi,
out of curiosity: what is still on the general to-do list for gretl 2.0?
I'm not talking about a wishlist for incremental features which will
always contain some items and will be added in point releases, but the
big picture -- I've heard there's ongoing work about multiprocessing
support, but apart from that I cannot think of anything fundamental that
is really missing, or is there?
Nice timing. Allin and I are, while I'm writing this, in the same room, so
I can speak for both. (In Edinburgh, if you're curious.)
There are many things that would have to be said in response to your
messsage; for example: yes, we're actively working on making it possible
to drive a massively multicore beast from hansl. The reason why I'm being
vague on this is that we're not yet sure of what the best way is to make
parallel cpus (if available on the hardware) available to the gretl user,
either through hansl or through the pre-canned procedures, so forgive me
if I'm scant on details.
The point you raise about accessing user-written procedures via generic
syntax constructs, such as "dash-dash" options is interesting, and I think
could be suitably generalised by saying (like you hint at by the end of
your message) "It'd be nice to have a syntax like stata has, where you can
call user-written stuff in a way that's sytactically undistinguishable
from in-built constructs". I personally agree that this is a goal well
worth pursuing.
Again: I won't go into details on this, but one of the things we plan to
do this week is to start working on a complete Backus-Naur representation
of hansl (that we don't have at the moment). Apart from making it possible
to re-implement a number of things more efficiently, it should give us a
much clearer idea on how to modify hansl for 2.0: what to add, what to
deprecate, what to modify, etcetera. Once you have hansl in Backus-Naur
form what you're suggesting should be feasible.
-------------------------------------------------------
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:25 p.m.
Am 27.11.2013 22:16, schrieb Riccardo (Jack) Lucchetti:
On Wed, 27 Nov 2013, Sven Schreiber wrote:
The point you raise about accessing user-written procedures via
generic
syntax constructs, such as "dash-dash" options is interesting, and I
think could be suitably generalised by saying (like you hint at by the
end of your message) "It'd be nice to have a syntax like stata has,
where you can call user-written stuff in a way that's sytactically
undistinguishable from in-built constructs". I personally agree that
this is a goal well worth pursuing.
Well yes, that's already a generalization of what I wrote, but of course
would be very nice.
Again: I won't go into details on this, but one of the things we plan to
do this week is to start working on a complete Backus-Naur
representation of hansl (that we don't have at the moment). Apart from
making it possible to re-implement a number of things more efficiently,
it should give us a much clearer idea on how to modify hansl for 2.0:
what to add, what to deprecate, what to modify, etcetera. Once you have
hansl in Backus-Naur form what you're suggesting should be feasible.
Had never heard of that BN form, briefly looked it up, indeed seems to
make extensions easier to handle... interesting.
I have no idea how time-consuming this internal change is; of course it
would be nice if gretl 2.0 could have it, but OTOH that could also be a
reason for a 3.0.
thanks,
sven
6:32 p.m.
On Thu, 28 Nov 2013, Sven Schreiber wrote:
> Again: I won't go into details on this, but one of the things
we plan to
> do this week is to start working on a complete Backus-Naur
> representation of hansl (that we don't have at the moment). Apart from
> making it possible to re-implement a number of things more efficiently,
> it should give us a much clearer idea on how to modify hansl for 2.0:
> what to add, what to deprecate, what to modify, etcetera. Once you have
> hansl in Backus-Naur form what you're suggesting should be feasible.
>
Had never heard of that BN form, briefly looked it up, indeed seems to
make extensions easier to handle... interesting.
I have no idea how time-consuming this internal change is; of course it
would be nice if gretl 2.0 could have it, but OTOH that could also be a
reason for a 3.0.
No, this is absolutely essential IMO. We're at a point when in order to
make any further significant progress, we have to clean things up
internally, and re-casting hansl in BNF is indispensable.
-------------------------------------------------------
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
-------------------------------------------------------
3800
days inactive
3801
days old
8 comments
3 participants
participants (3)
-
Logan Kelly -
Riccardo (Jack) Lucchetti -
Sven Schreiber