Am 19.09.2020 um 21:55 schrieb Allin Cottrell:
On Sat, 19 Sep 2020, Riccardo (Jack) Lucchetti wrote:
> I was thinking that there are quite a few things we should make
> decision on for the next version. One is exposing our time
> disaggregation apparatus (currently hidden as the _tdisagg()) function.
I'm in favour of that, and it's next on my agenda after getting regls
squared away (almost there, I think). Exposing tdisagg properly means
writing a decent GUI for it: shouldn't be too hard but it's always kinda
Who could be against new features? But the time-consuming aspect is the
key I guess. I think I would actually prefer to get a new release out
_with_ regls and _without_ tdisagg if the alternative is to wait much
longer for either. I mean regls (Lasso/Elanet) is already a big new
feature, so that would clearly be more than enough to warrant a new version.
Plus I think actually getting the join dialog to work on Windows is also
kind of important. Let me repeat that this has implications for the
actual GUI-usability of geoplot as well (again, on Windows).
> Another one is finally getting rid of tha arbond command.
I don't have strong feelings about that.
Me neither, in principle. However, I'm noting that there aren't any
deprecation warnings in the changelogs. In the command reference it just
says "please see dpanel for an updated and more flexible version".
I also just ran an arbond example and got no deprecation warning, so
removing it strikes me as quite sudden.
> On a more general level, now that Allin has implemented elastic
> too, should we have a "machine learning tools" submenu somewhere, with
> SVM, LASSO etc?
Maybe so. I hesitate just because it's not clear to what extent these
things can be represented in the GUI. SVM has no GUI at all at present.
regls (LASSO/Ridge/Elastic net) has a rudimentary GUI-in-progress, but
in neither case can you make serious use of these tools without
scripting (and setting up cross validation). There are too many
intricate and cross-linked options.
Well, maybe that's too strong a statement. Perhaps what I'm really
saying is that I dread designing and coding the highly complex GUI that
would be needed to enable serious use of machine learning via
point-and-click. It's a bit like trying to do a GUI for the Kalman
filter. OTOH, I guess it would be a good selling point if we took the
Good points. Those are the reasons why I thought that maybe a GTK tool
like the interface designer Glade could be something for gretl
development. However, as I've said before I've found it very hard to get
any kind of useful documentation or tutorial for it.
Apart from that, maybe regls could be handled somewhat like SVARs in
gretl: The GUI options could be quite limited, and then there would be
cross-references and hints that you need to do scripting to do more
flexible and advanced stuff.