Gretl project on the launchpad
by Ivan Sopov
Hello, gretl developers.
I'm trying to start a translation of help files into russian on
launchpad.net as it seems to be the most suitable tool to participate
for all familiars with econometrics but not with gettext, linux. cvs,
etc.
The problem is that there is already a project for gretl on launchpad
and it is strongly prohibited to start more than one project for a
single program. I cannot contact with Constantine Tsardounis for about
a month, so I think it is time to re-assign that project to someone
else. On the irc-channel of launchpad I was told that
Our admins can re-assign the project to new owners but we'd prefer to
hear from the upstream owners. can you get one of them to submit a
question here:
https://answers.edge.launchpad.net/launchpad
But if nobody from main developers wants to register and do something
at launchpad it is possible to assign this function to me and in that
case a letter in this list will probably be enough.
I have prepared a .po-file for genr_funcs.xml and gretl_commands.xml
with the help of po4a utility and got 1511 strings for translation
(strings a rather big).
Good luck, Ivan Sopov.
P.S. My previous letter about using launchpad for translation is
http://lists.wfu.edu/pipermail/gretl-devel/2009-November/002171.html
11 years, 9 months
gretl and openmp
by Allin Cottrell
As some of you know, we're currently experimenting with openmp in
gretl. When building from CVS, use of openmp is the default (if
openmp is supported on the host) unless you pass the option
--disable-openmp to the configure script. In addition the current
snapshots for Windows and OS X are built with openmp support
(using gcc 4.4.3 and gcc 4.2.4 respectively).
This note is just to inform you about the state of play, and to
invite submission of test results if people would like to do that.
Right now, we use openmp only for gretl's native matrix
multiplication. So it'll get used (assuming you have at least two
cores) if you do matrix multiplication in a script, or call a
function that does matrix multiplication (such as qform), or use a
built-in command that happens to call matrix multiplication. If we
decide it's a good idea, we could use openmp directives in other
gretl code (but as along as we rely on lapack for much of our
number-crunching, and as long as lapack is not available in a
parallelized form, the scope for threading will remain somewhat
limited).
In a typical current use situation, with gretl running on a
dual-core machine where there's little other demand being placed
on the processors, the asymptotic speed-up from openmp should be
close to a factor of two. However, it takes a big calculation to
get close to the asymptote, and we've found that with small to
moderate sized matrices the overhead from starting and stopping
threads dominates, producing a slowdown relative to serial code.
This is similar to what we found with regard to the ATLAS
optimized blas; see
http://ricardo.ecn.wfu.edu/~cottrell/tmp/gretl_speed.html
Anyway, in case anyone would like to test I'm attaching a matrix
multiplication script that Jack wrote. Right now this is mostly
useful for people building gretl from source, since you want to
run timings both with and without MP, which requires rebuilding.
But if you're currently using a snapshot from before yesterday
(build date 2010-03-21 or earlier) you could run the script, then
download a current snapshot and run it again.
Allin
13 years, 1 month
gretl source update
by Allin Cottrell
If anyone who's in the habit of using gretl CVS wants the latest
and greatest while sourceforge is out of action, please see
http://www.wfu.edu/~cottrell/tmp/
Please read the README file before doing anything else,but if you
were up to date with CVS as of January 25 you _might_ want to
apply the source patch in gretl-2011-01-27.tgz.
Be aware that updating in this way might create some "issues" when
SF CVS comes back online and you try to update in the usual way.
You should probably not apply the patch unless you know how to
handle CVS "conflicts". (Short version of handling conflicts:
delete your local version of the conflicted file and try "cvs
update" again.)
Allin Cottrell
13 years, 5 months
Re: [Gretl-devel] function calling and value copies
by Allin Cottrell
On 01/22/2011 01:27 PM, Riccardo (Jack) Lucchetti wrote:
> On Sat, 22 Jan 2011, Riccardo (Jack) Lucchetti wrote:
>
>> On Sat, 22 Jan 2011, Sven Schreiber wrote:
>>
>>> The funny thing is that the first version of the code that copies
>>> the
>>> generated number to the variable 'temp' is about 50% slower than the
>>> version without such copying!
>>
>> Confirmed here. I'll look into this.
>
> From some preliminary analysis, the difference seems to come from
> the fact that assigning the result to a variable avoids calling
> is_gretl_function_call() at line 2369 of lib/src/interact.c; this,
> in turn, saves calls to sscanf(), which is quite expensive. Mumble
> mumble.
If you replace
muniform(1,1)
with
eval muniform(1,1)
then it runs faster than the version with copying. The sooner
gretl can figure out what you want, the faster.
Allin
13 years, 6 months
Re: [Gretl-devel] [Gretl-users] variable types in different scripts
by Allin Cottrell
On 01/22/2011 01:52 PM, Sven Schreiber wrote:
> [I]t should be acknowledged that it is a real
> limitation of gretl to have only global variables (apart from the
> function scope), not to turn that around into a feature.
In my view the gretl script is an arbitrary textual unit, and
it does not make sense to limit the scope of variables based
on the script.
I can see a case for local variables, but these should be local
to non-arbitrary code blocks. For example it would be quite nice
to be able to say, within a loop or an if-block for example,
local matrix foo = whatever
so that the object would be destroyed automatically on exit
from the block. But scripts are not (logically) code blocks.
Allin
13 years, 6 months
Re: [Gretl-devel] [Gretl-users] variable types in different scripts
by Sven Schreiber
[moving over to gretl-devel, where I probably should have started this
anyway]
Am 21.01.2011 17:39, schrieb Riccardo (Jack) Lucchetti:
> On Fri, 21 Jan 2011, Sven Schreiber wrote:
>
> A few remarks:
>
> * We don't have "clear", which would probably be nice, but we have
> "nulldata": "nulldata 2" probably does what you want.
Yeah, except that it also clears the dataset, which is maybe not what I
want. Maybe 'nulldata' could be merged into a new 'clear' somehow?
clear --data # like nulldata --preserve
clear --all # like nulldata
clear # only clear variables like matrices, scalars, bundles,
strings, lists(?)...
???
(This is clearly a suggestion I only dare making in the context of the
pre-2.0 cycle, in general I would find it too disruptive.)
>
> * The relative merits of strong typing vs weak typing will always be an
> object for discussion. I personally prefer strong typing, but I concede
> that in a world where the most popular matrix-oriented languages are
> weakly-typed perhaps you have a point.
My point was not against strong typing in this context (although it
helped to trigger the error here, of course). It would be fine if in the
scope of the script the type of temp were fixed (strong typing). I'm
pointing out the problems of the fact that the scope of the variable
temp is automatically global, i.e. extends beyond the current script.
>
> * I would guess that if you have scripts that are meant to be run one
> after another with little or no editing, perhaps you ought to use
> functions and keep the usage of global variables at a minimum. Perhaps
> bundles may help too.
AFAICS this essentially would imply that *everything* needs to be
wrapped inside functions. I don't think that would be good. Note I
didn't *want* to make thiese variables global, but with gretl's current
behavior I don't have a choice (if I don't want to wrap everything in a
function); so I view your statement "keep global variables at a minimum"
as supporting my point!
thanks,
sven
13 years, 6 months
Re: [Gretl-devel] [Gretl-users] variable types in different scripts
by Allin Cottrell
On Sat, 22 Jan 2011, Riccardo (Jack) Lucchetti wrote:
> On Sat, 22 Jan 2011, Sven Schreiber wrote:
>
> > [moving over to gretl-devel, where I probably should have started this
> > anyway]
> >
> > Am 21.01.2011 17:39, schrieb Riccardo (Jack) Lucchetti:
> >> On Fri, 21 Jan 2011, Sven Schreiber wrote:
> >
> >>
> >> A few remarks:
> >>
> >> * We don't have "clear", which would probably be nice, but we have
> >> "nulldata": "nulldata 2" probably does what you want.
> >
> > Yeah, except that it also clears the dataset, which is maybe not what I
> > want.
I think a "clear" command might be quite useful (we have "dataset
clear" but it's somewhat hard to find). To keep things reasonably
simple, I'd suggest that it has three forks:
* default, no options: clears everything
* --dataset: clears the dataset only, leaves matrices etc.
* --other: clears everything other than the dataset.
Now "other" may not be the greatest label (suggestions welcome),
but I'm not keen to add a slew of specific options (matrices,
scalars, bundles, strings and so on, for clearing).
Allin
13 years, 6 months
function calling and value copies
by Sven Schreiber
Hi,
in the context of analyzing the random-number generation in gretl I was
trying to check the overhead of copying the generated values to a
(temporary) variable. I've done this with the following script:
<script>
set echo off
set messages off
total = 1e6
printf "with variable copying.\n"
temptimer = 0
loop total --quiet
set stopwatch # only measure the function itself
scalar temp = muniform(1,1)
temptimer += $stopwatch
end loop
printf " this iteration run time: %f\n", temptimer
print "---------------------"
printf "no variable copying.\n"
temptimer = 0
loop total --quiet
set stopwatch
muniform(1,1)
temptimer += $stopwatch
end loop
printf " this iteration run time: %f\n", temptimer
print "---------------------"
</script>
The funny thing is that the first version of the code that copies the
generated number to the variable 'temp' is about 50% slower than the
version without such copying! See the results below:
gretl-Version 1.9.3cvs
Aktuelle Sitzung: 2011-01-22 18:43
? set echo off
with variable copying.
this iteration run time: 10.310000
---------------------
no variable copying.
this iteration run time: 14.860000
---------------------
Is this expected or is there an unintended thing going on within gretl?
thanks,
sven
13 years, 6 months
Re: [Gretl-devel] [Gretl-users] variable types in different scripts
by Sven Schreiber
Am 21.01.2011 21:43, schrieb Allin Cottrell:
> On Fri, 21 Jan 2011, Sven Schreiber wrote:
>>
>> (BTW, I know that the 'open' command clears gretl's workspace, which
>> would probably be the solution here. But I find myself doing more and
>> more with gretl's nice matrix language without opening datafiles. So
>> maybe a 'clear' command is needed?)
>
> "dataset clear" will do the job.
>
Ok, this is like Jack's 'nulldata' suggestion. So suppose I do have a
dataset open (contrary to what I said above, I know) and don't want to
lose it. For the rest see the other email I just wrote about the topic.
-sven
13 years, 6 months
user-defined functions and smpl
by Allin Cottrell
As you probably know, we've emphasized the principle of
"encapsulation" for user-functions in gretl. One aspect of this is
that if the dataset is sub-sampled (non-contiguous observations
have been selected on some boolean criterion) on entry to a
function, you can't "un-subsample" inside the function (i.e. "smpl
full" will not give you the entire dataset as it exists at caller
level). This seems to me appropriate and I don't propose changing
it.
But we've also applied this principle to "regular" smpl setting,
where you just shift the end-points of the sample. To explain:
suppose we have a quarterly dataset that runs from 1980:1 to
2010:4. And suppose that on entry to a function the sample range
has been set by the caller to 1990:1 - 2005:4. Then inside the
function, although you can use smpl to adjust the end-points you
cannot shift them outside of the range set at the caller level.
E.g. in this case you couldn't get access to data before 1990 or
after 2005.
I'm now wondering if that is perhaps too restrictive. Bear in mind
that whatever sample is in force when a function is called will
always be restored when the function exits (again, something I do
not propose changing).
Any thoughts on this? Does it seem OK to let a function extend the
incoming sample range, provided it's then reset on exit? I think
this would make it easier to write certain kinds of potentially
useful functions.
Allin
13 years, 6 months