7:02 p.m.
I'm thinking that at this point we have accumulated enough
fixes to warrant a new release. Any other thoughts on this?
http://gretl.sourceforge.net/ChangeLog.html
Allin
8:43 a.m.
Am 21.02.2012 20:02, schrieb Allin Cottrell:
I'm thinking that at this point we have accumulated enough
fixes to warrant a new release. Any other thoughts on this?
Just yesterday I thought about the discussion before the Torun
conference that gretl 2.0 was imminent... I have no problem with an
on-going business-as-usual because that business is running rather well,
but originally the plan seemed to be something different to me.
cheers,
sven
9:41 a.m.
On Wed, 22 Feb 2012, Sven Schreiber wrote:
Am 21.02.2012 20:02, schrieb Allin Cottrell:
> I'm thinking that at this point we have accumulated enough
> fixes to warrant a new release. Any other thoughts on this?
>
Just yesterday I thought about the discussion before the Torun
conference that gretl 2.0 was imminent... I have no problem with an
on-going business-as-usual because that business is running rather well,
but originally the plan seemed to be something different to me.
I don't think that 1.9.8 should be perceived as "two to go before 2.0";
nobody is preventing us from having 1.9.10 or 1.10.1.
That said, I think you're right; we should start setting our agenda for
2.0 for real (up to now things have been a bit fuzzy IMHO) and some
brainstorming would be good.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
3:22 a.m.
On Wed, 22 Feb 2012, Riccardo (Jack) Lucchetti wrote:
On Wed, 22 Feb 2012, Sven Schreiber wrote:
> Am 21.02.2012 20:02, schrieb Allin Cottrell:
>> I'm thinking that at this point we have accumulated enough
>> fixes to warrant a new release. Any other thoughts on this?
>
> Just yesterday I thought about the discussion before the Torun
> conference that gretl 2.0 was imminent... I have no problem with an
> on-going business-as-usual because that business is running rather well,
> but originally the plan seemed to be something different to me.
I don't think that 1.9.8 should be perceived as "two to go before 2.0";
nobody is preventing us from having 1.9.10 or 1.10.1.
That said, I think you're right; we should start setting our agenda for 2.0
for real (up to now things have been a bit fuzzy IMHO) and some brainstorming
would be good.
I know we discussed gretl 2.0 issues a while back, and I know I need
to re-read what was said then, so that previous work is not just
discarded. But in the meantime here are a few thoughts off the top
of my head.
One general question: do we want to make a big deal of gretl 2.0, or
do we want to "do a Linus"?
By "do a Linus" I'm referring to the fact that when Linus Torvalds
released version 3.0 of the Linux kernel, he was quite emphatic that
it contained nothing dramatically new: it was a regular update which
would have been numbered 2.6.34 except that Linus had got tired of
the endless 2.6.NN series and decided to rebase the numbering.
In gretl's case it would be quite natural to roll over from 1.9.9 to
2.0.0. As Jack says, we could instead roll to 1.10.0 (or 1.9.10) but
multi-digit minor numbers are perhaps a little unsightly and liable
to cause confusion in some contexts.
OK, so much for doing a Linus: what's the case for making 2.0 a real
milestone? (And deferring that milestone until something special is
ready.) I can see a few possibilities (there may be more). Version
2.0 should contain one or more of:
1) Major new functionality
2) Major changes in the GUI
3) A major backward-incompatible clean-up of hansl
4) A major change in the libgretl API, to make it easier for third
parties to use
5) A major purge of bugs and update/completion of documentation
My current thinking (sorry if this is disappointing!) is that number
5 provides the strongest case for a "2.0 milestone". Let's go
through the list.
* Major new functionality: Well, if we're talking C code, then at
present that means stuff that Jack and I will produce. I put my view
on this at the 2011 gretl conference: I think we now have a good
enough baseline that people ought to be able to add functionality to
gretl in the form of function packages and "addons". I certainly
stand ready to fix bugs and tweak the C code (including the GUI code
and the "gretl server" infrastructure) to make that easier. But
right now I myself have no plans to add major econometric
functionality in C form. Jack has been working on substantial new
stuff, but in the form of (brilliant) hansl code rather than C.
* Major changes in the GUI: That's up to me alone, and I have no
plans in that area. Nor do I expect to have time to implement truly
big ideas that others may come up with, though I'm always ready to
consider incremental improvements and bug fixes.
* Major backward-incompatible clean-up of hansl: consistency and
cleanliness are good, but so is continuing backward compatibility. I
can surely see a case for scrapping some archaisms. But I seem to
recall some folk wisdom from computer science: the production of a
backward-incompatible "cleaned up" version 2 of language L often
results in fragmentation of the user base and decline of L.
* Clean-up of the libgretl API: A good idea. But this can be done
without much (if any) change that is visible to users of gretl
itself, so it's probably not very pertinent to the "2.0" question.
* Purge of bugs and update/completion of documentation: Here I can
really get on board. One conception of gretl 2.0 is that it has
achieved a degree of maturity where we have squashed as many bugs as
we can find on an extended period of testing, and have documented in
a reasonably comprehensible and cross-referenced form all that the
program can do.
Allin
10:26 a.m.
New subject: time for 1.9.8? (long, I'm afraid)
On Thu, 23 Feb 2012, Allin Cottrell wrote:
I know we discussed gretl 2.0 issues a while back, and I know I need
to
re-read what was said then, so that previous work is not just discarded. But
in the meantime here are a few thoughts off the top of my head.
One general question: do we want to make a big deal of gretl 2.0, or do we
want to "do a Linus"?
[ ... ]
I don't think we are in the position to gallantly ignore the psychological
and image implications od a major version number change like Linus did.
Compared to Linux, I'd venture to say that gretl is a slightly less
recognisable brand.
In gretl's case it would be quite natural to roll over from 1.9.9
to 2.0.0.
As Jack says, we could instead roll to 1.10.0 (or 1.9.10) but multi-digit
minor numbers are perhaps a little unsightly and liable to cause confusion in
some contexts.
IMHO, there would be more confusion after "Linussing"; casual users would
simply go "WOW! Oh, wait... what...?"
OK, so much for doing a Linus: what's the case for making 2.0 a
real
milestone? (And deferring that milestone until something special is ready.) I
can see a few possibilities (there may be more). Version 2.0 should contain
one or more of:
1) Major new functionality
2) Major changes in the GUI
3) A major backward-incompatible clean-up of hansl
4) A major change in the libgretl API, to make it easier for third
parties to use
5) A major purge of bugs and update/completion of documentation
My current thinking (sorry if this is disappointing!) is that number 5
provides the strongest case for a "2.0 milestone". Let's go through the
list.
* Major new functionality: Well, if we're talking C code, then at present
that means stuff that Jack and I will produce. I put my view on this at the
2011 gretl conference: I think we now have a good enough baseline that people
ought to be able to add functionality to gretl in the form of function
packages and "addons". I certainly stand ready to fix bugs and tweak the C
code (including the GUI code and the "gretl server" infrastructure) to make
that easier. But right now I myself have no plans to add major econometric
functionality in C form. Jack has been working on substantial new stuff, but
in the form of (brilliant) hansl code rather than C.
Thanks for the kind words, but in my experience hansl is absolutely and by
far the best language to work in from an applied econometrician's
viewpoint, so producing nice hansl code for doing even hard stuff is
surprisingly easy.
You may think that mine is a slightly biased opinion, having contributed
to the creation of hansl itself: it's a bit like Linus Torvalds saying he
likes Linux or Larry Wall saying he prefers Perl to Python (cue to Sven to
start the flamefest). You'd probably be right, but let my add one element:
contrary to LT and LW, coding is not my job and I never even had a formal
training at that. What I do as a job is being an academic economist (and a
bass player, but I digress). I think I can claim I have a much better
understanding of the needs of the end user than LT or LW can have, because
I'm one of them!
And I think we can take as a fact that most applied economists learn how
to use _one_ econometrics package or perhaps two, depending on their field
of activity; some (surely not the majority) learn how to program in _one_
language; a few become proficient in that language; only a tiny minority
can claim to be at ease with more than one language. Older time-series
people like Gauss or Ox, younger fellows go with Matlab, the micro
community worships Stata, the eccentric brag about R, corporate
practitioners are not even aware that something else exists but Eviews,
some pockets of resistance still exist in the TSP mountains, etcetera. I
have some familiarity with all of these, and I'm ready to defend the point
that NOTHING BEATS HANSL.
There are only three areas in which I see the necessity of low-level code
work (but maybe I'm missing something):
a) Massive parallelisation is definitely the future of scientific
computation. So far, we have cautiously explored some possibilities, but
time will come when properly parallelising the internals of gretl will
become unavoidable. But that's not for 2.0; I see it more as a 3.0 thing.
b) Both hansl and gretl (heh) may strongly benefit from setting up an
infrastructure for managing data sets like Stata does. That is, do the
things that, ideally, you'd use a RDBMS for, but you can't ask an applied
economist to study SQL, can you? I'm talking about dataset merging,
splitting, sorting, variable/cases keeping/dropping, etcetera. Anybody
who's ever worked with large micro data bases knows exactly what I'm
talking about. Stata is, to my knowledge, the only econometrics package
that attempts to do this and does it, in my opinion, badly.
c) There may be the case for extending the way data are stored in gretl
from a double-only representation to a more general one. This would enable
us to have string and int variables. Allin and I talked a little about
this in Toruń, but this is HUGE. The project currently contains about
400,000 lines of C code, and my guesstimate is that at least half of this
would have to be thoroughly revised, if not rewritten. Allin already has
done some rationalisation work in libgretl which makes this a little
easier, but it's a loooooooong way away.
* Major changes in the GUI: That's up to me alone, and I have no
plans in
that area. Nor do I expect to have time to implement truly big ideas that
others may come up with, though I'm always ready to consider incremental
improvements and bug fixes.
100% agree. (Notice my elegant silence on the issue of decimal
separators.)
* Major backward-incompatible clean-up of hansl: consistency and
cleanliness
are good, but so is continuing backward compatibility. I can surely see a
case for scrapping some archaisms. But I seem to recall some folk wisdom from
computer science: the production of a backward-incompatible "cleaned up"
version 2 of language L often results in fragmentation of the user base and
decline of L.
IMO, it's a matter of common sense. We may scrap a few things that really
are obsolete, but that's it IMO.
* Clean-up of the libgretl API: A good idea. But this can be done
without
much (if any) change that is visible to users of gretl itself, so it's
probably not very pertinent to the "2.0" question.
* Purge of bugs and update/completion of documentation: Here I can really get
on board. One conception of gretl 2.0 is that it has achieved a degree of
maturity where we have squashed as many bugs as we can find on an extended
period of testing, and have documented in a reasonably comprehensible and
cross-referenced form all that the program can do.
Agree.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
2:13 a.m.
New subject: time for 1.9.8? (long, I'm afraid)
On Fri, 24 Feb 2012, Riccardo (Jack) Lucchetti wrote:
On Thu, 23 Feb 2012, Allin Cottrell wrote:
> I know we discussed gretl 2.0 issues a while back, and I know I need to
> re-read what was said then, so that previous work is not just discarded.
> But in the meantime here are a few thoughts off the top of my head.
>
> One general question: do we want to make a big deal of gretl 2.0, or do we
> want to "do a Linus"?
[ ... ]
I don't think we are in the position to gallantly ignore the psychological
and image implications od a major version number change like Linus did.
Compared to Linux, I'd venture to say that gretl is a slightly less
recognisable brand.
Well, you have a point there ;-)
> * Major new functionality: Well, if we're talking C code,
then at present
> that means stuff that Jack and I will produce. I put my view on this at the
> 2011 gretl conference: I think we now have a good enough baseline that
> people ought to be able to add functionality to gretl in the form of
> function packages and "addons". I certainly stand ready to fix bugs and
> tweak the C code (including the GUI code and the "gretl server"
> infrastructure) to make that easier. But right now I myself have no plans
> to add major econometric functionality in C form. Jack has been working on
> substantial new stuff, but in the form of (brilliant) hansl code rather
> than C.
Thanks for the kind words, but in my experience hansl is absolutely and by
far the best language to work in from an applied econometrician's viewpoint,
so producing nice hansl code for doing even hard stuff is surprisingly easy.
You may think that mine is a slightly biased opinion ...
Not at all, I agree entirely! But seriously, I take your point,
which strengthns the case for the fabled hansl guide. I've thought
about that too, but haven't yet managed to make a start on it.
There are only three areas in which I see the necessity of low-level
code
work (but maybe I'm missing something):
a) Massive parallelisation is definitely the future of scientific
computation. So far, we have cautiously explored some possibilities, but time
will come when properly parallelising the internals of gretl will become
unavoidable. But that's not for 2.0; I see it more as a 3.0 thing.
Agreed, on both counts.
b) Both hansl and gretl (heh) may strongly benefit from setting up an
infrastructure for managing data sets like Stata does. That is, do the things
that, ideally, you'd use a RDBMS for, but you can't ask an applied economist
to study SQL, can you? I'm talking about dataset merging, splitting, sorting,
variable/cases keeping/dropping, etcetera. Anybody who's ever worked with
large micro data bases knows exactly what I'm talking about. Stata is, to my
knowledge, the only econometrics package that attempts to do this and does
it, in my opinion, badly.
Interesting. We do have _some_ such functionality already: what
would you see as most important to add?
c) There may be the case for extending the way data are stored in
gretl from a double-only representation to a more general one.
This would enable us to have string and int variables. Allin and I
talked a little about this in Toruń, but this is HUGE. The project
currently contains about 400,000 lines of C code, and my
guesstimate is that at least half of this would have to be
thoroughly revised, if not rewritten. Allin already has done some
rationalisation work in libgretl which makes this a little easier,
but it's a loooooooong way away.
Yes, not for 2.0, I think. But I have thought about this a bit more,
and I'll share those thoughts before long.
> * Purge of bugs and update/completion of documentation: Here I
can really
> get on board. One conception of gretl 2.0 is that it has achieved a degree
> of maturity where we have squashed as many bugs as we can find on an
> extended period of testing, and have documented in a reasonably
> comprehensible and cross-referenced form all that the program can do.
Agree.
I think we may have something like a consensus that reasonably
complete documentation (plus whatever goodies we manage to introduce
between now and that point) would be a good excuse for moving the
pointer to 2.0.
Allin
10:45 a.m.
On 02/24/2012 04:22 AM, Allin Cottrell wrote:
On Wed, 22 Feb 2012, Riccardo (Jack) Lucchetti wrote:
* Major new functionality: Well, if we're talking C code, then at
present that means stuff that Jack and I will produce. I put my view
on this at the 2011 gretl conference: I think we now have a good
enough baseline that people ought to be able to add functionality to
gretl in the form of function packages and "addons".
I think that the "addon" feature alone is enough to justify a 2.0
version, because it fundamentally changes the way how gretl can receive
new functionality. This would be easy to communicate to old and new
users. As I see it, it is now in a state of beta testing, and calling
the version 2.0 would constitute the claim that it's reasonably stable.
And documented, see below.
* Purge of bugs and update/completion of documentation: Here I can
really get on board. One conception of gretl 2.0 is that it has
achieved a degree of maturity where we have squashed as many bugs as
we can find on an extended period of testing, and have documented in
a reasonably comprehensible and cross-referenced form all that the
program can do.
@bugs: I don't see how we will find bugs at an accelerated rate. Feature
freeze/extended testing is probably good because it means no new bugs.
@documentation: Here I would suggest some kind of realistic deadline and
individual commitments to certain missing parts. What do I mean by
realistic: in my case probably not before July (sorry! -- but it would
be a commitment).
And wrt Jack's mention of parallelism: Indeed, and I'm currently trying
to get into that from the Python side. Recent Matlab versions can pretty
straightforwardly use Nvidia GPUs already (the "Parallel" toolkit is
needed for that). I think it would be a good topic for a kind of
technical session at the next gretl conference.
cheers,
sven
2:16 a.m.
On Fri, 24 Feb 2012, Sven Schreiber wrote:
On 02/24/2012 04:22 AM, Allin Cottrell wrote:
> On Wed, 22 Feb 2012, Riccardo (Jack) Lucchetti wrote:
>
> * Major new functionality: Well, if we're talking C code, then at
> present that means stuff that Jack and I will produce. I put my view
> on this at the 2011 gretl conference: I think we now have a good
> enough baseline that people ought to be able to add functionality to
> gretl in the form of function packages and "addons".
I think that the "addon" feature alone is enough to justify a 2.0
version, because it fundamentally changes the way how gretl can receive
new functionality. This would be easy to communicate to old and new
users. As I see it, it is now in a state of beta testing, and calling
the version 2.0 would constitute the claim that it's reasonably stable.
And documented, see below.
Good point, I like it.
> * Purge of bugs and update/completion of documentation: Here I
can
> really get on board. One conception of gretl 2.0 is that it has
> achieved a degree of maturity where we have squashed as many bugs as
> we can find on an extended period of testing, and have documented in
> a reasonably comprehensible and cross-referenced form all that the
> program can do.
@bugs: I don't see how we will find bugs at an accelerated rate. Feature
freeze/extended testing is probably good because it means no new bugs.
For my part, coding time has to be divided between new stuff and bug
fixing. So the less new stuff that's going on, the more time for
fixing.
@documentation: Here I would suggest some kind of realistic deadline
and
individual commitments to certain missing parts. What do I mean by
realistic: in my case probably not before July (sorry! -- but it would
be a commitment).
Any suggestion for a realistic deadline?
Allin
5:24 p.m.
One general question: do we want to make a big deal of gretl 2.0, or
do we want to "do a Linus"?
I think a Linus is fine. The evolution of gretl is steady and a lot has
changed from say 1.7 to 1.9.7
1) Major new functionality
2) Major changes in the GUI
3) A major backward-incompatible clean-up of hansl
I agree with Alin completely here.
4) A major change in the libgretl API, to make it easier for third
parties to use
* Major new functionality: Well, if we're talking C code, then
at
present that means stuff that Jack and I will produce. I put my view
on this at the 2011 gretl conference: I think we now have a good
enough baseline that people ought to be able to add functionality to
gretl in the form of function packages and "addons". I certainly
stand ready to fix bugs and tweak the C code (including the GUI code
and the "gretl server" infrastructure) to make that easier. But
right now I myself have no plans to add major econometric
functionality in C form. Jack has been working on substantial new
stuff, but in the form of (brilliant) hansl code rather than C.
The main estimators "missing" are the various simulated mle and such.
gretl is already competent in the main categories, wls, iv, gmm, mle, nls.
This is not a big deal for me, but as models get fancier, these
techniques will be used more. Whether this is better done as an addon or
in C I can't say.
* Major changes in the GUI: That's up to me alone, and I have no
plans in that area. Nor do I expect to have time to implement truly
big ideas that others may come up with, though I'm always ready to
consider incremental improvements and bug fixes.
The biggest problem I have with the GUI is window proliferation. As it
is now, in
a few minutes you end up with a dozen open windows to sort
through and this is clunky. Is there a way to introduce tabs into the
script editor and perhaps the output windows? So, for instance, the script
editor contains tabs for each open script. Ditto for the model output
windows. I realize that the session concept is a good way to organize the
models, but tabs would be good as well. Being able to dock the main
window, the console, and tabbed output window would be very nice.
* Major backward-incompatible clean-up of hansl: consistency and
cleanliness are good, but so is continuing backward compatibility. I
can surely see a case for scrapping some archaisms. But I seem to
recall some folk wisdom from computer science: the production of a
backward-incompatible "cleaned up" version 2 of language L often
results in fragmentation of the user base and decline of L.
It is ok as is. As conflicts arise, they do get taken care of.
* Clean-up of the libgretl API: A good idea. But this can be done
without much (if any) change that is visible to users of gretl
itself, so it's probably not very pertinent to the "2.0" question.
* Purge of bugs and update/completion of documentation: Here I can
really get on board. One conception of gretl 2.0 is that it has
achieved a degree of maturity where we have squashed as many bugs as
we can find on an extended period of testing, and have documented in
a reasonably comprehensible and cross-referenced form all that the
program can do.
This should be the first priority. The documentation is excellent in what
it covers, but it suffers three problems.
1. It is not complete.
2. It is hard to use because it is not sufficiently
cross-referenced. Half the stuff I'm looking for is covered in the User
Guide the other half in the Command Reference and they don't communicate
with each other. There are also the example scripts, many of which are
undocumented, that should be cross-referenced in both places.
3. It is not easy for potential contributors to add tthings. It might
be useful to consider some sort of structure for writing and reviewing new
documentation. This is not a trivial pursuit by any means. Consistency of
terms and notation across such a large swath of econometric practice not a
easy thing to accomplish. Open source documentation can be horrible
(witness R). Gretl, for what it has, is good. We're just not taking much
advantage of the openness ... which as R demonstrates, is not without
problems. Cross-referencing and openness, though not incompatible, are
certainly not going to be easy to do without some commitment.
Should the User Guide be modularlized in order to make it easier to add
entries to the Econometric Methods section?
I'd like to see a way to add documented examples that can be accessed from
links with the command and the user reference. We've already got some nice
examples in the program itself, but they need some words to go with the
hansl code, IMO. As an example, if I open the command reference and click
on leverage, I'm taken to some stuff that comes from the Command Reference
document. At the bottom, there should be links to the relevant entries in
the User Guide and to the leverage.inp script. Also, the leverage script
example should be discussed in the User Guide. This is bound to make
translations harder.
The only other canned software I'm using these days is Stata (and R, only
if I absolutely must). So, I'm not familiar with how Eviews, Limdep, SAS,
or other econometric software is documented. The documents in Stata are
very good. The examples help a lot. Stata's findit command is magical.
Cheers All,
Lee
PS I suppose it's about time for me to start working on the next
conference. Ignacio sent me a to do list a couple of months ago, and
despite his kind urging and support, I've been in complete denial about my
impending role. I hope to meet with our extension director next week to
get the ball rolling.
FWIW, we hosted a very large (well 200+ attendees) marketing conference
last year and managed to do it in Stillwater. Here's the PR department's
take on it:
http://spears.okstate.edu/news/2011/06/28/osu-hosts-prestigious-amasheth-...
. We
sent vans to OKC or Tulsa to retrieve folks from the airport. A lot will
depend on finances -- hosting here may cost less and I might be more likely
to get the Dean to cough up some support. I'll know more by the end of the
month. Any thoughts?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Lee Adkins
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com
5:48 p.m.
On Fri, 24 Feb 2012, Lee Adkins wrote:
Is there a way to introduce tabs into the script editor and perhaps
the
output windows? So, for instance, the script editor contains tabs for
each open script.
Excellent idea. I love it.
This should be the first priority. The documentation is excellent in
what
it covers, but it suffers three problems.
[...]
Make this four: we urgently need an authoritative, reasonably complete,
reasonably stand-alone hansl manual. I've been trying to get started on
this several times, but it's harder than I'd thought.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
2:27 a.m.
On Fri, 24 Feb 2012, Lee Adkins wrote:
The main estimators "missing" are the various simulated mle
and such.
gretl is already competent in the main categories, wls, iv, gmm, mle, nls.
This is not a big deal for me, but as models get fancier, these
techniques will be used more. Whether this is better done as an addon or
in C I can't say.
There may well be a case for MCMC in C.
> * Major changes in the GUI [...]
>
> The biggest problem I have with the GUI is window proliferation. As it
is now, in a few minutes you end up with a dozen open windows to sort
through and this is clunky. Is there a way to introduce tabs into the
script editor and perhaps the output windows?
That's worth thinking about and experimenting with, yes.
> * Purge of bugs and update/completion of documentation: Here I
can
> really get on board. One conception of gretl 2.0 is that it has
> achieved a degree of maturity where we have squashed as many bugs as
> we can find on an extended period of testing, and have documented in
> a reasonably comprehensible and cross-referenced form all that the
> program can do.
>
>
This should be the first priority. The documentation is excellent in what
it covers, but it suffers three problems.
1. It is not complete.
2. It is hard to use because it is not sufficiently
cross-referenced. Half the stuff I'm looking for is covered in the User
Guide the other half in the Command Reference and they don't communicate
with each other.
Agreed, but unfortunately it's hard if not impossible to get
seamless cross-referencing across distinct PDF files. Does anyone
have a suggestion other than creating a whopping great PDF
containing both the Guide and the Reference?
Should the User Guide be modularlized in order to make it easier to
add
entries to the Econometric Methods section?
Well, those "methods" chapters are separate TeX files, so I'd say
it's pretty much modular as is: it's trivial to drop in a new
chapter if one becomes available.
I'd like to see a way to add documented examples that can be
accessed from
links with the command and the user reference.
There should be some PDF magic that makes that possible. Any PDF
jockeys out there?
Allin
3:05 a.m.
Hi,
On Sat, Feb 25, 2012 at 2:27 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Fri, 24 Feb 2012, Lee Adkins wrote:
> The main estimators "missing" are the various simulated mle and such.
> gretl is already competent in the main categories, wls, iv, gmm, mle, nls.
> This is not a big deal for me, but as models get fancier, these
> techniques will be used more. Whether this is better done as an addon or
> in C I can't say.
There may well be a case for MCMC in C.
Translation, please.
Agreed, but unfortunately it's hard if not impossible to get
seamless cross-referencing across distinct PDF files. Does anyone
have a suggestion other than creating a whopping great PDF
containing both the Guide and the Reference?
I suggest TEX2HTML or something like
that.
You would still author in TEX and produce HTML (both online and offline).
I am not talking by experience, but willing to investigate.
> Should the User Guide be modularlized in order to make it easier
to add
> entries to the Econometric Methods section?
Well, those "methods" chapters are separate TeX files, so I'd say
it's pretty much modular as is: it's trivial to drop in a new
chapter if one becomes available.
> I'd like to see a way to add documented examples that can be accessed from
> links with the command and the user reference.
There should be some PDF magic that makes that possible. Any PDF
jockeys out there?
Done some work in this area with professional software and Open
Office.
Is the idea if open the example in Gretl from a link in the document?
Hélio
4:12 a.m.
On Sat, 25 Feb 2012, Hélio Guilherme wrote:
On Sat, Feb 25, 2012 at 2:27 AM, Allin Cottrell
<cottrell(a)wfu.edu> wrote:
> On Fri, 24 Feb 2012, Lee Adkins wrote:
>
>> The main estimators "missing" are the various simulated mle and such.
>> gretl is already competent in the main categories, wls, iv, gmm, mle, nls.
>> This is not a big deal for me, but as models get fancier, these
>> techniques will be used more. Whether this is better done as an addon or
>> in C I can't say.
>
> There may well be a case for MCMC in C.
Translation, please.
Sorry, I was thinking of Markov Chain Monte Carlo simulation.
> Agreed, but unfortunately it's hard if not impossible to get
> seamless cross-referencing across distinct PDF files. Does anyone
> have a suggestion other than creating a whopping great PDF
> containing both the Guide and the Reference?
I suggest TEX2HTML or something like that.
You would still author in TEX and produce HTML (both online and offline).
I am not talking by experience, but willing to investigate.
We could produce an HTML version of the Guide, yes, but IMO PDF is
much nicer to read; also the Guide contains some fairly complex
mathematical notation that is unlikely to work properly.
>> I'd like to see a way to add documented examples that can
be accessed from
>> links with the command and the user reference.
>
> There should be some PDF magic that makes that possible. Any PDF
> jockeys out there?
Done some work in this area with professional software and Open Office.
Is the idea if open the example in Gretl from a link in the document?
Yes, that's the idea. Since you can do javascript in PDF it
shouldn't be a big problem. Except that we'd probably want some
"client" mechanism for gretl so that the instruction would be:
launch gretl to open this script, or if gretl is already running,
tell the running gretl to open the script. Right now you can't do
the latter... unless you could somehow "fake" a drag-and-drop, I
wonder if that's possible?
Allin
11:15 a.m.
For what it's worth, I think (1) tabs in GUI and (2) mature and
reliable platform for developing addon packages are really 2 nice
features that can alone justify a 2.0 release (along with a few
goodies). Unfortunately (but as always) the resources are limited.
At this point I would like to ask: Is there a standard way or support
for translating function packages? If not, this may be a good time to
introduce that facility.
I know I have not been able to provide help as much as I want to
(other than translating and bug reporting). This is due to ongoing
tenure applications and other institutional limitations associated
with being a young academician. But I hope to be able to contribute
more over time.
Cheers
Talha
On Sat, Feb 25, 2012 at 6:12 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Sat, 25 Feb 2012, Hélio Guilherme wrote:
> On Sat, Feb 25, 2012 at 2:27 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
>>
>> On Fri, 24 Feb 2012, Lee Adkins wrote:
>>
>>> The main estimators "missing" are the various simulated mle and
such.
>>> gretl is already competent in the main categories, wls, iv, gmm, mle,
>>> nls.
>>> This is not a big deal for me, but as models get fancier, these
>>> techniques will be used more. Whether this is better done as an addon
>>> or
>>> in C I can't say.
>>
>>
>> There may well be a case for MCMC in C.
>
> Translation, please.
Sorry, I was thinking of Markov Chain Monte Carlo simulation.
>> Agreed, but unfortunately it's hard if not impossible to get
>> seamless cross-referencing across distinct PDF files. Does anyone
>> have a suggestion other than creating a whopping great PDF
>> containing both the Guide and the Reference?
>
> I suggest TEX2HTML or something like that.
>
> You would still author in TEX and produce HTML (both online and offline).
> I am not talking by experience, but willing to investigate.
We could produce an HTML version of the Guide, yes, but IMO PDF is much
nicer to read; also the Guide contains some fairly complex mathematical
notation that is unlikely to work properly.
>>> I'd like to see a way to add documented examples that can be accessed
>>> from
>>> links with the command and the user reference.
>>
>>
>> There should be some PDF magic that makes that possible. Any PDF
>> jockeys out there?
>
>
> Done some work in this area with professional software and Open Office.
> Is the idea if open the example in Gretl from a link in the document?
Yes, that's the idea. Since you can do javascript in PDF it shouldn't be a
big problem. Except that we'd probably want some "client" mechanism for
gretl so that the instruction would be: launch gretl to open this script, or
if gretl is already running, tell the running gretl to open the script.
Right now you can't do the latter... unless you could somehow "fake" a
drag-and-drop, I wonder if that's possible?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
3:14 a.m.
> I'd like to see a way to add documented examples that can be accessed
from
> links with the command and the user reference.
There should be some PDF magic that makes that possible. Any PDF
jockeys out there?
Allin
_______________________________________________
I'll look into this. I don't think that Stata's pdf's link to one
another
either (which suggests a limitation), but the html links to relevant pages
in each of the manuals. Maybe we need a master keyword list (html) with
links to relevant pages in the manuals and examples? It is certainly more
predictable to do mathematics in pdflatex. The solution may be to work on
the html side of things to link to pdf pages ....
Lee
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com
5:48 p.m.
In some sort this is point 5:
5) A major purge of bugs and update/completion of documentation
Some users are not comfortable with using mail-lists. Maybe it's better
to make an agreement to use some existing statistics/econometrics forum
for posting questions and answers about gretl there? For example, one
may use http://stats.stackexchange.com/ - it even has a tag "gretl", but
only one message under it :).
I am not promoting any particular forum, my point is that using some
existing popular forum will increase gretl's popularity as a side effect.
Best,
Boris Demeshev
4744
days inactive
4749
days old
15 comments
7 participants
participants (7)
-
Allin Cottrell -
Boris Demeshev -
Hélio Guilherme -
Lee Adkins -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Talha Yalta