Request for Comments: gnuplot and foreign
by Riccardo (Jack) Lucchetti
Gretl has used gnuplot for all its graphical output since the dawn of
time. Some people find gnuplot's output ugly, but that's highly subjective
IMO; as far as I'm concerned, I simply love it; I certainly wouln't trade
the austere beauty of a line graph like gretl produces with a cheap
alternative sporting grossly fatter lines in a tacky light blue frame.
We also go to great lengths to make gnuplot's output customisable from our
GUI client, and it's a great credit to Allin's committment and ingenuity
that most GUI users don't even realise that their graphs are in fact
produced by a piece of software other than gretl.
Our relationship with gnuplot, when it comes to scripting, is a bit more
awkward. We have one command (the 'gnuplot' command) for doing most
things, and its syntax has been expanding over time in order to
accommodate more and more flexibility. In fact, now that we have the
--input option, a hansl script writer has at her disposal the potential
for producing masterpieces such as those found at
http://gnuplot.sourceforge.net/demo_4.6/ if necessary.
However, this implies writing functions in which, basically, we issue
strings into a file that is then re-used as input by gnuplot. The funny
thing is, we already have a "foreign" environment that does basically the
same job for statistical packages.
It could perhaps be advisable to extend the "foreign" command to drive
gnuplot in a more transparent way than we do now, and at the same time
take advantage of a change scheduled for gnuplot 5.0 (which should be in a
cinema near you real soon): "Command scripts may place in-line data in a
named data block for repeated plotting." This would make it possible to
pass data to gnuplot in a clean and efficient way.
The big difference with other "foreign" environments would be that it's
highly likely that a script writer might want to pass to gnuplot strings
as well as data. So, we could imagine a situation in which we pass bundles
and have something like
<pseudo-hansl>
bundle to_gp = null
to_gp["foo"] = X
to_gp["bar"] = "A string"
foreign language=gnuplot --data=to_gp
...
end foreign
</pseudo-hansl>
Being able to do something like this would reduce the need for supporting
the rather byzantine syntax we now have for the "gnuplot" command, which
could be much simplified with some options deprecated.
How do you like the idea?
-------------------------------------------------------
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 years, 11 months
Re: [Gretl-devel] New Topic: Connecting gretl with external databases!
by Konstantinos Kaleris
Dear Rickardo, Ignacio,
thank's a lot for your replies! So if I understand correctly from you answers and from the FRB, FRED and NBER README files, in case of external databases there are two options..
1. download the files from the db first and then put the data in .idx and .bin files for gretl to read.
2. use ODBC to connect directly to the database and execute queries from Gretl.
The gretl manual describes the following way to open a connection using the dsn of the database, along with a username and a password.
open dsn=database [user=username] [password=password] --odbc
I guess then for the second method one has to contact the database admin. and ask for the dsn and the permissions to get access to the database. The dsn, among others, would include the address over a TCP/IP protocol... Is that right?
@Ignacio: I understand that the number of databases would get crazily high for central maintenance if everybody added his own database on the list. But maybe if the Greek people would need a Spanish database, then they could ask the Spanish people for the details and add the Spanish database on their local list. However still statistics that refer to broader audience, i.e. the US or Europe, Asia etc. could remain on the default list or so....
@Ricardo: I can almost see you guys there in Ancona from my balcony :)
Thanks again!!
Konstantinos
Firma Arista
11 years
New Topic: Connecting gretl with external databases!
by Konstantinos Kaleris
Dear gretl developers,
greetings from Patras, Greece, from a small workgroup that was formed in the frame of a seminar regarding open source software at the University of Patras.
In the case of our group, the task is to extend gretl according to the needs of our work, hoping that other people would also find these features useful.
Our first attempt would be to extend the database list and provide users with the possibility to access data from some other statistics sources - especially at first containing greek/european data. As we understood so far, ODBC provides an interface for gretl to interact with database servers and that the databases provided in the default installation of gretl reside on a database server dedicated to gretl. We would like to investigate the possibility of accessing databases that reside on other/external servers. This email is an attempt to make a first contact and see if there is anybody who has experience from similar tasks and could possibly give us hints on the process!! For a reply we would be glad. And we hope to be able soon to contribute to the gretl community!
Thank you for your time and wishes for a nice evening (or morning??)
Konstantinos, Vasia, Vaggelis
11 years
bug in modtest --autocorr
by Artur T.
Hi,
I found a bug in the modtest command. In the attached example you'll see
that the obtained test statistics for serial correlation of order one is
different when the --silent option is used.
I using current cvs on Linux.
Artur
<hansl>
set echo off
set messages off
open denmark.gdt -q
ols LRM 0 LRY IDE --quiet
modtest 1 --autocorr
scalar sc1 = $test
modtest 4 --autocorr
scalar sc4 = $test
printf "Test stats: SC1=%.3f SC4=%.3f\n", sc1, sc4
# The same using option --silent
ols LRM 0 LRY IDE --quiet
modtest 1 --autocorr --silent
scalar sc1 = $test
modtest 4 --autocorr --silent
scalar sc4 = $test
printf "\nTest stats: SC1=%.3f SC4=%.3f\n", sc1, sc4
</hansl>
11 years
syntax suggestion for append to string
by Sven Schreiber
Hi,
in hansl we concatenate strings with "~" and not "+" (which is an offset
specification). But then why do we have to use "+=" to append to a
string and not "~="? I find this confusing and always get this wrong. Is
it just me or could we introduce the syntax "~=" for strings? AFAICS
this would just be syntactic sugar without side effects, right?
thanks,
sven
11 years
Post-doc position available in Ancona
by Riccardo (Jack) Lucchetti
Attention gretlers:
A post-doc position will be available soon here in Ancona: the idea is to
work together with me and Allin on a brand new, completely redesigned
hansl interpreter.
Candidates should be very good coders, ideally with a good background in
compiler design, gramars, BNF and all that, but budding econometricians
with strong computational skills may also be perfectly suitable for the
job.
I'll post a link to the actual application webpage as soon as it's
available. In the meantime, think about it and spread the word among your
CompSci friends!
-------------------------------------------------------
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 years
Sugestion: new function called varnames
by Logan Kelly
Hello,
Quick suggestion. Could a function called varnames() be added that is like varname() except it returns an array with the names of variables in a list. For example:
<hansl>
function strings varnames(list in)
#Returns an array of strings containing the names of each variable in a list
catch strings ret = strsplit(strsub(varname(in),","," "))
if $error != 0
strings ret
string errormesage = errmsg($error)
print errormesage
endif
return ret
end function
</hansl>
Just a thought.
Logan
11 years, 1 month
devel news II
by Allin Cottrell
OK, maybe I should give some idea of what to expect from the new
parser, when it comes on line.
1) It will be a lot easier to maintain (admittedly, not something
users will see directly).
2) It will check the syntax of hansl commands much more rigorously.
This is a benefit which might hurt a little at first ;-) Here are
some examples:
* The old parser sloppily accepted some quoted strings where the
quotation was never actually closed, as in
print "This is a string
Not any more!
* While the old parser mostly checked for _absence_ of required
elements on the command line, it wasn't properly equipped to check
for the _presence_ of syntactical "junk". E.g.
print "This is a string")
The extraneous ')' here will now cause an error. For another
example, consider
end mle @foo
at the end of an mle block. The idea is clear enough, "@foo" is
being used for string substitution, perhaps to add the --verbose
option or not depending on how the string named foo is defined. But
suppose there is in fact no string named foo in scope. The old
parser would happily ignore the undigested "@foo" at the end of the
line; the new one will not.
(The above examples are based on real-world cases from contributed
function packages.)
3) The main benefit that should eventually be visible to users is
the potential for substantial speed-up of big scripts. I say
"potential" here: in the first instance I don't expect much impact
on speed -- some scripts may go faster, some may go a little slower.
But the way the new parser works, it will create the possibility for
pre-parsing an entire hansl script, including both loops and any
functions called, and I expect a major speed-up for complex scripts
from that, when we get to it.
Allin
11 years, 1 month
