From cottrell@wfu.edu Mon Nov 30 21:53:22 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject:
 Re: [Gretl-devel] Goodness of Fit test to normal distribution and QQ plot
Date: Mon, 30 Nov 2009 21:53:21 -0500
Message-ID: <Pine.A41.4.58.0911302143220.2568566@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B13A51E.1070706@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6362644720468563654=="

--===============6362644720468563654==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 30 Nov 2009, Sven Schreiber wrote:

> Costia schrieb:
> > 2. I haven't found a Q-Q plot test in GRETL, (like in SAS e.g.). I think
> > it would be a good thing to add it.
>
> I agree. It's not difficult to use a quick-and-dirty script to get it
> done, but properly handling missing values etc. needs more care.

I haven't messed much with Q-Q plots.  Can anyone confirm if the
following script is correct?  If so, then I guess we could do it
as a built-in at some point.

<script>
nulldata 500
scalar n = $nobs
# artificial series to test
genr y = sort(normal())
series Qemp, Qnorm
scalar p, N, nl, nh

loop i=1..n -q
  p = i/(n+1)
  N = (n + 1) * p - 1;
  nl = floor(N);
  nh = ceil(N);
  if (nh == 0 || nh == n)
    Qemp[i] = NA
  else
    Qemp[i] = quantile(y, p)
  endif
  Qnorm[i] = critical(N, 1-p)
endloop

store @dotdir/gpdata.dat Qemp Qnorm --traditional

set echo off
outfile @dotdir/qq.gp --write
print "set datafile missing '-999'"
print "set nokey"
print "set xlabel 'Normal quantiles'"
print "set ylabel 'Empirical quantiles'"
print "plot '@dotdir/gpdata.dat', x"
outfile --close
if WIN32
  launch @gnuplot @dotdir/qq.gp
else
  launch @gnuplot -persist @dotdir/qq.gp
endif
</script>

Allin.

--===============6362644720468563654==--


From talhayalta@gmail.com Tue Dec  1 04:56:36 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] window arrangements
Date: Tue, 01 Dec 2009 11:56:33 +0200
Message-ID: <5b1988aa0912010156y34c875dfi9b5daba805c824cf@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.0911282027200.217468@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9214218778444465812=="

--===============9214218778444465812==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Dear fellow gretl users and contributors:
First of all, I'd like to thank and congratulate Allin and other
contributors for a successfull new release and their endless efforts
making gretl keep getting better and better. I do appreciate the new
window management functionality in the CVS and would like to offer my
two cents on this issue:

I welcome the new windows menu and I also agree that it is not as
useful and intuitive even as a sub menu. Moreover, I think we are
getting close to a point where we have too many menus and menu items.
If I am not mistaken, about three years ago we've had a discussion
regarding a reorganization of the gretl menus, which resulted in a
much improved user interface. Since gretl keeps getting more and more
functionality and new menu items, this may be a good time to do this
again. As a result:
1)- I support Allin's proposal to merge "Data", "View" and "Sample" to
2 headings.

2)- I humbly suggest that we
     a)- move the "Seed for random numbers" and the  "Set missing
value code" menu items to the preferences window,
     b)- remove the second "Define new variable..." item in the
Variable menu. We already have this in the Add menu and it fits there
quite well.

3)- One problem I am having while working with multiple windows is
that various gretl windows have the same title, which results in
ANOVA, confidence ellipse, normality test etc. windows from different
models getting mixed up. IMHO it would be much better if the different
windows originating from different models had the name of the original
model in their respective titles. That is, instead of having "gretl:
ANOVA" for all ANOVA windows, we would have something like "gretl:
ANOVA (Model 8)."

4)- Recently I had personally complained to Allin regarding how
various error message windows could get lost below other open windows
and freeze everything else. Allin was kind enough to fix this so that
now we have such windows remain at the top at all times. I strongly
belive that it would be better still if the various dialog boxes (such
as model specification or choosing variables to plot something etc.)
were to stay at the top also. These do not freeze gretl but they can
sometimes get lost under other windows. Making them stay on top would
ensure that the user is aware of them and do someting with them, that
is either use them or close them, preventing window clutter and
promoting a more organized work environment.

Best regards
A. Talha Yalta





On Sun, Nov 29, 2009 at 3:49 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
>
> On Sat, 28 Nov 2009, Sven Schreiber wrote:
>
>> Allin Cottrell schrieb:
>> > * The main window now has a menu item named "Windows" which
>> > presents a list of open gretl windows, with icons in some cases to
>> > provide an easy visual fix on what's open.  I'm not sure whether
>> > this should be a sub-item of the "View" menu, or a top-level menu
>> > in its own right.  For now I've made it the latter.  Any thoughts?
>>
>> Given that "View" is the shortest of all menus and that there
>> are already nine top-level menus I would tend to favor the View
>> menu. But to be honest I'm not sure if that's the best
>> approach...
>
> I'm thinking that if this new feature is to be really useful, it
> should be immediately apparent, not one layer down.
>
> However, I take your point about the proliferation of top-level
> menu headings.  I wonder if we could do some consolidation,
> perhaps reducing "Data", "View" and "Sample" to 2 headings.
>
>> on many systems you have a list of the open gretl windows
>> already in some taskbar (don't know about windows 7 that
>> Patricio mentioned). So having another such list inside gretl
>> may be redundant in many situations.
>
> A gretl window list is less essential if the desktop has its own
> (good) task-listing mechanism, yes.  But for people who have lots
> of windows open I think we can probably do better.  For one thing,
> we can drop the leading "gretl: " from the listed window titles so
> it's easier to scan the relevant part.  And we can origanize
> things to some extent, with model-related windows listed under the
> model window to which they pertain.
>
>> I don't have the perfect solution, so I proposed a partial
>> reform that would reduce the overall number of windows.
>
> Frankly, I don't like the idea of sticking together windows that
> are currently separate.  It reduces flexibility and, IMO, destroys
> the design coherence of existing windows.  I tried a test of
> combining the existing main window with the icon view (this was
> some months ago), and I didn't like the result at all.
>
>> Another possibility in principle might be to have a "gretl
>> workspace window" that holds all other gretl windows (apart from
>> dialog windows).
>
> MDI? Sorry, I don't like it.
> http://en.wikipedia.org/wiki/Multiple_document_interface
>
>> -- BTW, that just inspired an idea: I think it would be helpful if with
>> some command you could "conjure" all gretl windows to the front at the
>> same time. Actually, if that were possible, I would tend to think that
>> it's actually not necessary to reduce the number of windows! So, is it
>> possible?
>
> Hmm, tessellating the plane with gretl windows? I don't know how
> easy that would be.
>
>> thanks, especially for your open-mindedness about this issue,
>
> As you see, I'm open-minded only up to a point!  But we'll see
> what we can do.
>
> Allin.
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>



-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============9214218778444465812==--


From cottrell@wfu.edu Tue Dec  1 16:17:35 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] window arrangements
Date: Tue, 01 Dec 2009 16:17:34 -0500
Message-ID: <Pine.A41.4.58.0912011609020.2617654@f1n11.sp2net.wfu.edu>
In-Reply-To: 5b1988aa0912010156y34c875dfi9b5daba805c824cf@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7085850199397012480=="

--===============7085850199397012480==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 1 Dec 2009, Talha Yalta wrote:

> I do appreciate the new window management functionality in the
> CVS and would like to offer my two cents on this issue:
>
> I welcome the new windows menu and I also agree that it is not
> as useful and intuitive even as a sub menu. Moreover, I think we
> are getting close to a point where we have too many menus and
> menu items.

In CVS I have made the window-list menu available in various ways:

1) Under /View/Windows

2) In most gretl windows, via Alt-w. If that keybinding collides
with something important to people, please let me know.

3) For (most?) windows with a toolbar at the top, via a new
"compass" icon button.  If anyone can find or produce a better
compass icon (or other suitable icon for the job) at 16x16 pixels,
please do so!

> If I am not mistaken, about three years ago we've had a discussion
> regarding a reorganization of the gretl menus, which resulted in a
> much improved user interface. Since gretl keeps getting more and more
> functionality and new menu items, this may be a good time to do this
> again. As a result:
> 1)- I support Allin's proposal to merge "Data", "View" and "Sample" to
> 2 headings.

Hmm, I did float that idea, but I'm not sure how to do it.

> 2)- I humbly suggest that we
>      a)- move the "Seed for random numbers" and the  "Set missing
> value code" menu items to the preferences window,

I don't think of these as "preferences".  I think of preferences
as relatively settled matters that you'd not want to change much.
I think of the random seed as a tool, and the missing values code
as dataset-dependent.

>      b)- remove the second "Define new variable..." item in the
> Variable menu. We already have this in the Add menu and it fits there
> quite well.

Yeah, but defining a new variable is such a common task that I
don't think it hurts to have it in both places.

> 3)- One problem I am having while working with multiple windows is
> that various gretl windows have the same title, which results in
> ANOVA, confidence ellipse, normality test etc. windows from different
> models getting mixed up. IMHO it would be much better if the different
> windows originating from different models had the name of the original
> model in their respective titles. That is, instead of having "gretl:
> ANOVA" for all ANOVA windows, we would have something like "gretl:
> ANOVA (Model 8)."

Yes, that's probably worth doing.

Allin.

--===============7085850199397012480==--


From moradan228@gmail.com Tue Dec  1 16:42:02 2009
From: Ivan Sopov <moradan228@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Gretl project on the launchpad
Date: Tue, 01 Dec 2009 23:42:00 +0200
Message-ID: <7e0e63490912011342j3728a3afsea9582608508a059@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2071817966636418480=="

--===============2071817966636418480==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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

--===============2071817966636418480==--


From cottrell@wfu.edu Tue Dec  1 19:18:11 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] window arrangements
Date: Tue, 01 Dec 2009 19:18:10 -0500
Message-ID: <Pine.A41.4.58.0912011917090.3108948@f1n11.sp2net.wfu.edu>
In-Reply-To: Pine.A41.4.58.0912011609020.2617654@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5952565343672639722=="

--===============5952565343672639722==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 1 Dec 2009, Allin Cottrell wrote:

> In CVS I have made the window-list menu available in various ways:
> ...
> 3) For (most?) windows with a toolbar at the top, via a new
> "compass" icon button.  If anyone can find or produce a better
> compass icon (or other suitable icon for the job) at 16x16 pixels,
> please do so!

OK, I've got a better icon (it's now in CVS).

Allin

--===============5952565343672639722==--


From cottrell@wfu.edu Tue Dec  1 19:27:12 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Tue, 01 Dec 2009 19:27:11 -0500
Message-ID: <Pine.A41.4.58.0912011925510.3108948@f1n11.sp2net.wfu.edu>
In-Reply-To: 7e0e63490912011342j3728a3afsea9582608508a059@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3958558935979242957=="

--===============3958558935979242957==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 1 Dec 2009, Ivan Sopov wrote:

> 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 have posted a question on launchpad, requesting that the
gretl project be reassigned to you.

Allin Cottrell

--===============3958558935979242957==--


From henrique.coelho@gmail.com Tue Dec  1 21:14:18 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Wed, 02 Dec 2009 00:13:56 -0200
Message-ID: <b3173c600912011813x361a0dcaq194011a023b241e2@mail.gmail.com>
In-Reply-To: 7e0e63490912011342j3728a3afsea9582608508a059@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============3420634482250550073=="

--===============3420634482250550073==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIDEyIGRlIGRlemVtYnJvIGRlIDIwMDkgSXZhbiBT
b3BvdiBlc2NyZXZldTo8c3BhbiBkaXI9Imx0ciI+PC9zcGFuPjxicj48YmxvY2txdW90ZSBjbGFz
cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw
NCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4K
Cgo8L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1
b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1h
cmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CkkgaGF2ZSBwcmVw
YXJlZCBhIC5wby1maWxlIGZvciBnZW5yX2Z1bmNzLnhtbCBhbmQgZ3JldGxfY29tbWFuZHMueG1s
PGJyPgp3aXRoIHRoZSBoZWxwIG9mIHBvNGEgdXRpbGl0eSBhbmQgZ290IDE1MTEgc3RyaW5ncyBm
b3IgdHJhbnNsYXRpb248YnI+CihzdHJpbmdzIGEgcmF0aGVyIGJpZykuPGJyPjwvYmxvY2txdW90
ZT48ZGl2Pjxicj5JIHN0cm9uZ2x5IHN1cHBvcnQgeW91ciBpbml0aWF0aXZlPHNwYW4gc3R5bGU9
ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPiEgTm93IDwvc3Bhbj48c3Bh
biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgaWQ9InJlc3Vs
dF9ib3giIGNsYXNzPSJzaG9ydF90ZXh0Ij5JJiMzOTttIHdhaXRpbmcgYW54aW91c2x5IGZvciB0
aGUgcmVsZWFzZSA7KTwvc3Bhbj48YnI+Cgo8YnI+QmVzdCwgPGJyPjwvZGl2PjwvZGl2PkhlbnJp
cXVlPGJyPgoK

--===============3420634482250550073==--


From patriciocuaron@gmail.com Tue Dec  1 23:19:23 2009
From: Patricio =?utf-8?q?Cuar=C3=B3n?= <patriciocuaron@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] window arrangements
Date: Wed, 02 Dec 2009 01:19:01 -0300
Message-ID: <8aeb6c2b0912012019w580a0258nb2591b8f56da0685@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.0912011917090.3108948@f1n11.sp2net.wfu.edu
Content-Type: multipart/mixed; boundary="===============1680521481962830676=="

--===============1680521481962830676==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

aGVyZSYjMzk7cyBpbW8gYSBiZXR0ZXIgaWNvbiAoY3JlYXRpdmUgY29tbW9ucykgYmFzZWQgb24g
dGhlIHRhbmdvIGljb24gc2V0IDxhIGhyZWY9Imh0dHA6Ly93d3cuY2hpcHg4Ni5jb20vYmxvZy8y
MDA3LzAzLzA5L3Ztd2FyZS10YW5nby1pY29ucy0lRTIlOTklQTUtY3JlYXRpdmUtY29tbW9ucy8i
Pmh0dHA6Ly93d3cuY2hpcHg4Ni5jb20vYmxvZy8yMDA3LzAzLzA5L3Ztd2FyZS10YW5nby1pY29u
cy0lRTIlOTklQTUtY3JlYXRpdmUtY29tbW9ucy88L2E+oCBhbmQgdGhlcmUgaXMgYW5vdGhlciBv
bmUgdGhhdCBjb3VsZCBmaXQsIGZyb20gdGhlICYjMzk7b2ZmaWNpYWwmIzM5OyB0YW5nbyByZWxl
YXNlcywgPGEgaHJlZj0iaHR0cDovL2NvbW1vbnMud2lraW1lZGlhLm9yZy93aWtpL0ZpbGU6UHJl
ZmVyZW5jZXMtc3lzdGVtLXdpbmRvd3Muc3ZnIj5odHRwOi8vY29tbW9ucy53aWtpbWVkaWEub3Jn
L3dpa2kvRmlsZTpQcmVmZXJlbmNlcy1zeXN0ZW0td2luZG93cy5zdmc8L2E+PGJyPgoKPGJyPjxk
aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIERlYyAxLCAyMDA5IGF0IDk6MTggUE0sIEFs
bGluIENvdHRyZWxsIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNvdHRyZWxs
QHdmdS5lZHUiPmNvdHRyZWxsQHdmdS5lZHU8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44
ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxl
ZnQ6IDFleDsiPgoKPGRpdiBjbGFzcz0iaW0iPjxicj4KT24gVHVlLCAxIERlYyAyMDA5LCBBbGxp
biBDb3R0cmVsbCB3cm90ZTo8YnI+Cjxicj4KJmd0OyBJbiBDVlMgSSBoYXZlIG1hZGUgdGhlIHdp
bmRvdy1saXN0IG1lbnUgYXZhaWxhYmxlIGluIHZhcmlvdXMgd2F5czo8YnI+CjwvZGl2PiZndDsg
Li4uPGJyPgo8ZGl2IGNsYXNzPSJpbSI+Jmd0OyAzKSBGb3IgKG1vc3Q/KSB3aW5kb3dzIHdpdGgg
YSB0b29sYmFyIGF0IHRoZSB0b3AsIHZpYSBhIG5ldzxicj4KJmd0OyAmcXVvdDtjb21wYXNzJnF1
b3Q7IGljb24gYnV0dG9uLiCgSWYgYW55b25lIGNhbiBmaW5kIG9yIHByb2R1Y2UgYSBiZXR0ZXI8
YnI+CiZndDsgY29tcGFzcyBpY29uIChvciBvdGhlciBzdWl0YWJsZSBpY29uIGZvciB0aGUgam9i
KSBhdCAxNngxNiBwaXhlbHMsPGJyPgomZ3Q7IHBsZWFzZSBkbyBzbyE8YnI+Cjxicj4KPC9kaXY+
T0ssIEkmIzM5O3ZlIGdvdCBhIGJldHRlciBpY29uIChpdCYjMzk7cyBub3cgaW4gQ1ZTKS48YnI+
CjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+PGJyPgpBbGxpbjxicj4KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CkdyZXRsLWRldmVsIG1h
aWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHUi
PkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHU8L2E+PGJyPgo8YSBocmVmPSJodHRwOi8vbGlzdHMu
d2Z1LmVkdS9tYWlsbWFuL2xpc3RpbmZvL2dyZXRsLWRldmVsIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cDovL2xpc3RzLndmdS5lZHUvbWFpbG1hbi9saXN0aW5mby9ncmV0bC1kZXZlbDwvYT48YnI+Cjwv
ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg==

--===============1680521481962830676==--


From henrique.coelho@gmail.com Wed Dec  2 00:23:58 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] window arrangements
Date: Wed, 02 Dec 2009 03:23:36 -0200
Message-ID: <b3173c600912012123j2b22367bi53d529b868a15b60@mail.gmail.com>
In-Reply-To: 8aeb6c2b0912012019w580a0258nb2591b8f56da0685@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============6193462897873963248=="

--===============6193462897873963248==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIDIgZGUgZGV6ZW1icm8gZGUgMjAwOSBQYXRyaWNp
byBDdWFy8248c3BhbiBkaXI9Imx0ciI+IGVzY3JldmV1Ojwvc3Bhbj48YnI+PGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0
LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4
OyI+CgpoZXJlJiMzOTtzIGltbyBhIGJldHRlciBpY29uIChjcmVhdGl2ZSBjb21tb25zKSBiYXNl
ZCBvbiB0aGUgdGFuZ28gaWNvbiBzZXQgPGEgaHJlZj0iaHR0cDovL3d3dy5jaGlweDg2LmNvbS9i
bG9nLzIwMDcvMDMvMDkvdm13YXJlLXRhbmdvLWljb25zLSVFMiU5OSVBNS1jcmVhdGl2ZS1jb21t
b25zLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuY2hpcHg4Ni5jb20vYmxvZy8yMDA3LzAz
LzA5L3Ztd2FyZS10YW5nby1pY29ucy0lRTIlOTklQTUtY3JlYXRpdmUtY29tbW9ucy88L2E+oCBh
bmQgdGhlcmUgaXMgYW5vdGhlciBvbmUgdGhhdCBjb3VsZCBmaXQsIGZyb20gdGhlICYjMzk7b2Zm
aWNpYWwmIzM5OyB0YW5nbyByZWxlYXNlcywgPGEgaHJlZj0iaHR0cDovL2NvbW1vbnMud2lraW1l
ZGlhLm9yZy93aWtpL0ZpbGU6UHJlZmVyZW5jZXMtc3lzdGVtLXdpbmRvd3Muc3ZnIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cDovL2NvbW1vbnMud2lraW1lZGlhLm9yZy93aWtpL0ZpbGU6UHJlZmVyZW5j
ZXMtc3lzdGVtLXdpbmRvd3Muc3ZnPC9hPjwvYmxvY2txdW90ZT4KCjxkaXY+PGJyPqBJIGFncmVl
IHdpdGggUGF0cmljaW8uPGJyPjxicj5CZXN0LDxicj5IZW5yaXF1ZTxicj48L2Rpdj48L2Rpdj4K

--===============6193462897873963248==--


From moradan228@gmail.com Wed Dec  2 03:10:55 2009
From: Ivan Sopov <moradan228@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Wed, 02 Dec 2009 10:10:51 +0200
Message-ID: <7e0e63490912020010s8a21fd2o5bf3e2527c929f91@mail.gmail.com>
In-Reply-To: b3173c600912011813x361a0dcaq194011a023b241e2@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5369882295147770242=="

--===============5369882295147770242==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

2009/12/2 Henrique <henrique.coelho(a)gmail.com>:
>
> I strongly support your initiative! Now I'm waiting anxiously for the
> release ;)
>

Pleased to read that. If anyone is willing to translate help system in
some other languages with the help of launchpad he is probably should
generate a .po-file himself with the .pot-file (As far as i understood
with the usual gettext-tools .po-files are generated from .pot-file
wich is single for all languages. And also some explicit settings
about plural forms must be done in .po-file which I can not do not
knowing other languages). It can be found here
http://sopovs.com/gretl/gretl_help.pot
And also here is my config-file for po4a utility that generates .pot
and .po from our xmls.
http://www.sopovs.com/gretl/po4a_config.txt

Good luck, Ivan.

--===============5369882295147770242==--


From henrique.coelho@gmail.com Wed Dec  2 10:14:26 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Brazilian Website
Date: Wed, 02 Dec 2009 13:14:04 -0200
Message-ID: <b3173c600912020714p2161ddc4s1634c816733f1e1d@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============0815119776058870611=="

--===============0815119776058870611==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

RGVhciBkZXZlbG9wZXJzLDxicj48YnI+oKCgoCBJcyBpdCBwb3NzaWJsZSB0byBpbmNsdWRlIGEg
c2VwYXJhdGUgR3JldGwgd2ViIHBhZ2UgZm9yIEJyYXppbGlhbiBQb3J0dWd1ZXNlPzxicj48YnI+
QmVzdCw8YnI+SGVucmlxdWUgQy4gZGUgQW5kcmFkZTxicj5Eb3V0b3JhbmRvIGVtIEVjb25vbWlh
IEFwbGljYWRhPGJyPlVuaXZlcnNpZGFkZSBGZWRlcmFsIGRvIFJpbyBHcmFuZGUgZG8gU3VsPGJy
PgoKPGEgaHJlZj0iaHR0cDovL3d3dy51ZnJncy5ici9wcGdlIj53d3cudWZyZ3MuYnIvcHBnZTwv
YT48YnI+Cg==

--===============0815119776058870611==--


From svetosch@gmx.net Wed Dec  2 10:37:50 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] filenames with dots
Date: Wed, 02 Dec 2009 16:36:53 +0100
Message-ID: <4B168995.30102@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6178328226738666873=="

--===============6178328226738666873==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

a very minor issue:

even if 'myfilenamewith.dots.inp' exists (and is in the right
place/dir), the command

include myfilenamewith.dots

fails, apparently because gretl interprets .dots as a filename extension.

('include myfilenamewith.dots.inp' works as expected)

cheers,
sven

--===============6178328226738666873==--


From helioxentric@gmail.com Wed Dec  2 11:23:13 2009
From: =?utf-8?q?H=C3=A9lio?= Guilherme <helioxentric@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Brazilian Website
Date: Wed, 02 Dec 2009 16:23:10 +0000
Message-ID: <5be765950912020823q5516a01bnb2ebba3d7e9169ad@mail.gmail.com>
In-Reply-To: b3173c600912020714p2161ddc4s1634c816733f1e1d@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============2828182099092451892=="

--===============2828182099092451892==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

SGkgSGVucmlxdWUsPGJyPjxicj5DYW4geW91IHBsZWFzZSBkZXNjcmliZSB0aGUgcmVhc29ucyB3
aHkgeW91IHJlcXVlc3QgdGhpcz88YnI+PGJyPklmIGl0IGlzIGEgbWF0dGVyIG9mIGxhbmd1YWdl
LCB3ZSBtYXkgY29uc2lkZXIgaGF2aW5nIGEgcmV2aXNlZCB0ZXh0IGZvbGxvd2luZyB0aGUgJnF1
b3Q7QWNvcmRvIE9ydG9ncsOhZmljbyZxdW90OywgYW5kIGFkYXB0aW5nIG5hbWVzIHRvIEJyYXpp
bGlhbiB3b3Jkcy48YnI+Cjxicj4KSSBhbSBpbiBmYXZvciBvZiBhIHNpbmdsZSBQb3J0dWd1ZXNl
IHZhcmlhbnQuPGJyPjxicj5BbHNvIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2YgdGhlIHBhZ2VzIGl0
IGlzIGJldHRlciB0byBoYXZlIGEgc2luZ2xlIGxhbmd1YWdlLjxicj48YnI+UmVnYXJkcyw8YnI+
SMOpbGlvPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBEZWMgMiwgMjAw
OSBhdCAzOjE0IFBNLCBIZW5yaXF1ZSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0
bzpoZW5yaXF1ZS5jb2VsaG9AZ21haWwuY29tIj5oZW5yaXF1ZS5jb2VsaG9AZ21haWwuY29tPC9h
PiZndDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz
dHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjog
MHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+RGVhciBkZXZlbG9wZXJzLDxi
cj48YnI+wqDCoMKgwqAgSXMgaXQgcG9zc2libGUgdG8gaW5jbHVkZSBhIHNlcGFyYXRlIEdyZXRs
IHdlYiBwYWdlIGZvciBCcmF6aWxpYW4gUG9ydHVndWVzZT88YnI+Cjxicj5CZXN0LDxicj48Zm9u
dCBjb2xvcj0iIzg4ODg4OCI+SGVucmlxdWUgQy4gZGUgQW5kcmFkZTxicj5Eb3V0b3JhbmRvIGVt
IEVjb25vbWlhIEFwbGljYWRhPGJyPlVuaXZlcnNpZGFkZSBGZWRlcmFsIGRvIFJpbyBHcmFuZGUg
ZG8gU3VsPGJyPgoKPGEgaHJlZj0iaHR0cDovL3d3dy51ZnJncy5ici9wcGdlIiB0YXJnZXQ9Il9i
bGFuayI+d3d3LnVmcmdzLmJyL3BwZ2U8L2E+PGJyPgo8L2ZvbnQ+PGJyPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpHcmV0bC1kZXZlbCBtYWlsaW5n
IGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpHcmV0bC1kZXZlbEBsaXN0cy53ZnUuZWR1Ij5HcmV0
bC1kZXZlbEBsaXN0cy53ZnUuZWR1PC9hPjxicj4KPGEgaHJlZj0iaHR0cDovL2xpc3RzLndmdS5l
ZHUvbWFpbG1hbi9saXN0aW5mby9ncmV0bC1kZXZlbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9s
aXN0cy53ZnUuZWR1L21haWxtYW4vbGlzdGluZm8vZ3JldGwtZGV2ZWw8L2E+PGJyPjwvYmxvY2tx
dW90ZT48L2Rpdj48YnI+Cg==

--===============2828182099092451892==--


From henrique.coelho@gmail.com Wed Dec  2 21:01:06 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Brazilian Website
Date: Thu, 03 Dec 2009 00:00:44 -0200
Message-ID: <b3173c600912021800pabd0edftf356bd6260e580b0@mail.gmail.com>
In-Reply-To: 5be765950912020823q5516a01bnb2ebba3d7e9169ad@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============6627522679689501356=="

--===============6627522679689501356==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

RW0gMiBkZSBkZXplbWJybyBkZSAyMDA5IEjpbGlvIEd1aWxoZXJtZSA8c3BhbiBkaXI9Imx0ciI+
Jmx0OzxhIGhyZWY9Im1haWx0bzpoZWxpb3hlbnRyaWNAZ21haWwuY29tIj5oZWxpb3hlbnRyaWNA
Z21haWwuY29tPC9hPiZndDs8L3NwYW4+IGVzY3JldmV1Ojxicj48ZGl2IGNsYXNzPSJnbWFpbF9x
dW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6
IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7
IHBhZGRpbmctbGVmdDogMWV4OyI+Cgo8YnI+Q2FuIHlvdSBwbGVhc2UgZGVzY3JpYmUgdGhlIHJl
YXNvbnMgd2h5IHlvdSByZXF1ZXN0IHRoaXM/PGJyPjxicj5JZiBpdCBpcyBhIG1hdHRlciBvZiBs
YW5ndWFnZSwgd2UgbWF5IGNvbnNpZGVyIGhhdmluZyBhIHJldmlzZWQgdGV4dCBmb2xsb3dpbmcg
dGhlICZxdW90O0Fjb3JkbyBPcnRvZ3LhZmljbyZxdW90OywgYW5kIGFkYXB0aW5nIG5hbWVzIHRv
IEJyYXppbGlhbiB3b3Jkcy48YnI+CgoKPC9ibG9ja3F1b3RlPjxkaXY+PGJyPkRlYXIgSOlsaW8s
IEkgd2FzIHRoaW5raW5nIGFib3V0IGEgQnJhemlsaWFuIHdlYnBhZ2UgZHVlIHRvIHRoZSBzZXZl
cmFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlbSBhbmQgdGhlIEV1cm9wZWFuIHZhcmlhbnQuIFNv
bWUgd29yZHMgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50LiBTb21lIGV4YW1wbGVzOjxicj48YnI+
RmlsZTo8YnI+QXJxdWl2byAoQnJhemlsKTxicj4KCkZpY2hlaXJvIChQb3J0dWdhbCk8YnI+PGJy
PlZpZXc6PGJyPlZpc3VhbGl6YXIgKEJyYXppbCk8YnI+VmlzaW9uYXIgKFBvcnR1Z2FsKTxicj48
YnI+RnVydGhlcm1vcmUsIHdlIGhhdmUgYSBsb3Qgb2YgZXhwcmVzc2lvbnMgdGhhdCBhcmUgZGlm
ZmVyZW50IGJldHdlZW4gdGhlIHR3byB2YXJpYW50cy48YnI+PGJyPqA8L2Rpdj48YmxvY2txdW90
ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigy
MDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAx
ZXg7Ij4KCgpJIGFtIGluIGZhdm9yIG9mIGEgc2luZ2xlIFBvcnR1Z3Vlc2UgdmFyaWFudC48YnI+
PGJyPkFsc28gZm9yIHRoZSBtYWludGVuYW5jZSBvZiB0aGUgcGFnZXMgaXQgaXMgYmV0dGVyIHRv
IGhhdmUgYSBzaW5nbGUgbGFuZ3VhZ2UuPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj4KPC9kaXY+
PC9kaXY+T2ssIG5vIHByb2JsZW0gOykgSWYgeW91IHByZWZlciB3ZSBjYW4gdHJ5IHRvIGltcHJv
dmUgdGhlICZxdW90O2NvbXBhdGliaWx0eSZxdW90OyBiZXR3ZWVuIEJyYXppbGlhbiBhbmQgRXVy
b3BlYW4gdmFyaWFudHMgb24gR3JldGwgd2Vic2l0ZS48YnI+PGJyPkp1c3Qgb25lIG1vcmUgdGhp
bmc6IElzIHRoZXJlIGFueW9uZSBlbHNlIHdobyBzcGVha3MgUG9ydHVndWVzZSBpbiB0aGlzIGxp
c3Q/PGJyPgoKPGJyPiZxdW90O0FicmHnb3MmcXVvdDssPGJyPkhlbnJpcXVlPGJyPgo=

--===============6627522679689501356==--


From henrique.coelho@gmail.com Wed Dec  2 21:32:35 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Thu, 03 Dec 2009 00:32:12 -0200
Message-ID: <b3173c600912021832l21dbf38bo30c74cdf62fbb299@mail.gmail.com>
In-Reply-To: 7e0e63490912020010s8a21fd2o5bf3e2527c929f91@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============2475699078537041884=="

--===============2475699078537041884==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

SXZhbiw8YnI+PGJyPkkmIzM5O3ZlIGp1c3QgZG93bmxvYWRlZCB0aGUgZ3JldGxfaGVscC5wb3Qg
ZmlsZSBhbmQgY3JlYXRlIGEgZ3JldGxfaGVscF9wdF9CUi5wbyBmaWxlICh1c2luZyBQb2VkaXQg
c29mdHdhcmUpLiBCdXQgSSYjMzk7bSBub3Qgc3VyZSBhYm91dCB0aGlzIHByb2Nlc3MgKEkmIzM5
O20gbm90IGEgY29tcHV0ZXIgZXhwZXJ0IDspLjxicj48YnI+U28sIEkgd291bGQgbGlrZSBraW5k
bHkgdG8gcmVxdWVzdCB5b3UgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIGZpbGUganVzdCB0byB2ZXJp
ZnkgaWYgSSBkaWQgdGhlIHJpZ2h0IHRoaW5nLiBJcyBpdCBwb3NzaWJsZT88YnI+Cgo8YnI+QmVz
dCw8YnI+SGVucmlxdWU8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzEyLzIg
SXZhbiBTb3BvdiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzptb3JhZGFuMjI4
QGdtYWlsLmNvbSI+bW9yYWRhbjIyOEBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+PGJsb2Nr
cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCBy
Z2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVm
dDogMWV4OyI+CgoyMDA5LzEyLzIgSGVucmlxdWUgJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5yaXF1
ZS5jb2VsaG9AZ21haWwuY29tIj5oZW5yaXF1ZS5jb2VsaG9AZ21haWwuY29tPC9hPiZndDs6PGJy
Pgo8ZGl2IGNsYXNzPSJpbSI+Jmd0Ozxicj4KJmd0OyBJIHN0cm9uZ2x5IHN1cHBvcnQgeW91ciBp
bml0aWF0aXZlISBOb3cgSSYjMzk7bSB3YWl0aW5nIGFueGlvdXNseSBmb3IgdGhlPGJyPgomZ3Q7
IHJlbGVhc2UgOyk8YnI+CiZndDs8YnI+Cjxicj4KPC9kaXY+UGxlYXNlZCB0byByZWFkIHRoYXQu
IElmIGFueW9uZSBpcyB3aWxsaW5nIHRvIHRyYW5zbGF0ZSBoZWxwIHN5c3RlbSBpbjxicj4Kc29t
ZSBvdGhlciBsYW5ndWFnZXMgd2l0aCB0aGUgaGVscCBvZiBsYXVuY2hwYWQgaGUgaXMgcHJvYmFi
bHkgc2hvdWxkPGJyPgpnZW5lcmF0ZSBhIC5wby1maWxlIGhpbXNlbGYgd2l0aCB0aGUgLnBvdC1m
aWxlIChBcyBmYXIgYXMgaSB1bmRlcnN0b29kPGJyPgp3aXRoIHRoZSB1c3VhbCBnZXR0ZXh0LXRv
b2xzIC5wby1maWxlcyBhcmUgZ2VuZXJhdGVkIGZyb20gLnBvdC1maWxlPGJyPgp3aWNoIGlzIHNp
bmdsZSBmb3IgYWxsIGxhbmd1YWdlcy4gQW5kIGFsc28gc29tZSBleHBsaWNpdCBzZXR0aW5nczxi
cj4KYWJvdXQgcGx1cmFsIGZvcm1zIG11c3QgYmUgZG9uZSBpbiAucG8tZmlsZSB3aGljaCBJIGNh
biBub3QgZG8gbm90PGJyPgprbm93aW5nIG90aGVyIGxhbmd1YWdlcykuIEl0IGNhbiBiZSBmb3Vu
ZCBoZXJlPGJyPgo8YSBocmVmPSJodHRwOi8vc29wb3ZzLmNvbS9ncmV0bC9ncmV0bF9oZWxwLnBv
dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zb3BvdnMuY29tL2dyZXRsL2dyZXRsX2hlbHAucG90
PC9hPjxicj4KQW5kIGFsc28gaGVyZSBpcyBteSBjb25maWctZmlsZSBmb3IgcG80YSB1dGlsaXR5
IHRoYXQgZ2VuZXJhdGVzIC5wb3Q8YnI+CmFuZCAucG8gZnJvbSBvdXIgeG1scy48YnI+CjxhIGhy
ZWY9Imh0dHA6Ly93d3cuc29wb3ZzLmNvbS9ncmV0bC9wbzRhX2NvbmZpZy50eHQiIHRhcmdldD0i
X2JsYW5rIj5odHRwOi8vd3d3LnNvcG92cy5jb20vZ3JldGwvcG80YV9jb25maWcudHh0PC9hPjxi
cj4KPGJyPgpHb29kIGx1Y2ssIEl2YW4uPGJyPgo8ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0i
aDUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpH
cmV0bC1kZXZlbCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpHcmV0bC1kZXZlbEBs
aXN0cy53ZnUuZWR1Ij5HcmV0bC1kZXZlbEBsaXN0cy53ZnUuZWR1PC9hPjxicj4KPGEgaHJlZj0i
aHR0cDovL2xpc3RzLndmdS5lZHUvbWFpbG1hbi9saXN0aW5mby9ncmV0bC1kZXZlbCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy53ZnUuZWR1L21haWxtYW4vbGlzdGluZm8vZ3JldGwtZGV2
ZWw8L2E+PGJyPgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0i
YWxsIj48YnI+LS0gPGJyPkhlbnJpcXVlIEMuIGRlIEFuZHJhZGU8YnI+RG91dG9yYW5kbyBlbSBF
Y29ub21pYSBBcGxpY2FkYTxicj5Vbml2ZXJzaWRhZGUgRmVkZXJhbCBkbyBSaW8gR3JhbmRlIGRv
IFN1bDxicj48YSBocmVmPSJodHRwOi8vd3d3LnVmcmdzLmJyL3BwZ2UiPnd3dy51ZnJncy5ici9w
cGdlPC9hPjxicj4KCgo=

--===============2475699078537041884==--


From bttomio@al.furb.br Thu Dec  3 12:37:21 2009
From: Bruno Thiago Tomio <bttomio@al.furb.br>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] RES: Gretl-devel Digest, Vol 35, Issue 4
Date: Thu, 03 Dec 2009 15:36:57 -0200
Message-ID: <E2E29503F750A24D80C8A16BB6AC4D7A045B1347@FALCAO.furb.br>
In-Reply-To: mailman.47.1259859604.30281.gretl-devel@lists.wfu.edu
Content-Type: multipart/mixed; boundary="===============5514760157173982777=="

--===============5514760157173982777==
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"
MIME-Version: 1.0

eJ8+IhERAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKQAAAFJFUzogR3JldGwtZGV2ZWwg
RGlnZXN0LCBWb2wgMzUsIElzc3VlIDQArQwBBYADAA4AAADZBwwAAwAPACQAOQAEAF8BASCAAwAO
AAAA2QcMAAMADwAlAA8ABAA2AQEJgAEAIQAAAEJDMTQ4MTY3M0VEQjc1NDk4MkQ0NzVGM0E1NTFE
RUY3AEAHAQOQBgAAHwAAOAAAAAMANgAAAAAAQAA5ANKBbDY/dMoBHgA9AAEAAAAGAAAAUkVTOiAA
AAACAUcAAQAAACsAAABjPVVTO2E9IDtwPUZVUkI7bD1GQUxDQU8tMDkxMjAzMTczNzE1Wi0zMzAA
AB4ASQABAAAAJAAAAEdyZXRsLWRldmVsIERpZ2VzdCwgVm9sIDM1LCBJc3N1ZSA0AEAATgAAguAO
OnTKAR4AWgABAAAAIgAAAGdyZXRsLWRldmVsLWJvdW5jZXNAbGlzdHMud2Z1LmVkdQAAAAIBWwAB
AAAAYQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGdyZXRsLWRldmVsLWJvdW5jZXNAbGlzdHMu
d2Z1LmVkdQBTTVRQAGdyZXRsLWRldmVsLWJvdW5jZXNAbGlzdHMud2Z1LmVkdQAAAAACAVwAAQAA
ACcAAABTTVRQOkdSRVRMLURFVkVMLUJPVU5DRVNATElTVFMuV0ZVLkVEVQAAHgBdAAEAAAAiAAAA
Z3JldGwtZGV2ZWwtcmVxdWVzdEBsaXN0cy53ZnUuZWR1AAAAAgFeAAEAAABhAAAAAAAAAIErH6S+
oxAZnW4A3QEPVAIAAAAAZ3JldGwtZGV2ZWwtcmVxdWVzdEBsaXN0cy53ZnUuZWR1AFNNVFAAZ3Jl
dGwtZGV2ZWwtcmVxdWVzdEBsaXN0cy53ZnUuZWR1AAAAAAIBXwABAAAAJwAAAFNNVFA6R1JFVEwt
REVWRUwtUkVRVUVTVEBMSVNUUy5XRlUuRURVAAAeAGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAA
IgAAAGdyZXRsLWRldmVsLWJvdW5jZXNAbGlzdHMud2Z1LmVkdQAAAB4AaAABAAAABQAAAFNNVFAA
AAAAHgBpAAEAAAAiAAAAZ3JldGwtZGV2ZWwtcmVxdWVzdEBsaXN0cy53ZnUuZWR1AAAAHgBwAAEA
AAAkAAAAR3JldGwtZGV2ZWwgRGlnZXN0LCBWb2wgMzUsIElzc3VlIDQAAgFxAAEAAAAbAAAAAcp0
Ojua2Bh97oA7QtyQ3b9dJDrWQwABPrRiAB4AdAABAAAAGgAAAGdyZXRsLWRldmVsQGxpc3RzLndm
dS5lZHUAAAAeABoMAQAAABMAAABCcnVubyBUaGlhZ28gVG9taW8AAB4AHQ4BAAAAJAAAAEdyZXRs
LWRldmVsIERpZ2VzdCwgVm9sIDM1LCBJc3N1ZSA0AAIBCRABAAAAZhcAAGIXAABYWAAATFpGdXj6
2kkDAAoAcmNwZzEyNYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xADAFAE
VghVB7IR1Q5RAwHdENcyBgAGwxHVMwRGENlZEu9mNBBvEXs1A8ZUfGFoA3ECgBHjCO8J9zt7HB8O
MDUdPx0REeEMYGNnAFALCQFkMzYRYAulNHIgEAIqXA6yAZAOEDkAIDxIVE1MIGSIaXI9IrByPn0i
c+cAIQMwI8FkbwDgI8EKsfxccRwAI8EY4AMwJCURYI0iKzMiACMgRUFEI/AJIiw3NyMQVElUTC5F
KB0h8A7wRx6gdGwSLQEAdmUDIERpZyEHkHQsIFYG8CAzmjUr8EkEEApQIDQoLXQ4NSMQLylfIsIK
4yAXLq8vvw4QNg7wPE1FOFRBIAWgAjAJ8HQ9BiIF4CMzNi4wMC4HIWAz4TIgODkwIiAEbmEHgD1H
RU5F4FJBVE9SKB0qoS4gLyffKnEw7yLBNRFgPEI4T0RZKB0hcThfZzkCNiMQRElWIGlkgj08sE9X
QVJlC1DweVRleBTgDkA5cSOP/iAAACUlJcMlgSYfOn87j988kD4vPz9ASiJJNizwRDkTQH8ipDQ4
IxBGT074VCBmANA1AAcTMrEbsaw9IzQhNCEgAJB6NQDuMkQbGDADMGMT8AOyAdCtQFlICfAFEHEK
UCwiLPo1PEEvScIj+SQHRmsBwF8kBwqiUQgKgCIsMCehL/88cVBfSF9Bz0LfQ+9E/1E//0cfVl9J
P0pGS69MtE1tTu8XT/9WLyKFOCIAJm5izHNwAoAkGCdhAUBbz/9SP1NPVF9Vb2VvV49Yn1mv/1q/
aB9c320/Xv9gD2EfTYsOWQeQLHFwUG8uIEX2dUoBG7AuYv9kD1EPaQ//ah9rL2w/dO9uX29vcH9x
j/9yn3OvdL91z3bfd+9iD3s//3xPjp9mT2dffa9+v3/PgN//kN+C/4QPhR+GL4c/iE+JXx+Zv4t/
jI+Nn6EWQWJy4mGT8GU3b3oAjy+QP/99P5U/lk+XX5hvoR+aj5uf/5yvnb+ez5/foO+h/6MPpB//
jj+m76f/uk+Sf5OPqV+qb/+rf6yPvI+ur6+/sM+x37Lvf7P/tQ/Fb7cvuD+5T8zGQvBydW5vut+7
76jvwO//wf/DD8QfzM/X39jvxZ/Gr+/Hv8jPyd/cjzEOIDmRNaE/JBgKsQqB4b/dT95bSFISIAGR
SW4BAHg9LZYxz8wAUHEA4HFqDGCIbGRiAzB+IF/qUvfqESSgC4Bl1kPkf+WOyy//zD/NT85ZGsTP
X0yiLgC53x+9vTmg39vqAfOnRGU62+aM4zEv9UrUOSAJwSsGzi0G4NHgSjBzQOrgK9DAcy53ZnUu
CYB6oPxlbTTAA3As0AEA+aseoP9OoSvQ+uziTTxB42zq4ut/R/SP9Z8BUkVudgcwZF5h9w/4H/kn
TqBpLEAvtQ4gLwwAMCMA0uA6M+C//p//rwC/Ac8C3ws0UORQ/wSvBb/5HytC/b8IzwnfCu/fC/8N
D6XiLKEzEG8Ojw+f9xCnKt8r7zQSzxPfFO/ST//TXyBPHl8fb9Sf1a/Wv9qP/yJv7B/mLzwX39sr
Lyw/7an953BQ448vCC5vI2/OJ/Hfa+khTXxTTmBkG4vxoGkZ6uFnIPryNmB1Ym3jEgA2cG9uc+ew
0g0kf/8lj72vvr+/yj5fP29Af0GP/0KfQ69Ev0XPRt9H70j/Sg//Sx9ML00/Tk8Q7xH/O588r09O
/1SPVZ9WpVRvOmJz6mPPEGL8MG8wwNHgWkjrBGHnsGj8MFda4OngXEDiafxRV2ViHLAEYDZw/nRX
H1gvVj9Pz1DfYB9hL/9iP2NPZF9lb2Z/Z49on2mv/2q/a89s323vbv9wD1GsFc+IQSBo/UBmPSJz
YKB0cDovL/r7LzmijfGgbnbDX7Bmby/5uaoiz8xpHCBkMRJm6eADX7AckHtIWVBFUuBMSU5LIHZf
d294fyZ97XF64XJzMYBcY//pQenQ84l8H30veI0qfzOa+ysPGVpBMhBdr16/X8xa4N9dMvGw+9A5
sRywczii8bCv/CAYgDGg/DB3XYBoOmI4amVjOlBa4fpwZHnEICdcIGxwJzsviM//id9x73L/cS+R
/5MPlB+VL/+WP5dPmF+Zb5p/m4+cn52v/56/n8+g33PP/I/9n46/j88vkN+oL6k/qkhZ+oAgYz2C
oCCmkM7AjPBcEnBl93+gOvA5kW4xoDniXBI6I/5hXZ+r76n/ow+kH7MftC//tT+2T7dfuG+5f7qP
u5+8r/+9v77Pv9/A78H/ww+k7/nY9G936wBypw+w77H/sw83yj/LT8xWV1wgrkJwbP55OeEcsNBA
rnCL0PvA32DtOlB5+oAwwFONJeriNmB/WiDRUckQOZBa4NKBrwBj+ml6UGPM383vy/xcEK4xpCJS
9vAgQzrwdDigv/sgWtAyoBua32Acci7ZgP4i1A/VH8v/2f/bD9wf3S9n3j9ZmASQeSc7EFoQcP3T
4HMY7OCf4a/fv+S/5c8/xR/GL+kf6i/rP8eEMS7qINdiQg5gejnBrjFdAXNdcfwwKEg4oFqQprEp
/+a/58/o3+zP7d/0L/U/9k+dx5My75Qbk67wcm+NRPuuQLADYVsQrpAwoDjA8R//8i/zP/cv/i//
PwBPAV8Cb7wgLQaPB58Irwm/LQOP3wSfAq8LHwwvDTlNjFTXgG4xDe8O/w0MRLCQ78FUdGh1HLAz
HECNUPpwMKgwOSAVoDoV4TT4cLwtMBWREY8Snw0MRvtgbm0RUPz2948mMYD46TwjgGn9BS5jb9jw
aG+sQGeLch3BbRq/Zxva/j4NTxc/GE84Jo0kEVDXYvpb2Gld7+8NESGPIp9ZXP/61tjD41CMQNfw
Gq8bvyDm/1KPyV8fbyB/J08oXxAv2UD4LUlE468zPwz/97/4z/84TzlfOm87fzyPPZ8+rz+//0DP
Qd9C70P/RQ9GH0cvSD8Pc+8rryy/SdNiMzE3KDNjNhWhMRaQMjFGOBag/KBiZDDJoGaRS/AzNTZQ
4DYyUADEZTVQkGIwQB5THk8/MC8xPzX/Nw84G9elLVSOedOQEVAnAHh0L9BA+YuAbjuuENcQf6DY
gHZAAS7gby04ODU5LX4x2b9W3zf/W99c7136Ra5t+nAqsSqxeotgYvtgM2HyFZNIP7BA0rBHdfuC
cPwQcoxATQ9OHxzIY2H2eNfhGlBjHj9Tv1TP0SDsc2OmkNjgdTXfX79dz/9rj2yfba9oj2mfbk9v
X3Bv93F/co/HdUOuMdGB0LbYwPlq4Wli0RD8Aq5hrzHjIHx3aI3wedKmldbxLuA//3P/dQ92H3cv
eD9/733/fw/3gB+BL8dXSdhA0tSMIbCQ3ycAjaDYMfxAr9B1jIHQoL530RBnsI3wHdB7oGnYwPuN
oNcQdq/CiOBrAS7gyaB/WaOCv4PPhN+F74b/x5NmlG9sKwB3r8YiQR3QVHJk0rBPS+Bvx+A/edPR
byLQoK+A/MD8sGH8cHSvwq+QKzDjIJOwJgn+d5NBLxCMn42vjr+Pz5Df/5mfl6+Yv5xfnW8Tnq5w
iyA7Y0PQoEmKMNDwfMJua/2Lc2LRkLBxlcomwPyg2UB/2RAagZWh/ALRANjg8ABsz59voH+ejNFA
ZmaLEBow9mOVcXrgdIpAz/H8AWHAe5Ry/AJF0aDjUK5wrkB2/1qQ8FHZcNHAGeDREJZzsID/01Fo
AdDBJwDQUKbfp++o//+qA6zWWcCVUNDB45+vj55v/7M/tE8Y/PAw78C2L7c/tUykQXL9QGl20rAo
JhRP/X+6f7g//IBlaWKRKOJQ00B0dWemsL1vvn8PtT/Bz8Lfw+pWaWV3t7lvxa/Gv3OJ4C7QeqKB
/7z/yI/Jn8qmY3CVQMuBwR//zK/Nv8RP0Q/SHxmSq/CS0f9kAM/QihSLQbJwiOArAPux/0kgWcD7
UDVBz1GjYhSQraP/sZeqioxArVDTX9Rv0nysdf+Wv9wP0l/ev9/P4N/h7+L//+QP5R/mL+c/mn+H
bojQYcD/6bCSIItQz9CJYojgJuCLgP16ICDPxHyBsnCsduev6L//6c/q3+vv8t/w7/H/8w/0H/lM
h0FsWxCSIaKQktJnsf9Y8pRwqlCJYpLSpWKIwIiE/6qRiTKVoddV7nT1r/a/98//+N/570zDiabw
DwB/AY8Cn38DrwhfBm8HfwsfDC8NPk+aa4ogbrzQ2FBvYnog+WHAOymIQnnTKnCqAYoy3mOsQWdQ
ipCVoWmywBnQP9dxktOt8okQetDL8HR5/1uvDz8NTaqWJhiUcqvuiMD/z2AqVaUxJuIFnxa/DU8c
b/Mdfx6KSnV8oc9gilHW0fWjc2cqQEmjYqoRlGF50H8ioS6gelF70LzQS1CsMGv/iMDu6e2RfNIf
TyBfHmwu0v99Hye/Hl8qLys/LEqTEGKA8GE/b3OUQC0PLh8sLH5I2eBnYHxxMK8xvywsLf83K5Uw
WcH9MU6wNx00LzU/w7ud2oBIVE1MiNCJID5hWnCVYNnxo0Jq4XVieXrgZC4+gDmfOq8sLFXMUkxZ
kAiuPEHXQBLRg1rgS6B0cDovLymyod6Ad2Z1LowgdVnwbmlZcGQAZ8Evk9AbgS3PYjCmgEVgPRhz
L2LyUEHAMy82ZDc2jCBbUEVGOS1jADAxLkuiIq8/+QjAlABm4GQIwmZKcIMsEHyge0hZUEVBwPhJ
TkuTAEOfRK9Fv0bP80ffSOd9fUohSnBaoAkwwFxjZjFcdRugZjn/TB9NL04/T09QX0j1ZZdlhxcs
4FmPLN45YeA8L0H/P/A+vz/PLC9dj16fNn9jrz85L2D/Yg9gH2YPZx8gTffYcYnxI3AyaD9pT6GN
iRBRa5FUaHWKIDOiUWMLa7BXMSBXMDozMjr7V2A3EDBXIWvfbO/VfawAbm0jcDOmQf8mCTAJ2Tw7
UxkztS6UICSQJPBAZ/tVUngRbXUPCb9nz3G/cs9Ve3JTPjBqb7B0I3BS7WuRWxtjVfRdG1URoX7i
VxsiktKJoHX8kGilYGTne798z2dcVG8jcBtkVgO/rBA9c3kvdh97RVWpQFQrP4avej97T4Lvg/9q
+S1JXkTH745fZ0+K7W4b4HDhi/lcJ2Ewk2+Uf5WP/5afl6+Yv5nPmt+b75z/ng//nx+gL6E/ok+j
X6RspT+Hr4EYNzMxNzNjNlc0KDIxOHBgbKuQZGIAZjM4Ym8zMGMANzRjZGY2MmbhPkAyOTlAeKN4
n4tP74xfkR+SL5M7Q89g/FFIsPxUeSUwI3AcEDgwVPAFEP2TEDsTUNkAUlD+EENwywCIby04WBA5
LTEVr1+yD5Mftw+4H7kqSe+Qbr8wn7rvuP+9X75vvCsn13HCaiJSZG93btfAgiAXPmDak1WjX9qw
bHAu/nDX0UpA7rEZ0j4QJUAcEB/+4MA/wU+/XMTIX3B07l/H4MVhxaQoIlAjQSWBNz5g/aH7YGba
4NlBKS79GSB1hoDDMBIAEXDMERog/9eBrGDM8MbPx9+/XCZyEZL//KDYgMtAzSb+8BTizPD+Qf/Y
Mf5AhoASID6vz0+/T9Qf29UvfftvEVDtQHcSkEpwlSmhayYga9YAZGwTw/8bcDPxw6ESgv5x15Da
0f7w+cQQb2s9ARSDxbPDg/5w39b/2A/WHP7AM9BmE8DhsO/tMUrwxGQz0Gff8CMUzMD/I5H9ocVw
a1AVQBHgKf/fj+/WD+Sv5b/mykLb4b0v6I//Mr8zz+uP7J/nX+8/8E9XIr4vV2BXELzT2eHFcHao
Lx+pP/DWItGCIAUgMjI4/3iPru+v//Ff8m/wf/w//U///l/53/rvqBD0WHR/9i92n/93r/kPAq/7
LJD/AA8BHwof/wsvp98QT/s/DN8N7xQvEq//E78XvxjPGdfiICnQ0aAjUPvbQc2gcMVwOIHcIdMw
FtAV48BpxnBpw1AhIE4/w+DNE8xwHqHLkSQgeGn33DBSYNtQZiWg3XIUzxXf/xbvGp8brxofJR8D
283AxdD/PdDDYNPAIV8ibyN/Jy8oP/8mry3/FA8qjyufMd8wXzFvvzJ/M480nzWvNr8vklAps//E
YduCgiDdccZw43E5wL0A79wgOhDjsOOgdwmQOfHLoH/cYvhQSxCBsMaBxSLMIHn9HSBl0kA6ADf/
OQ86Hzsv/zw/L4O2QIZQgTDdgdMwgbD9HWB1a3E/ot2A3XNBE8xA74GoCFE/gtGRYs3wHYIJMP/a
cUH/Qw9EH0UvRj8vg2uA104A+FDGgiDFYS3Fs9FQem0p4GxNsEjnxWJSZCi6QeOgZsyAzeDjoSCB
0PeJkLXQ23BvS99M703/Tw9/UB8vdEjny2BIgIXAa4B09bTiLVWhbOOgUjbjoMyB+1F3xiBmdCFT
yFXvVv9YD/9ZH1ovWzW1oD+Cy3LF0SDi71xAhcBIR8zAQcYRXEC2QHdHhNNRYbBjzAJcgcuBc/9f
v2DPYd9i72P/L4PN89GAfmzNsFxBIOFS4Pgg3iJi38Ngw9A/YoFQUjd30VBlcf3iIGP1EdJiw9DS
Umlvan/va49sn22vL4Nr0mA/wMuR+0ftzLFJhoByQnCBIOBVQf8IUc3Acy90P3VPdl93by+P2X9i
PEEIUM3AZrYQfRDgdHA6Ly+2QPVhijDd0sEviTOD5MUXInzpe8DrxbCJwGR7wmbagH2wHSAAe0hZ
UEVSTEk4Tksggs+D34TkfX0PhfHagLXQfzBcY2Yx/lxLsH2AB9iH74j/xXF/9y9/5zfQjn83zjkF
IDwv/kF84HuvfL99z37ff++A87dnd3tiP4Jt21AI8G7FsO5nUmQg4srQNNKgzPAJkP/jwNtRPqFR
d10zcx+TT5Rff5Vvln9upcYRysNe4h5CeP+goGdAnC+dP55Pn1+gb4D/a4IPjFF3qsAujI+aIl/5
mSQudLUAhT+GT4ddqs//q9+s4YpPi1+v/7EPrMKPv/+Pj6XPka+jn6SvuP+mzzcfv7rvu/+9D74f
vy+ooEdVsfFJ4HVja9oR9QGjH8FP78Jfw2/Ef6hkX8yPzZ/Oan/G78f/yQ/KH8svxZSNQi3/VWAf
AG+wCXIgAtFwHSDPf9/Qj9Gf0q/Tv9TOQNZSZ0DQd2Z1Ll6gddaf169/2L/Zz9rfqH+pj4xR3Psv
+wlyCXBu5VPf0CDgjSTVZP+tD64fh13lb+Z/54eyb7N//+r/7A/VKLgvt//gb7of3j//30/0v+Fv
v2/2r/e/+M/8b//9f/6P/58ArwG/As8D3wTgXC0tBQ8GHwQsSFGQcuhpcXVHwEM+0FVgl9Lfb5BV
YAgvCT8ELERvIW/g96HBZ+BBoUWZIWgQHsCX0LtockpgYQyPDZ8ELFUekNsfAO4waRFQC+FGXqBR
sXtvsHLBUiBw1QGhwXCSIL5TS7ARfxKPBCy0onVe0NFpQC5icrFQcFGAFw//GB8HLh4acnBcsUrg
VMBwYD8eHBsfHC8ELGdwCxBUTbZMbvBckGFKMEewbnBggndU8XNjcnVicIB8ZC4lcCCPIZ8TnYdg
Osf5b+Rv8BtwaXBIENXSBedKLyQIcy8yMDAEOTEt8DMvYmQ2UYKQZGI1LSktLgAw/DEuJxLoD+kf
6i8rHywv/y0/Lk8vX+3P7t8zTzRfNW//Nn83jych8+/zvwSv9d8mH/8nL0KPRO9F/x3fSw9HT0hf
/0ZvTF9Nb055zm9TL86vT2//UH9OiNUf1i9Vv1bPV93c7/9Zz1rfTn8pXypv8I/xnzBf/zFvMn9j
T2Rf7V85fzqPaV//am9Bv0GPYM9Dr16fX69yf9d033XvdvJFodFveQBYGpZEmWCbsHTGcFZvWLCk
MzXGcXNzC4E0dz/7eE92XCp/34DvgWV8333vC3Zfgqk1g2EvRk9O7lSDuXD/hDBcH1GHmIS4r4RQ
H1GEv/nGN3PCUHQewjBiAS9ESVaG74sPCGc1OHPRQk9EWbl0HTI3c9EjsoOwfZJwAAAeADUQAQAA
ADoAAAA8RTJFMjk1MDNGNzUwQTI0RDgwQzhBMTZCQjZBQzREN0EwNDVCMTM0N0BGQUxDQU8uZnVy
Yi5icj4AAAAeADkQAQAAADgAAAA8bWFpbG1hbi40Ny4xMjU5ODU5NjA0LjMwMjgxLmdyZXRsLWRl
dmVsQGxpc3RzLndmdS5lZHU+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A
8xABAAAAXgAAAFIARQBTACUAMwBBACAARwByAGUAdABsAC0AZABlAHYAZQBsACAARABpAGcAZQBz
AHQALAAgAFYAbwBsACAAMwA1ACwAIABJAHMAcwB1AGUAIAA0AC4ARQBNAEwAAAAAAAsA9hAAAAAA
QAAHMHUfajY/dMoBQAAIMGvX+UA/dMoBAwDeP69vAAADAPE/FgQAAB4A+D8BAAAAEwAAAEJydW5v
IFRoaWFnbyBUb21pbwAAAgH5PwEAAABbAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9P
PUZVUkIvT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9DTj1CVFRP
TUlPAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA
3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAA
AAAAAwAeQAAAAAAeADBAAQAAAAgAAABCVFRPTUlPAB4AMUABAAAACAAAAEJUVE9NSU8AHgAyQAEA
AAAiAAAAZ3JldGwtZGV2ZWwtYm91bmNlc0BsaXN0cy53ZnUuZWR1AAAAHgAzQAEAAAAiAAAAZ3Jl
dGwtZGV2ZWwtcmVxdWVzdEBsaXN0cy53ZnUuZWR1AAAAHgA4QAEAAAAIAAAAQlRUT01JTwAeADlA
AQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEC07nksDAAcQuw4AAAMAEBAA
AAAAAwAREAAAAAAeAAgQAQAAAGUAAABIRU5SSVFVRSxZRVMsSURPRVVGQUxPQUJSQedPUyxCUlVO
T0RFOkdSRVRMLURFVkVMLUJPVU5DRVNATElTVFNXRlVFRFVFTU5PTUVERUdSRVRMLURFVkVMLVJF
UVVFU1RATElTAAAAAAIBfwABAAAAOgAAADxFMkUyOTUwM0Y3NTBBMjREODBDOEExNkJCNkFDNEQ3
QTA0NUIxMzQ3QEZBTENBTy5mdXJiLmJyPgAAAPTU

--===============5514760157173982777==--


From svetosch@gmx.net Sun Dec  6 18:22:52 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject:
 Re: [Gretl-devel] Goodness of Fit test to normal distribution and QQ plot
Date: Mon, 07 Dec 2009 00:22:27 +0100
Message-ID: <4B1C3CB3.6090402@gmx.net>
In-Reply-To: Pine.A41.4.58.0911302143220.2568566@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2942789461514555841=="

--===============2942789461514555841==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Mon, 30 Nov 2009, Sven Schreiber wrote:
> 
>> Costia schrieb:
>>> 2. I haven't found a Q-Q plot test in GRETL, (like in SAS e.g.). I think
>>> it would be a good thing to add it.
>> I agree. It's not difficult to use a quick-and-dirty script to get it
>> done, but properly handling missing values etc. needs more care.
> 
> I haven't messed much with Q-Q plots.  Can anyone confirm if the
> following script is correct?  If so, then I guess we could do it
> as a built-in at some point.

sorry for not answering earlier...

> 
> <script>
> nulldata 500
> scalar n = $nobs
> # artificial series to test
> genr y = sort(normal())
> series Qemp, Qnorm
> scalar p, N, nl, nh
> 
> loop i=1..n -q
>   p = i/(n+1)

>   N = (n + 1) * p - 1;

given your def. of p, wouldn't that be equiv. to N = i-1 ?

>   nl = floor(N);

accordingly redundant? (nl = i-1)

>   nh = ceil(N);

ditto?

>   if (nh == 0 || nh == n)
>     Qemp[i] = NA

don't understand the reason for this: here it seems the first item in
the empirical quantiles will always be set to NA?

>   else
>     Qemp[i] = quantile(y, p)
>   endif
>   Qnorm[i] = critical(N, 1-p)

or rather Qnorm[i] = 1-critical(N,p)? (could make a difference for
discrete distributions, not for continuous as here)

> endloop
> 

and the 45-degree line is needed for comparison

altogether I think something like this also would do the trick (bugs
probably included, even if it's only two lines...):

matrix mp = transp(seq(1,n))/n	
# (col vector of cumulative relative frequencies for n obs)
matrix mQtheory = invcdf(N,mp)	
# BTW, the help about invcdf() says P(X<x), but shouldn't it be P(X<=x)?

and your y (the sorted input series) can already be plotted against
mQtheory to give the QQ plot (if I'm not missing something right now
which may well be the case since I'm a bit tired). You might argue that
this doesn't really deal with ties, but from the various possible
definitions I've seen of quantiles per se and how to deal with ties I
think it's actually legitimate.

Why not just copy the convention and maybe the code from R?

good night,
sven

--===============2942789461514555841==--


From svetosch@gmx.net Mon Dec  7 09:16:27 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] oxgauss
Date: Mon, 07 Dec 2009 15:15:09 +0100
Message-ID: <4B1D0DED.9060606@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5345497548496451561=="

--===============5345497548496451561==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

I would like to ask whether it's worthwhile to enable the OxGauss
functionality in combination with gretl's Ox support. (OxGauss means
that Ox can run many existing Gauss programs.) It seems to me that basic
support would be relatively simple, since only a -g switch is needed; so
for running a Gauss program 'mygauss.prg' gretl would need to call:

<path/to/>oxl -g mygauss.prg

(instead of '<path/to/>oxl myox.ox')

I guess a further issue would be how to pass matrices to what would then
be Gauss code, but note that even without it I think it would already be
useful to be able to do:

<gretl-script>
store @dotdir/mydata.dat --jmulti
# jmulti's format should be same as Gauss (?)
foreign language=OxGauss
  T = 100;	# ugly hardcoding, but not the point here
  k = 2;
  load datamatrix[T,2] = mydata.dat; # hope OxGauss would find this
  print "yeah";
end foreign
</gretl-script>

In terms of user interface I tend to think that no separate script class
for Gauss code (executed via OxGauss) should be introduced, since Gauss
in my view is a little obsolete. But maybe opinions differ on that.

BTW, the background in my case is to build wrappers around the break
test codes of Qu&Perron (Econometrica 2007) or Bai&Perron etc. which are
only available in Gauss, a little lengthy, and also I'm not sure whether
their license would allow porting.

thanks,
sven






--===============5345497548496451561==--


From svetosch@gmx.net Mon Dec  7 10:05:02 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] oxgauss
Date: Mon, 07 Dec 2009 16:04:06 +0100
Message-ID: <4B1D1966.2080702@gmx.net>
In-Reply-To: 4B1D0DED.9060606@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1501408502683090515=="

--===============1501408502683090515==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

BTW, related to Ox support I couldn't find the --with-ox configure
option in the manual (had to dig in the list archives). I could add it
to the cvs tex files, should I?

And the configure script output doesn't mention Ox support in any way
AFAICS, as opposed to libR for example. (That's something I cannot
correct myself.)

thanks,
sven



--===============1501408502683090515==--


From cottrell@wfu.edu Mon Dec  7 10:13:24 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] oxgauss
Date: Mon, 07 Dec 2009 10:13:23 -0500
Message-ID: <Pine.A41.4.58.0912071008420.217450@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B1D1966.2080702@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4746921588400069807=="

--===============4746921588400069807==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 7 Dec 2009, Sven Schreiber wrote:

> BTW, related to Ox support I couldn't find the --with-ox configure
> option in the manual (had to dig in the list archives). I could add it
> to the cvs tex files, should I?

Yes, that would be good.

> And the configure script output doesn't mention Ox support in any way
> AFAICS, as opposed to libR for example. (That's something I cannot
> correct myself.)

It was mentioned in ./configure --help, but not noted in the final
"Configuration:" output.  I've now added it there.

Allin.

--===============4746921588400069807==--


From svetosch@gmx.net Mon Dec  7 13:26:40 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] jmulti data export bug
Date: Mon, 07 Dec 2009 19:26:13 +0100
Message-ID: <4B1D48C5.4040508@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4590705504826077416=="

--===============4590705504826077416==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

exporting data to a jmulti .dat file seems to mess up the variable
description in the exported file. (Haven't tried other export formats.)

thanks,
sven

--===============4590705504826077416==--


From cottrell@wfu.edu Mon Dec  7 14:21:49 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] jmulti data export bug
Date: Mon, 07 Dec 2009 14:21:48 -0500
Message-ID: <Pine.A41.4.58.0912071407460.2482478@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B1D48C5.4040508@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5301962122935030056=="

--===============5301962122935030056==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 7 Dec 2009, Sven Schreiber wrote:

> exporting data to a jmulti .dat file seems to mess up the variable
> description in the exported file. (Haven't tried other export formats.)

Ah, we were exporting the description for the wrong variable (in
general).  Fixed in CVS.

Allin.

--===============5301962122935030056==--


From svetosch@gmx.net Tue Dec  8 07:53:18 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] function namespace bug
Date: Tue, 08 Dec 2009 13:52:34 +0100
Message-ID: <4B1E4C12.8060506@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2217733882116128582=="

--===============2217733882116128582==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
here's the recipe for a function namespace-related bug:

1. open (start to execute) the function package BreitungCandelonTest.gfn
(I did it locally, but I guess the same should happen when opened from
the package server)

2. don't really execute the package, but cancel the package dialog (I
think this is not crucial, but I'm describing exactly what I did) --
note that inside the package there is a helper function 'BCtest_fromto()'

3. have a script named 'func2include_file.inp' in the current working
dir with the following contents (a new definition of the function
BCtest_fromto()):
<script>
function void BCtest_fromto(void)
    print "hello, this is the alternative BCtest_fromto function"
end function
</script>

4. also have the following script file:
<script>
include func2include_file.inp
BCtest_fromto()
</script>

5. get an error like 'symbol BCtest_fromto() unknown' or so

Since the function definition in the package isn't declared "public" I
would expect the new function definition to work normally. Or I would
expect an error when the new function *definition* is encountered, not
at the later stage when that function is called.

Needless (?) to say, the scripts alone run fine without the clash with
the package. (Tested after restarting gretl.)

Thanks,
sven

--===============2217733882116128582==--


From svetosch@gmx.net Tue Dec  8 08:28:51 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] chow test underflow (?) bug
Date: Tue, 08 Dec 2009 14:28:06 +0100
Message-ID: <4B1E5466.8030105@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9212330851202173448=="

--===============9212330851202173448==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi again,

running a regression that includes a shift dummy for 1989q3 and then
doing a Chow test for that exact date gretl omits its own split dummy
due to collinearity (ok, of course) and yields:

a test statistic F(0,148) = 1.#INF,
which is still not so problematic, but then:

a p-value of  P(F(0,148)> 1.#INF) = 1.79769e+308

with a positive exponent and that is clearly wrong. I guess NA would be
more appropriate.

thanks,
sven

--===============9212330851202173448==--


From cottrell@wfu.edu Tue Dec  8 09:46:09 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] chow test underflow (?) bug
Date: Tue, 08 Dec 2009 09:46:08 -0500
Message-ID: <Pine.A41.4.58.0912080931160.3010614@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B1E5466.8030105@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5466393345948547698=="

--===============5466393345948547698==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 8 Dec 2009, Sven Schreiber wrote:

> running a regression that includes a shift dummy for 1989q3 and then
> doing a Chow test for that exact date gretl omits its own split dummy
> due to collinearity (ok, of course) and yields:
>
> a test statistic F(0,148) = 1.#INF,
> which is still not so problematic, but then:
>
> a p-value of  P(F(0,148)> 1.#INF) = 1.79769e+308
>
> with a positive exponent and that is clearly wrong. I guess NA would be
> more appropriate.

That is in fact NA, but we're showing its numerical value, which
is a bug.  Fixed in CVS.

Just to let people know, I'll be mostly offline for a while,
resuming "normal service" later this month.

Allin.



--===============5466393345948547698==--


From svetosch@gmx.net Tue Dec  8 11:18:58 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] bug with variable label in estimation table
Date: Tue, 08 Dec 2009 17:18:32 +0100
Message-ID: <4B1E7C58.4060402@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6028899578409585668=="

--===============6028899578409585668==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Here comes another bug report, I guess the last one for today :-)

Estimating one equation of an underlying VAR with 7 variables and 3 lags
by hand with OLS (don't ask why right now) produces a glitch with one of
the variable names: Instead of 'Yield_10yr_1' the name 'd_Yield_10yr' is
printed. Strangely, 'Yield_10yr_2' and so forth print ok. The other
variable names print 100% ok. Fortunately, I verified that it's only the
label and not a different variable, i.e. the first lag of Yield_10yr is
used alright, not the difference as it looks at first.

This applies to GUI as well as script input, but I couldn't create a
test case with the built-in datasets, sorry. Maybe it has to do with the
underscores in the name?

cheers,
sven

--===============6028899578409585668==--


From marcin@wrzosy.nsb.pl Tue Dec  8 13:34:22 2009
From: Marcin =?utf-8?q?B=C5=82a=C5=BCejowski?= <marcin@wrzosy.nsb.pl>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Small bug in GUI
Date: Tue, 08 Dec 2009 19:34:16 +0100
Message-ID: <4B1E9C28.5040002@wrzosy.nsb.pl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2422206676939548774=="

--===============2422206676939548774==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi,
let's run following script:

---
nulldata 2000
setobs 6 2003/01/03 --time-series
series X = normal()
series Y = normal(1,10)
---
and try to compact data...

But for 5 or 7 day week this option is visible.
Current CVS.

Best Regards,
Marcin

-- 
Marcin Błażejowski
http://www.wrzosy.nsb.pl/~marcin/
GG# 203127



--===============2422206676939548774==--


From r.lucchetti@univpm.it Tue Dec  8 13:52:20 2009
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Small bug in GUI
Date: Tue, 08 Dec 2009 19:52:17 +0100
Message-ID: <alpine.DEB.2.00.0912081946400.6081@ec-4.econ.univpm.it>
In-Reply-To: 4B1E9C28.5040002@wrzosy.nsb.pl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1770008489205183374=="

--===============1770008489205183374==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 8 Dec 2009, Marcin B=C5=82a=C5=BCejowski wrote:

> Hi,
> let's run following script:
>
> ---
> nulldata 2000
> setobs 6 2003/01/03 --time-series
> series X =3D normal()
> series Y =3D normal(1,10)
> ---
> and try to compact data...
>
> But for 5 or 7 day week this option is visible.
> Current CVS.

Bug acknowledged. However, the data compaction operation can be done (the=20
command "dataset compact 52" works fine). It's a GUI bug, easily fixed:

Index: gui2/menustate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/gretl/gretl/gui2/menustate.c,v
retrieving revision 1.112
diff -u -r1.112 menustate.c
--- gui2/menustate.c    2 Dec 2009 15:45:17 -0000       1.112
+++ gui2/menustate.c    8 Dec 2009 18:51:39 -0000
@@ -177,8 +177,8 @@

  #define COMPACTABLE(d) (d->structure =3D=3D TIME_SERIES && \
                          (d->pd =3D=3D 4 || d->pd =3D=3D 12 || \
-                         d->pd =3D=3D 5 || d->pd =3D=3D 7 || \
-                         d->pd =3D=3D 24))
+                         d->pd =3D=3D 5 || d->pd =3D=3D 6 || \
+                         d->pd =3D=3D 7 || d->pd =3D=3D 24))

  #define EXPANSIBLE(d) (d->structure =3D=3D TIME_SERIES && (d->pd =3D=3D 1 |=
| d->pd =3D=3D 4))



Riccardo (Jack) Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============1770008489205183374==--


From r.lucchetti@univpm.it Tue Dec  8 14:34:30 2009
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Small bug in GUI
Date: Tue, 08 Dec 2009 20:34:23 +0100
Message-ID: <alpine.DEB.2.00.0912082033550.6081@ec-4.econ.univpm.it>
In-Reply-To: alpine.DEB.2.00.0912081946400.6081@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1624815041889338478=="

--===============1624815041889338478==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 8 Dec 2009, Riccardo (Jack) Lucchetti wrote:

> Bug acknowledged. However, the data compaction operation can be done (the 
> command "dataset compact 52" works fine). It's a GUI bug, easily fixed:

Now in CVS.


Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============1624815041889338478==--


From marcin@wrzosy.nsb.pl Tue Dec  8 14:49:12 2009
From: Marcin =?utf-8?q?B=C5=82a=C5=BCejowski?= <marcin@wrzosy.nsb.pl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Small bug in GUI
Date: Tue, 08 Dec 2009 20:49:06 +0100
Message-ID: <4B1EADB2.7030503@wrzosy.nsb.pl>
In-Reply-To: alpine.DEB.2.00.0912082033550.6081@ec-4.econ.univpm.it
Content-Type: multipart/mixed; boundary="===============8224981205941439780=="

--===============8224981205941439780==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1V
VEYtOCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4KPC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIj
ZmZmZmZmIiB0ZXh0PSIjMDAwMDAwIj4KVGhlcmUgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlIHdp
bmRvdyB3aXRoIG9wdGlvbnMgZm9yIGNvbXBhY3Rpbmc6PGJyPgo8YnI+CjEuIHdoZW4gSSBoZXZl
IGRhaWx5IGRhdGEsIEkgY2FuIGNob29zZSB3YXkgb2YgYWdncmVnYXRpb24sIGJ1dCBJIGNhbid0
CmNob29zZSBmcmVxdWVuY3k8YnI+CjIuIHdoZW4gSSBoYXZlIHdlZWtseSBkYXRhLCBJIGNhbiBv
bmx5IGFnZ3JhZ2F0ZSBieSBhdmVnYXJpbmcgYW5kIHN0aWxsCmNhbid0IGNob29zZSBmcmVxdWVu
Y3k8YnI+Cjxicj4KTWFyY2luPGJyPgo8YnI+Cjxicj4KUmljY2FyZG8gKEphY2spIEx1Y2NoZXR0
aSBwaXN6ZToKPGJsb2NrcXVvdGUKIGNpdGU9Im1pZDphbHBpbmUuREVCLjIuMDAuMDkxMjA4MjAz
MzU1MC42MDgxQGVjLTQuZWNvbi51bml2cG0uaXQiCiB0eXBlPSJjaXRlIj5PbiBUdWUsIDggRGVj
IDIwMDksIFJpY2NhcmRvIChKYWNrKSBMdWNjaGV0dGkgd3JvdGU6CiAgPGJyPgogIDxicj4KICA8
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5CdWcgYWNrbm93bGVkZ2VkLiBIb3dldmVyLCB0aGUgZGF0
YQpjb21wYWN0aW9uIG9wZXJhdGlvbiBjYW4gYmUgZG9uZSAodGhlIGNvbW1hbmQgImRhdGFzZXQg
Y29tcGFjdCA1MiIKd29ya3MgZmluZSkuIEl0J3MgYSBHVUkgYnVnLCBlYXNpbHkgZml4ZWQ6CiAg
ICA8YnI+CiAgPC9ibG9ja3F1b3RlPgogIDxicj4KTm93IGluIENWUy4KICA8YnI+CiAgPGJyPgog
IDxicj4KUmljY2FyZG8gKEphY2spIEx1Y2NoZXR0aQogIDxicj4KRGlwYXJ0aW1lbnRvIGRpIEVj
b25vbWlhCiAgPGJyPgpVbml2ZXJzaXTDoCBQb2xpdGVjbmljYSBkZWxsZSBNYXJjaGUKICA8YnI+
CiAgPGJyPgo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86
ci5sdWNjaGV0dGlAdW5pdnBtLml0Ij5yLmx1Y2NoZXR0aUB1bml2cG0uaXQ8L2E+CiAgPGJyPgo8
YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3LmVjb24udW5p
dnBtLml0L2x1Y2NoZXR0aSI+aHR0cDovL3d3dy5lY29uLnVuaXZwbS5pdC9sdWNjaGV0dGk8L2E+
PGJyPgogIDxwcmUgd3JhcD0iIj4KPGhyIHNpemU9IjQiIHdpZHRoPSI5MCUiPgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpHcmV0bC1kZXZlbCBtYWlsaW5n
IGxpc3QKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkdy
ZXRsLWRldmVsQGxpc3RzLndmdS5lZHUiPkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHU8L2E+Cjxh
IGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly9saXN0cy53ZnUuZWR1
L21haWxtYW4vbGlzdGluZm8vZ3JldGwtZGV2ZWwiPmh0dHA6Ly9saXN0cy53ZnUuZWR1L21haWxt
YW4vbGlzdGluZm8vZ3JldGwtZGV2ZWw8L2E+PC9wcmU+CjwvYmxvY2txdW90ZT4KPGJyPgo8YnI+
CjxwcmUgY2xhc3M9Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSAKTWFyY2luIELFgmHFvGVq
b3dza2kKPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3d3dy53
cnpvc3kubnNiLnBsL35tYXJjaW4vIj5odHRwOi8vd3d3Lndyem9zeS5uc2IucGwvfm1hcmNpbi88
L2E+CkdHIyAyMDMxMjcKPC9wcmU+CjwvYm9keT4KPC9odG1sPgo=

--===============8224981205941439780==--


From svetosch@gmx.net Wed Dec  9 13:04:56 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] off-by-one error in index loop?
Date: Wed, 09 Dec 2009 19:04:19 +0100
Message-ID: <4B1FE6A3.9000508@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1966133201652724552=="

--===============1966133201652724552==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi,

the following minimal demonstration script:

<script>
open denmark
loop i=1985:1..1985:4
    printf "the period: %s\n", obslabel(i)
end loop
</script>

yields the following output for me:

<output>
gretl-Version 1.8.6cvs
Aktuelle Sitzung: 2009-12-09 19:00
? open denmark

Lese Datendatei /usr/local/share/gretl/data/misc/denmark.gdt
Periodizität: 4, max-Beob.: 55,
Beobachtungsbereich: 1974:1-1987:3

Liste 5 Variablen auf:
  0) const    1) LRM      2) LRY      3) IBO      4) IDE

? loop i=1985:1..1985:4
> printf "the period: %s\n", obslabel(i)
> end loop
loop: i = 1985:2

the period: 1985:1
loop: i = 1985:3

the period: 1985:2
loop: i = 1985:4

the period: 1985:3
loop: i = 1986:1

the period: 1985:4

Anzahl an Iterationen: 4
</output>

Notice that gretl's echo/message w.r.t. the loop index seems to be ahead
of the actual loop index by one. But the bug seems harmless, as nothing
substantial is affected.

Or am I missing something?

thanks,
sven


--===============1966133201652724552==--


From cottrell@wfu.edu Wed Dec  9 16:22:43 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] off-by-one error in index loop?
Date: Wed, 09 Dec 2009 16:22:42 -0500
Message-ID: <Pine.A41.4.58.0912091620200.2670978@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B1FE6A3.9000508@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6724937051655707932=="

--===============6724937051655707932==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Wed, 9 Dec 2009, Sven Schreiber wrote:

> <script>
> open denmark
> loop i=1985:1..1985:4
>     printf "the period: %s\n", obslabel(i)
> end loop
> </script>

This is a quick one I can address without reliable internet
access.  I see obslabel() is doing the right thing but the
automatic printout of "loop: i = ..." is indeed off by one
for dates.  Will fix shortly.

Allin.


--===============6724937051655707932==--


From svetosch@gmx.net Thu Dec 10 08:48:09 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] restrict --silent
Date: Thu, 10 Dec 2009 14:47:22 +0100
Message-ID: <4B20FBEA.9010000@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2958095797117679218=="

--===============2958095797117679218==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

hi,

a silent option for restrict would be nice....

thanks,
sven

--===============2958095797117679218==--


From ignacio.diaz-emparanza@ehu.es Thu Dec 10 09:13:50 2009
From: Ignacio Diaz-Emparanza <ignacio.diaz-emparanza@ehu.es>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] rmplot
Date: Thu, 10 Dec 2009 15:13:45 +0100
Message-ID: <1260454425.2176.13.camel@U001082.ehu.es>
In-Reply-To: 4B20FBEA.9010000@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1342546631512939431=="

--===============1342546631512939431==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The command 'rmplot' is defined only for the GUI. I think it would be
very good if we could use it also in scripts. I think the result should
be no more than the current text output, and the t statistic and pvalue
could be saved in th $test and $pvalue variables.



-- 
Ignacio Diaz-Emparanza  
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es 



--===============1342546631512939431==--


From svetosch@gmx.net Thu Dec 10 11:27:11 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] bootstrapped test results
Date: Thu, 10 Dec 2009 17:26:22 +0100
Message-ID: <4B21212E.8010507@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5509311477054722333=="

--===============5509311477054722333==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

it seems it's not currently possible to access the results of a
bootstrapped restriction test?

I just did:
restrict --bootstrap
<whatever>
end restrict
stat = $test
p = $pvalue

and stat and p then hold the output of the standard Wald test, which is
misleading IMHO. Instead I would suggest to set $test to NA or something
like that, while $pvalue should give the bootstrapped rejection frequency.

Also, an option to set the number of replications would be useful (e.g.
resrict --bootstrap=5000).

thanks,
sven


--===============5509311477054722333==--


From r.lucchetti@univpm.it Thu Dec 10 20:34:58 2009
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict --silent
Date: Fri, 11 Dec 2009 02:34:50 +0100
Message-ID: <alpine.DEB.2.00.0912110233310.10777@ec-4.econ.univpm.it>
In-Reply-To: 4B20FBEA.9010000@gmx.net
Content-Type: multipart/mixed; boundary="===============8847256792369108135=="

--===============8847256792369108135==
Content-Type: text/x-diff
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="silent_restrict.diff"
MIME-Version: 1.0

SW5kZXg6IGxpYi9zcmMvZ3JldGxfcmVzdHJpY3QuYw0KPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9j
dnNyb290L2dyZXRsL2dyZXRsL2xpYi9zcmMvZ3JldGxfcmVzdHJpY3QuYyx2DQpyZXRyaWV2aW5n
IHJldmlzaW9uIDEuMTQwDQpkaWZmIC11IC1yMS4xNDAgZ3JldGxfcmVzdHJpY3QuYw0KLS0tIGxp
Yi9zcmMvZ3JldGxfcmVzdHJpY3QuYwkxOSBTZXAgMjAwOSAxODoyMTo0MiAtMDAwMAkxLjE0MA0K
KysrIGxpYi9zcmMvZ3JldGxfcmVzdHJpY3QuYwkxMSBEZWMgMjAwOSAwMTozMTowNyAtMDAwMA0K
QEAgLTE5MTMsNiArMTkxMyw4IEBADQogew0KICAgICBNT0RFTCAqcG1vZCA9IHJzZXQtPm9iajsN
CiAgICAgaW50IHJvYnVzdCwgYXN5bSA9IDA7DQorICAgIGludCBxdWlldCAgPSAocnNldC0+b3B0
ICYgT1BUX1EpOw0KKyAgICBpbnQgc2lsZW50ID0gKHJzZXQtPm9wdCAmIE9QVF9TKTsNCiANCiAg
ICAgcm9idXN0ID0gKHBtb2QtPm9wdCAmIE9QVF9SKTsNCiANCkBAIC0xOTIzLDI4ICsxOTI1LDM1
IEBADQogICAgIGlmIChhc3ltKSB7DQogCXJzZXQtPmNvZGUgPSBHUkVUTF9TVEFUX1dBTERfQ0hJ
U1E7DQogCXJzZXQtPnB2YWwgPSBjaGlzcV9jZGZfY29tcChyc2V0LT5nLCByc2V0LT50ZXN0KTsN
Ci0JcHByaW50Zihwcm4sICJcbiVzOiAlcyglZCkgPSAlZywgIiwgXygiVGVzdCBzdGF0aXN0aWMi
KSwgDQotCQkocm9idXN0KT8gXygiUm9idXN0IGNoaV4yIik6ICJjaGleMiIsDQotCQlyc2V0LT5n
LCByc2V0LT50ZXN0KTsNCisJaWYgKCFzaWxlbnQpIHsNCisJICAgIHBwcmludGYocHJuLCAiXG4l
czogJXMoJWQpID0gJWcsICIsIF8oIlRlc3Qgc3RhdGlzdGljIiksIA0KKwkJICAgIChyb2J1c3Qp
PyBfKCJSb2J1c3QgY2hpXjIiKTogImNoaV4yIiwNCisJCSAgICByc2V0LT5nLCByc2V0LT50ZXN0
KTsNCisJfQ0KICAgICB9IGVsc2Ugew0KIAlyc2V0LT5jb2RlID0gR1JFVExfU1RBVF9GOw0KIAly
c2V0LT50ZXN0IC89IHJzZXQtPmc7DQogCXJzZXQtPnB2YWwgPSBzbmVkZWNvcl9jZGZfY29tcChy
c2V0LT5nLCBwbW9kLT5kZmQsIHJzZXQtPnRlc3QpOw0KLQlwcHJpbnRmKHBybiwgIlxuJXM6ICVz
KCVkLCAlZCkgPSAlZywgIiwgXygiVGVzdCBzdGF0aXN0aWMiKSwgDQotCQkocm9idXN0KT8gXygi
Um9idXN0IEYiKTogIkYiLA0KLQkJcnNldC0+ZywgcG1vZC0+ZGZkLCByc2V0LT50ZXN0KTsNCisJ
aWYgKCFzaWxlbnQpIHsNCisJICAgIHBwcmludGYocHJuLCAiXG4lczogJXMoJWQsICVkKSA9ICVn
LCAiLCBfKCJUZXN0IHN0YXRpc3RpYyIpLCANCisJCSAgICAocm9idXN0KT8gXygiUm9idXN0IEYi
KTogIkYiLA0KKwkJICAgIHJzZXQtPmcsIHBtb2QtPmRmZCwgcnNldC0+dGVzdCk7DQorCX0NCiAg
ICAgfQ0KIA0KLSAgICBpZiAoIW5hKHJzZXQtPnB2YWwpKSB7DQorICAgIGlmICghbmEocnNldC0+
cHZhbCkgJiYgIXNpbGVudCkgew0KIAlwcHJpbnRmKHBybiwgXygid2l0aCBwLXZhbHVlID0gJWdc
biIpLCByc2V0LT5wdmFsKTsNCiAgICAgfQ0KLSAgICBwcHV0Yyhwcm4sICdcbicpOw0KKw0KKyAg
ICBpZiAoIXNpbGVudCkgew0KKwlwcHV0Yyhwcm4sICdcbicpOw0KKyAgICB9DQogDQogICAgIGlm
ICghKHJzZXQtPm9wdCAmIE9QVF9DKSkgew0KIAlyZWNvcmRfdGVzdF9yZXN1bHQocnNldC0+dGVz
dCwgcnNldC0+cHZhbCwgXygicmVzdHJpY3Rpb24iKSk7DQogICAgIH0NCiANCi0gICAgaWYgKHBt
b2QgIT0gTlVMTCAmJiBaICE9IE5VTEwgJiYgIShyc2V0LT5vcHQgJiBPUFRfUSkgDQorICAgIGlm
IChwbW9kICE9IE5VTEwgJiYgWiAhPSBOVUxMICYmICEocXVpZXQgfHwgc2lsZW50KQ0KIAkmJiBw
bW9kLT5jaSA9PSBPTFMpIHsNCiAJZG9fcmVzdHJpY3RlZF9lc3RpbWF0ZXMocnNldCwgWiwgcGRp
bmZvLCBwcm4pOw0KICAgICB9DQpAQCAtMjMyMiw2ICsyMzMxLDcgQEANCiB7DQogICAgIGludCB0
ID0gcnNldC0+b3R5cGU7DQogICAgIGludCBlcnIgPSAwOw0KKyAgICBpbnQgc2lsZW50ID0gKHJz
ZXQtPm9wdCB8IG9wdCkgJiBPUFRfUzsNCiANCiAjaWYgUkRFQlVHDQogICAgIGZwcmludGYoc3Rk
ZXJyLCAiZ3JldGxfcmVzdHJpY3Rpb25fZmluYWxpemUoKVxuIik7DQpAQCAtMjM0Nyw3ICsyMzU3
LDcgQEANCiAJfQ0KICAgICB9DQogDQotICAgIGlmIChyc2V0LT5yb3dzICE9IE5VTEwpIHsNCisg
ICAgaWYgKChyc2V0LT5yb3dzICE9IE5VTEwpICYmICFzaWxlbnQpIHsNCiAJcHJpbnRfcmVzdHJp
Y3Rpb25fc2V0KHJzZXQsIHBkaW5mbywgcHJuKTsNCiAgICAgfQ0KIA0KSW5kZXg6IGxpYi9zcmMv
b3B0aW9ucy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2c3Jvb3QvZ3JldGwvZ3JldGwvbGli
L3NyYy9vcHRpb25zLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMyMA0KZGlmZiAtdSAtcjEu
MzIwIG9wdGlvbnMuYw0KLS0tIGxpYi9zcmMvb3B0aW9ucy5jCTEgRGVjIDIwMDkgMDI6MzE6MTYg
LTAwMDAJMS4zMjANCisrKyBsaWIvc3JjL29wdGlvbnMuYwkxMSBEZWMgMjAwOSAwMTozMTowOCAt
MDAwMA0KQEAgLTMxMSw2ICszMTEsNyBAQA0KICAgICB7IFJFU1RSSUNULCBPUFRfViwgInZlcmJv
c2UiLCAwIH0sDQogICAgIHsgUkVTVFJJQ1QsIE9QVF9MLCAibGJmZ3MiLCAwIH0sDQogICAgIHsg
UkVTVFJJQ1QsIE9QVF9OLCAibm8tc2NhbGluZyIsIDAgfSwNCisgICAgeyBSRVNUUklDVCwgT1BU
X1MsICJzaWxlbnQiLCAwIH0sDQogICAgIHsgUlVOUywgICAgIE9QVF9ELCAiZGlmZmVyZW5jZSIs
IDAgfSwNCiAgICAgeyBSVU5TLCAgICAgT1BUX0UsICJlcXVhbCIsIDAgfSwNCiAgICAgeyBTQ0FU
VEVSUywgT1BUX0wsICJ3aXRoLWxpbmVzIiwgMCB9LA0K

--===============8847256792369108135==--


From svetosch@gmx.net Fri Dec 11 06:40:47 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] gretl usage in Germany
Date: Fri, 11 Dec 2009 12:40:00 +0100
Message-ID: <4B222F90.5070404@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8546048942623118711=="

--===============8546048942623118711==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Dear all,

as a change from my flood of bug reports I thought I'd share this
information with you: At the institute where I am working we regularly
receive applications for internships from German (-speaking) students.
Right now it's especially noticeable because the semester break in
February/March is approaching. And what's interesting is that in their
CVs quite many (maybe half?) of the applicants mention that they are
familiar with gretl. That must be because it was taught at their home
university. (And no, they are not applying directly to me, so it's not
because they want to pamper me -- actually I don't think that the
average student looks at the info box and remembers the name of the
translator there.)

So I think gretl is definitely on the rise in the German-speaking region.

have a good weekend,
sven

--===============8546048942623118711==--


From svetosch@gmx.net Fri Dec 11 06:45:19 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict --silent
Date: Fri, 11 Dec 2009 12:44:45 +0100
Message-ID: <4B2230AD.3050504@gmx.net>
In-Reply-To: alpine.DEB.2.00.0912110233310.10777@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3442917915761175001=="

--===============3442917915761175001==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Riccardo (Jack) Lucchetti schrieb:
> On Thu, 10 Dec 2009, Sven Schreiber wrote:
> 
>> hi,
>>
>> a silent option for restrict would be nice....
> 
> Sven,
> 
> see if the attached patch does what you want. I'm not making commits to
> CVS till Allin's back, but in the meantime you can try it out.
> 

Thanks Jack -- but I have never applied a diff that affects several
files I think. I'm sure it's just a one-liner?

-sven

--===============3442917915761175001==--


From moradan228@gmail.com Fri Dec 11 07:41:41 2009
From: Ivan Sopov <moradan228@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Fri, 11 Dec 2009 14:41:39 +0200
Message-ID: <7e0e63490912110441l2e7fcff7h711442167bf1af96@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6865110246354439342=="

--===============6865110246354439342==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hello, our project at launchpad have recently past the stage of manual
import of the template stage and we are able to start translation of
the help system on Launchpad.

Here is the link to the translation in russian:
https://translations.launchpad.net/gretl/trunk/+pots/gretl-help/ru/+translate

Here is the link to the template:
https://translations.launchpad.net/gretl/trunk/+pots/gretl-help

I'm currently not on my linux laptop so I will try to generate
.po-files for pt_BR some time later as it was requested. We'll look
what it will be.


---------- Forwarded message ----------
From:  <rosetta(a)launchpad.net>
Date: 2009/12/11
Subject: Translation template import - gretl-help in gretl trunk
To: moradan228(a)gmail.com


Hello Ivan Sopov,

On 2009-12-06 09:27z (5 days 2 hours 52 minutes ago), you uploaded a
translation template for gretl-help in gretl trunk in Launchpad.

The template has now been imported successfully.


Thank you,

The Launchpad team

--===============6865110246354439342==--


From marcin@wrzosy.nsb.pl Fri Dec 11 08:01:07 2009
From: Marcin =?utf-8?q?B=C5=82a=C5=BCejowski?= <marcin@wrzosy.nsb.pl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict --silent
Date: Fri, 11 Dec 2009 14:01:03 +0100
Message-ID: <4B22428F.2000804@wrzosy.nsb.pl>
In-Reply-To: 4B2230AD.3050504@gmx.net
Content-Type: multipart/mixed; boundary="===============7327257976764329567=="

--===============7327257976764329567==
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="marcin.vcf"
MIME-Version: 1.0

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6TWFyY2luIEI9QzU9ODJhPUM1PUJDZWpv
d3NraQ0KbjtxdW90ZWQtcHJpbnRhYmxlOkI9QzU9ODJhPUM1PUJDZWpvd3NraTtNYXJjaW4NCmVt
YWlsO2ludGVybmV0Om1hcmNpbkB3cnpvc3kubnNiLnBsDQpub3RlOkdHOiAyMDMxMjcNCngtbW96
aWxsYS1odG1sOlRSVUUNCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K

--===============7327257976764329567==--


From henrique.coelho@gmail.com Fri Dec 11 14:08:25 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Fri, 11 Dec 2009 17:08:03 -0200
Message-ID: <b3173c600912111108y15e6ed29pe9636cb2c0df1b7@mail.gmail.com>
In-Reply-To: 7e0e63490912110441l2e7fcff7h711442167bf1af96@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============5781967260357585966=="

--===============5781967260357585966==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIDExIGRlIGRlemVtYnJvIGRlIDIwMDkgSXZhbiBl
c2NyZXZldTo8c3BhbiBkaXI9Imx0ciI+PC9zcGFuPjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21h
aWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0
KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5IZWxsbywg
b3VyIHByb2plY3QgYXQgbGF1bmNocGFkIGhhdmUgcmVjZW50bHkgcGFzdCB0aGUgc3RhZ2Ugb2Yg
bWFudWFsPGJyPgoKCmltcG9ydCBvZiB0aGUgdGVtcGxhdGUgc3RhZ2UgYW5kIHdlIGFyZSBhYmxl
IHRvIHN0YXJ0IHRyYW5zbGF0aW9uIG9mPGJyPgp0aGUgaGVscCBzeXN0ZW0gb24gTGF1bmNocGFk
Ljxicj4KPC9ibG9ja3F1b3RlPjxkaXY+PGJyPlRoaXMgaXMgZ3JlYXQhIE1ha2UgdHJhbnNsYXRp
b25zIHVzaW5nIC5wbyBmaWxlcyByZWFsbHkgaGVscHMuIFRoYW5rIHlvdSBJdmFuITwvZGl2Pjxk
aXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRl
ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0
IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCkhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIHRl
bXBsYXRlOjxicj4KPGEgaHJlZj0iaHR0cHM6Ly90cmFuc2xhdGlvbnMubGF1bmNocGFkLm5ldC9n
cmV0bC90cnVuay8rcG90cy9ncmV0bC1oZWxwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90cmFu
c2xhdGlvbnMubGF1bmNocGFkLm5ldC9ncmV0bC90cnVuay8rcG90cy9ncmV0bC1oZWxwPC9hPjxi
cj4KPGJyPgpJJiMzOTttIGN1cnJlbnRseSBub3Qgb24gbXkgbGludXggbGFwdG9wIHNvIEkgd2ls
bCB0cnkgdG8gZ2VuZXJhdGU8YnI+Ci5wby1maWxlcyBmb3IgcHRfQlIgc29tZSB0aW1lIGxhdGVy
IGFzIGl0IHdhcyByZXF1ZXN0ZWQuIFdlJiMzOTtsbCBsb29rPGJyPgp3aGF0IGl0IHdpbGwgYmUu
PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj5JJiMzOTtkIHN0YXJ0ZWQgdGhlIHRyYW5zbGF0aW9u
IG9mIHRoZSBwdF9CUiByaWdodCBub3cuIEkgaG9wZSBJIGNhbiBmaW5pc2ggdGhpcyBhcyBzb29u
IGFzIHBvc3NpYmxlLjxicj48YnI+QmVzdCw8YnI+SGVucmlxdWU8YnI+PC9kaXY+PC9kaXY+Cg==

--===============5781967260357585966==--


From henrique.coelho@gmail.com Fri Dec 11 14:20:37 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl usage in Germany
Date: Fri, 11 Dec 2009 17:20:15 -0200
Message-ID: <b3173c600912111120s15af679wf94b652a8bb75d@mail.gmail.com>
In-Reply-To: 4B222F90.5070404@gmx.net
Content-Type: multipart/mixed; boundary="===============7177950001120989769=="

--===============7177950001120989769==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIGRlemVtYnJvIGRlIDIwMDkgU3ZlbiBlc2NyZXZl
dTo8c3BhbiBkaXI9Imx0ciI+PC9zcGFuPjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv
dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy
Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4gKC4uLikgQXQgdGhl
IGluc3RpdHV0ZSB3aGVyZSBJIGFtIHdvcmtpbmcgd2UgcmVndWxhcmx5IHJlY2VpdmUgYXBwbGlj
YXRpb25zPGJyPgoKCgpmb3IgaW50ZXJuc2hpcHMgZnJvbSBHZXJtYW4gKC1zcGVha2luZykgc3R1
ZGVudHMuICguLi4pICBBbmQgd2hhdCYjMzk7czxicj4gaW50ZXJlc3RpbmcKaXMgdGhhdCBpbiB0
aGVpciAKQ1ZzIHF1aXRlIG1hbnkgKG1heWJlIGhhbGY/KSBvZiB0aGUgYXBwbGljYW50czxicj5t
ZW50aW9uIHRoYXQgdGhleSBhcmUgZmFtaWxpYXIgd2l0aCBncmV0bC48YnI+PC9ibG9ja3F1b3Rl
PjxkaXY+PGJyPlRoaXMgaXMgdmVyeSBnb29kITxicj6gPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9
ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs
IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CgoK
KEFuZCBubywgdGhleSBhcmUgbm90IGFwcGx5aW5nIGRpcmVjdGx5IHRvIG1lLCBzbyBpdCYjMzk7
cyBub3Q8YnI+CmJlY2F1c2UgdGhleSB3YW50IHRvIHBhbXBlciBtZSAtLSBhY3R1YWxseSBJIGRv
biYjMzk7dCB0aGluayB0aGF0IHRoZTxicj4KYXZlcmFnZSBzdHVkZW50IGxvb2tzIGF0IHRoZSBp
bmZvIGJveCBhbmQgcmVtZW1iZXJzIHRoZSBuYW1lIG9mIHRoZTxicj4KdHJhbnNsYXRvciB0aGVy
ZS4pPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj46KTxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0
LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4
OyI+ClNvIEkgdGhpbmsgZ3JldGwgaXMgZGVmaW5pdGVseSBvbiB0aGUgcmlzZSBpbiB0aGUgR2Vy
bWFuLXNwZWFraW5nIHJlZ2lvbi48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+SXQgd291bGQg
YmUgbmljZSBpZiB0aGUgc2FtZSBvY2N1cnMgaGVyZSBpbiBCcmF6aWwhPGJyPjxicj5CZXN0LDxi
cj5IZW5yaXF1ZTxicj4K

--===============7177950001120989769==--


From artur.tarassow@googlemail.com Fri Dec 11 14:25:07 2009
From: Artur T. <artur.tarassow@googlemail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl usage in Germany
Date: Fri, 11 Dec 2009 19:25:01 +0000
Message-ID: <4B229C8D.6080905@googlemail.com>
In-Reply-To: b3173c600912111120s15af679wf94b652a8bb75d@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3856784849055420292=="

--===============3856784849055420292==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Henrique schrieb:
> Em dezembro de 2009 Sven escreveu:
>
>     (...) At the institute where I am working we regularly receive
>     applications
>     for internships from German (-speaking) students. (...) And what's
>     interesting is that in their CVs quite many (maybe half?) of the
>     applicants
>     mention that they are familiar with gretl.
>
>
> This is very good!
>  
>
>     (And no, they are not applying directly to me, so it's not
>     because they want to pamper me -- actually I don't think that the
>     average student looks at the info box and remembers the name of the
>     translator there.)
>
>
> :)
>
>     So I think gretl is definitely on the rise in the German-speaking
>     region.
>
>
> It would be nice if the same occurs here in Brazil!
>
> Best,
> Henrique
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
That's sounds good! But actually I am quite surprised. Personally I do 
not know so many students in Germany who use it.

Here in Leeds I am just on a "mission" to advertise gretl. My student 
mates like it more than microfit or stata ;)

Best,
Artur



--===============3856784849055420292==--


From helioxentric@gmail.com Fri Dec 11 16:20:13 2009
From: =?utf-8?q?H=C3=A9lio?= Guilherme <helioxentric@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Gretl project on the launchpad
Date: Fri, 11 Dec 2009 21:20:10 +0000
Message-ID: <5be765950912111320r1cb3e78x53cc27ea8219206f@mail.gmail.com>
In-Reply-To: b3173c600912111108y15e6ed29pe9636cb2c0df1b7@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============2505708560192088220=="

--===============2505708560192088220==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

R29vZCA6KS48YnI+PGJyPkkgd2lsbCB1c2UgeW91ciBwdF9CUiB0cmFuc2xhdGlvbiB0byBhZGFw
dCB0byBwdF9QVC48YnI+PGJyPkNoZWVycyw8YnI+SMOpbGlvIEd1aWxoZXJtZTxicj48YnI+PGJy
PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIERlYyAxMSwgMjAwOSBhdCA3OjA4IFBN
LCBIZW5yaXF1ZSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpoZW5yaXF1ZS5j
b2VsaG9AZ21haWwuY29tIj5oZW5yaXF1ZS5jb2VsaG9AZ21haWwuY29tPC9hPiZndDs8L3NwYW4+
IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVy
LWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQg
MC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIDEx
IGRlIGRlemVtYnJvIGRlIDIwMDkgSXZhbiBlc2NyZXZldTo8ZGl2IGNsYXNzPSJpbSI+PHNwYW4g
ZGlyPSJsdHIiPjwvc3Bhbj48YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5
bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBw
dCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPkhlbGxvLCBvdXIgcHJvamVjdCBh
dCBsYXVuY2hwYWQgaGF2ZSByZWNlbnRseSBwYXN0IHRoZSBzdGFnZSBvZiBtYW51YWw8YnI+CgoK
aW1wb3J0IG9mIHRoZSB0ZW1wbGF0ZSBzdGFnZSBhbmQgd2UgYXJlIGFibGUgdG8gc3RhcnQgdHJh
bnNsYXRpb24gb2Y8YnI+CnRoZSBoZWxwIHN5c3RlbSBvbiBMYXVuY2hwYWQuPGJyPgo8L2Jsb2Nr
cXVvdGU+PC9kaXY+PGRpdj48YnI+VGhpcyBpcyBncmVhdCEgTWFrZSB0cmFuc2xhdGlvbnMgdXNp
bmcgLnBvIGZpbGVzIHJlYWxseSBoZWxwcy4gVGhhbmsgeW91IEl2YW4hPC9kaXY+PGRpdiBjbGFz
cz0iaW0iPjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5
bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBw
dCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCgpIZXJlIGlzIHRoZSBsaW5r
IHRvIHRoZSB0ZW1wbGF0ZTo8YnI+CjxhIGhyZWY9Imh0dHBzOi8vdHJhbnNsYXRpb25zLmxhdW5j
aHBhZC5uZXQvZ3JldGwvdHJ1bmsvK3BvdHMvZ3JldGwtaGVscCIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vdHJhbnNsYXRpb25zLmxhdW5jaHBhZC5uZXQvZ3JldGwvdHJ1bmsvK3BvdHMvZ3JldGwt
aGVscDwvYT48YnI+Cjxicj4KSSYjMzk7bSBjdXJyZW50bHkgbm90IG9uIG15IGxpbnV4IGxhcHRv
cCBzbyBJIHdpbGwgdHJ5IHRvIGdlbmVyYXRlPGJyPgoucG8tZmlsZXMgZm9yIHB0X0JSIHNvbWUg
dGltZSBsYXRlciBhcyBpdCB3YXMgcmVxdWVzdGVkLiBXZSYjMzk7bGwgbG9vazxicj4Kd2hhdCBp
dCB3aWxsIGJlLjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGRpdj48YnI+SSYjMzk7ZCBzdGFydGVk
IHRoZSB0cmFuc2xhdGlvbiBvZiB0aGUgcHRfQlIgcmlnaHQgbm93LiBJIGhvcGUgSSBjYW4gZmlu
aXNoIHRoaXMgYXMgc29vbiBhcyBwb3NzaWJsZS48YnI+PGJyPkJlc3QsPGJyPkhlbnJpcXVlPGJy
PjwvZGl2PjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+CkdyZXRsLWRldmVsIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRv
OkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHUiPkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHU8L2E+
PGJyPgo8YSBocmVmPSJodHRwOi8vbGlzdHMud2Z1LmVkdS9tYWlsbWFuL2xpc3RpbmZvL2dyZXRs
LWRldmVsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLndmdS5lZHUvbWFpbG1hbi9saXN0
aW5mby9ncmV0bC1kZXZlbDwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K

--===============2505708560192088220==--


From cottrell@wfu.edu Sat Dec 12 11:25:12 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] restrict --silent
Date: Sat, 12 Dec 2009 11:25:10 -0500
Message-ID: <Pine.A41.4.58.0912121124340.2294182@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B2230AD.3050504@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0787255463227199021=="

--===============0787255463227199021==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Fri, 11 Dec 2009, Sven Schreiber wrote:

> Riccardo (Jack) Lucchetti schrieb:
> > On Thu, 10 Dec 2009, Sven Schreiber wrote:
> >
> >> hi,
> >>
> >> a silent option for restrict would be nice....
> >
> > Sven,
> >
> > see if the attached patch does what you want. I'm not making commits to
> > CVS till Allin's back, but in the meantime you can try it out.
> >
>
> Thanks Jack -- but I have never applied a diff that affects several
> files I think. I'm sure it's just a one-liner?

Jack's patch looks fine to me and is now applied in CVS.

Allin.

--===============0787255463227199021==--


From cottrell@wfu.edu Sat Dec 12 11:31:33 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl usage in Germany
Date: Sat, 12 Dec 2009 11:31:32 -0500
Message-ID: <Pine.A41.4.58.0912121129020.2294182@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B222F90.5070404@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8007763703338634127=="

--===============8007763703338634127==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Fri, 11 Dec 2009, Sven Schreiber wrote:

> [...] So I think gretl is definitely on the rise in the
> German-speaking region.

Thanks, Sven, this is encouraging.  I've been talking to some
Germans at the conference I'm at (in Dijon) and they seeme to know
something about gretl (have colleagues who use it, if not using it
themselves).

Allin.

--===============8007763703338634127==--


From svetosch@gmx.net Sat Dec 12 11:54:36 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl usage in Germany
Date: Sat, 12 Dec 2009 17:54:08 +0100
Message-ID: <4B23CAB0.8030808@gmx.net>
In-Reply-To: Pine.A41.4.58.0912121129020.2294182@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4008053759570259571=="

--===============4008053759570259571==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Fri, 11 Dec 2009, Sven Schreiber wrote:
> 
>> [...] So I think gretl is definitely on the rise in the
>> German-speaking region.
> 
> Thanks, Sven, this is encouraging.  I've been talking to some
> Germans at the conference I'm at (in Dijon) and they seeme to know
> something about gretl (have colleagues who use it, if not using it
> themselves).
> 

sorry to spoil the mood, but those are probably former and/or current
colleagues of mine, so that's not surprising.  :-)
Our institute in general is still Eviews-land (to some extent for good
reasons).

thanks,
sven

--===============4008053759570259571==--


From svetosch@gmx.net Sat Dec 12 12:48:09 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] crash with vecm
Date: Sat, 12 Dec 2009 18:34:32 +0100
Message-ID: <4B23D428.4080902@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8379544059626636628=="

--===============8379544059626636628==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Here's how to get a crash (with cvs version on linux from Dec 7th):

* open australia data
* do vecm with pau and pus as endo (lag order 4, rank 1), iau and ius as
exogenous, unrestricted, lags 1 to 2.
* estimate
* modify specification: set all exogenous to restricted
* estimate: -boom-

thanks,
sven

--===============8379544059626636628==--


From svetosch@gmx.net Sat Dec 12 12:48:09 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] exo vars in johansen test
Date: Sat, 12 Dec 2009 18:20:20 +0100
Message-ID: <4B23D0D4.7020009@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2742669875000929546=="

--===============2742669875000929546==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
I just noticed that while it's possible to specify exogenous variables
in the Johansen cointegration test, there are the following issues with
the output:

* the exogenous variables aren't reported
* a warning should be printed that the critical values and p-values are
in general only appropriate in the case without exogenous variables

thanks,
sven

--===============2742669875000929546==--


From ignacio.diaz-emparanza@ehu.es Mon Dec 14 04:26:40 2009
From: Ignacio Diaz-Emparanza <ignacio.diaz-emparanza@ehu.es>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 10:26:36 +0100
Message-ID: <1260782796.2156.10.camel@U001082.ehu.es>
In-Reply-To: 4B23D428.4080902@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1584124844311206977=="

--===============1584124844311206977==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

El sáb, 12-12-2009 a las 18:34 +0100, Sven Schreiber escribió:
> Here's how to get a crash (with cvs version on linux from Dec 7th):
> 
> * open australia data
> * do vecm with pau and pus as endo (lag order 4, rank 1), iau and ius as
> exogenous, unrestricted, lags 1 to 2.
> * estimate
> * modify specification: set all exogenous to restricted
> * estimate: -boom-
> 
> thanks,
> sven

I repeated your steps firstly with gretl built on december 9 (on Ubuntu
Linux 9.10) and after that with gretl built just now, and in both cases
I don't obtain a crash. The output is:

Sistema VECM, orden del retardo 4
estimaciones de Máxima Verosimilitud, observaciones 1973:1-1991:1 (T =
73)
Rango de cointegración = 1
Caso 3: constante no restringida

beta (vectores cointegrantes, Desviaciones típicas entre paréntesis)

PAU         1,0000 
           (0,0000) 
PUS        -3,0156 
          (0,51320) 
IAU_1      -2,5207 
           (9,2520) 
IAU_2       15,363 
           (8,3597) 
IUS_1       11,141 
           (7,9130) 
IUS_2      -5,1118 
           (7,3574) 

alpha (alfa (vectores de ajuste))

PAU      0,0034811 
PUS     -0,0096879 

Log-verosimilitud = -142,69443
Determinante de la matriz de covarianzas = 0,17096136
AIC = 4,4026
BIC = 4,9674
HQC = 4,6277

Ecuación 1: d_PAU

             Coeficiente   Desv. Típica   Estadístico t   Valor p
  ---------------------------------------------------------------
  const       0,723281      0,527800          1,370       0,1754 
  d_PAU_1     0,139629      0,140211          0,9958      0,3231 
  d_PAU_2     0,315540      0,146587          2,153       0,0352  **
  d_PAU_3     0,120829      0,144805          0,8344      0,4072 
  d_PUS_1     0,562600      0,245402          2,293       0,0252  **
  d_PUS_2    −0,440802      0,264517         −1,666       0,1006 
  d_PUS_3    −0,0805612     0,252506         −0,3190      0,7507 
  EC1         0,00348110    0,00590694        0,5893      0,5578 

Media de la vble. dep.  2,376712   D.T. de la vble. dep.   1,135478
Suma de cuad. residuos  66,11593   D.T. de la regresión    1,024431
R-cuadrado              0,287777   R-cuadrado corregido    0,186031
rho                    −0,018969   Durbin-Watson           1,922460

Ecuación 2: d_PUS

             Coeficiente   Desv. Típica   Estadístico t   Valor p
  ---------------------------------------------------------------
  const       0,878983      0,246449          3,567       0,0007  ***
  d_PAU_1    −0,0341883     0,0654699        −0,5222      0,6034 
  d_PAU_2     0,0967910     0,0684471         1,414       0,1623 
  d_PAU_3    −0,0153595     0,0676148        −0,2272      0,8210 
  d_PUS_1     0,228302      0,114587          1,992       0,0507  *
  d_PUS_2     0,120999      0,123513          0,9796      0,3310 
  d_PUS_3     0,426381      0,117904          3,616       0,0006  ***
  EC1        −0,00968793    0,00275817       −3,512       0,0008  ***

Media de la vble. dep.  1,178082   D.T. de la vble. dep.   0,628987
Suma de cuad. residuos  14,41529   D.T. de la regresión    0,478345
R-cuadrado              0,493933   R-cuadrado corregido    0,421637
rho                     0,042825   Durbin-Watson           1,890975

Matriz de covarianzas cruzadas entre ecuaciones:

              PAU          PUS
PAU       0,90570    -0,088806 
PUS     -0,088806      0,19747 

determinante = 0,170961



-- 
Ignacio Diaz-Emparanza  
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es 



--===============1584124844311206977==--


From svetosch@gmx.net Mon Dec 14 05:00:16 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 10:59:07 +0100
Message-ID: <4B260C6B.2020203@gmx.net>
In-Reply-To: 1260782796.2156.10.camel@U001082.ehu.es
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6321991492254559144=="

--===============6321991492254559144==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Ignacio Diaz-Emparanza schrieb:
> El sáb, 12-12-2009 a las 18:34 +0100, Sven Schreiber escribió:
>> Here's how to get a crash (with cvs version on linux from Dec 7th):
>>
>> * open australia data
>> * do vecm with pau and pus as endo (lag order 4, rank 1), iau and ius as
>> exogenous, unrestricted, lags 1 to 2.
>> * estimate
>> * modify specification: set all exogenous to restricted
>> * estimate: -boom-
>>
>> thanks,
>> sven
> 
> I repeated your steps firstly with gretl built on december 9 (on Ubuntu
> Linux 9.10) and after that with gretl built just now, and in both cases
> I don't obtain a crash. The output is:
> 

thanks for testing, Ignacio. I will update my gretl build and re-check.
Did you also do it via the GUI?

thanks,
sven


--===============6321991492254559144==--


From svetosch@gmx.net Mon Dec 14 06:14:19 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 12:13:01 +0100
Message-ID: <4B261DBD.1070604@gmx.net>
In-Reply-To: 4B260C6B.2020203@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1066705783084887396=="

--===============1066705783084887396==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Sven Schreiber schrieb:
> Ignacio Diaz-Emparanza schrieb:
>> El sáb, 12-12-2009 a las 18:34 +0100, Sven Schreiber escribió:
>>> Here's how to get a crash (with cvs version on linux from Dec 7th):
>>>
>>> * open australia data
>>> * do vecm with pau and pus as endo (lag order 4, rank 1), iau and ius as
>>> exogenous, unrestricted, lags 1 to 2.
>>> * estimate
>>> * modify specification: set all exogenous to restricted
>>> * estimate: -boom-
>>>
>>> thanks,
>>> sven
>> I repeated your steps firstly with gretl built on december 9 (on Ubuntu
>> Linux 9.10) and after that with gretl built just now, and in both cases
>> I don't obtain a crash. The output is:
>>
> 
> thanks for testing, Ignacio. I will update my gretl build and re-check.
> Did you also do it via the GUI?
> 

well strangely enough it's now even worse for me: the crash already
occurs at the first estimation stage, without modifying the spec. It
also does when running gretl in English. The console error output is
simply "segmentation fault".

I will test on Windows tomorrow.

cheers,
sven


--===============1066705783084887396==--


From svetosch@gmx.net Mon Dec 14 06:39:54 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 12:39:07 +0100
Message-ID: <4B2623DB.6090105@gmx.net>
In-Reply-To: 4B261DBD.1070604@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2740704029893049782=="

--===============2740704029893049782==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Sven Schreiber schrieb:
> Sven Schreiber schrieb:
>> Ignacio Diaz-Emparanza schrieb:
>>> El sáb, 12-12-2009 a las 18:34 +0100, Sven Schreiber escribió:
>>>> Here's how to get a crash (with cvs version on linux from Dec 7th):
>>>>
>>>> * open australia data
>>>> * do vecm with pau and pus as endo (lag order 4, rank 1), iau and ius as
>>>> exogenous, unrestricted, lags 1 to 2.
>>>> * estimate
>>>> * modify specification: set all exogenous to restricted
>>>> * estimate: -boom-
>>>>
>>>> thanks,
>>>> sven
>>> I repeated your steps firstly with gretl built on december 9 (on Ubuntu
>>> Linux 9.10) and after that with gretl built just now, and in both cases
>>> I don't obtain a crash. The output is:
>>>
>> thanks for testing, Ignacio. I will update my gretl build and re-check.
>> Did you also do it via the GUI?
>>
> 
> well strangely enough it's now even worse for me: the crash already
> occurs at the first estimation stage, without modifying the spec. It
> also does when running gretl in English. The console error output is
> simply "segmentation fault".
> 
> I will test on Windows tomorrow.
> 

ok, problem resolved, after a reboot no crash occurs anymore, so it
wasn't gretl's fault it seems. Funny though how Linux resembles Windows
more and more, now even reboots are necessary to fix problems... ;-)

thanks,
sven



--===============2740704029893049782==--


From cottrell@wfu.edu Mon Dec 14 06:42:43 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 06:42:42 -0500
Message-ID: <Pine.A41.4.58.0912140639580.2523572@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B261DBD.1070604@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8930060558732365434=="

--===============8930060558732365434==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 14 Dec 2009, Sven Schreiber wrote:

> well strangely enough it's now even worse for me: the crash already
> occurs at the first estimation stage, without modifying the spec. It
> also does when running gretl in English. The console error output is
> simply "segmentation fault".

This is specific to using the GUI lag selector for lags of the
exogenous variables in a VECM.  I've applied a fix in CVS but I
haven't had time to test much and it may need more work.

Allin



--===============8930060558732365434==--


From cottrell@wfu.edu Mon Dec 14 06:49:16 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 06:49:15 -0500
Message-ID: <Pine.A41.4.58.0912140643440.2523572@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B2623DB.6090105@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7530932002680512867=="

--===============7530932002680512867==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 14 Dec 2009, Sven Schreiber wrote:

> ok, problem resolved, after a reboot no crash occurs anymore, so it
> wasn't gretl's fault it seems. Funny though how Linux resembles Windows
> more and more, now even reboots are necessary to fix problems... ;-)

Unless you updated from CVS in the last 2 minutes, the problem
was not solved!  Sometimes you "get lucky" and a memory management
fault doesn't cause a crash.  But in fact this is unlucky from the
coder's point of view because it masks the problem.

Hint: anyone using gretl built from CVS might want to consider
building with debugging symbols on ("-g") and then running gretl
under valgrind when this sort of issue occurs.  Valgrind usually
manages to spot exactly where the error is, whether or not it
actually produces a crash.

Allin

--===============7530932002680512867==--


From svetosch@gmx.net Mon Dec 14 10:10:09 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 16:09:32 +0100
Message-ID: <4B26552C.8000009@gmx.net>
In-Reply-To: Pine.A41.4.58.0912140639580.2523572@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2890153622630584067=="

--===============2890153622630584067==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Mon, 14 Dec 2009, Sven Schreiber wrote:
> 
>> well strangely enough it's now even worse for me: the crash already
>> occurs at the first estimation stage, without modifying the spec. It
>> also does when running gretl in English. The console error output is
>> simply "segmentation fault".
> 
> This is specific to using the GUI lag selector for lags of the
> exogenous variables in a VECM.  I've applied a fix in CVS but I
> haven't had time to test much and it may need more work.
> 

ah ok, interesting that the bug was kind of erratic. So are you saying
that it will necessarily show up under valgrind if "it needs more work"?
If yes, I could try to do that. Or is the issue more subtle?

thanks,
sven

--===============2890153622630584067==--


From cottrell@wfu.edu Mon Dec 14 12:58:09 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] crash with vecm
Date: Mon, 14 Dec 2009 12:58:07 -0500
Message-ID: <Pine.A41.4.58.0912141255290.2171088@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B26552C.8000009@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3583607957096266659=="

--===============3583607957096266659==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 14 Dec 2009, Sven Schreiber wrote:

> Allin Cottrell schrieb:
> > On Mon, 14 Dec 2009, Sven Schreiber wrote:
> >
> >> well strangely enough it's now even worse for me: the crash already
> >> occurs at the first estimation stage, without modifying the spec. It
> >> also does when running gretl in English. The console error output is
> >> simply "segmentation fault".
> >
> > This is specific to using the GUI lag selector for lags of the
> > exogenous variables in a VECM.  I've applied a fix in CVS but I
> > haven't had time to test much and it may need more work.
> >
>
> ah ok, interesting that the bug was kind of erratic. So are you saying
> that it will necessarily show up under valgrind if "it needs more work"?
> If yes, I could try to do that. Or is the issue more subtle?

It's sure to show up under valgrind if it involves reading/writing
off the end of dynamically-allocated memory, which was the case
here.  But in fact, after a little more testing I think this is OK
now.

Allin.

--===============3583607957096266659==--


From gianluca@hotelchristine.it Tue Dec 15 02:45:54 2009
From: Gianluca Caporello <gianluca@hotelchristine.it>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Seats-Tramo
Date: Tue, 15 Dec 2009 08:45:42 +0100
Message-ID: <0FCA408E78DC46E3A7B66ECD8CB56FEF@IPPOGRIFO>
Content-Type: multipart/mixed; boundary="===============1057892826251121048=="

--===============1057892826251121048==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t
ODg1OS0xIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29u
dGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODg2NSI+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+CjxC
T0RZIGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1BcmlhbD5IaSBhbGws
PC9GT05UPjwvRElWPgo8RElWPjxGT05UIHNpemU9MiBmYWNlPUFyaWFsPkknbSBHaWFubHVjYSBD
YXBvcmVsbG8gdGhlIG1haW4gZGV2ZWxvcGVyIG9mIApTZWF0cy1UcmFtbywgYnkgbm93LCBhdCB0
aGUgYmFuayBvZiBTcGFpbiB3ZSBkZXZlbG9wZWQgYSBuZXcgcmVsZWFzZSBvZiBTVCB3aGljaCAK
ZXhwb3J0IGEgQysrLEphdmEgYW5kIFB5dGhvbiZuYnNwOyhhbmQgYSBwcmltaXRpdmUgUikgQVBJ
IHRvIFNUIChXaW5kb3dzIGFuZCAKTGludXgpLlRoZSBBUEkgaXMgbm90IGRvY3VtZW50ZWQgYnV0
IGl0J3MgcnVubmluZyBmcm9tIHNvbWUgeWVhcnMgb24gYSBGQU1FIAppbnRlZ3JhdGlvbiBhbmQg
d2UgaGF2ZSBhIGxvdCBvZiBydW5uaW5nIGV4YW1wbGVzLjwvRk9OVD48L0RJVj4KPERJVj48Rk9O
VCBzaXplPTIgZmFjZT1BcmlhbD5JZiBpbnRlcmVzdGVkIGZvciBhIGJldHRlciBpbnRlZ3JhdGlv
biBpbiBHUkVUTCAKZmVlbCBmcmVlIHRvIGNvbnRhY3QgbWUgb3IgZ2l2ZSBhIGxvb2sgYXQgPEEg
CmhyZWY9Imh0dHA6Ly93d3cuYmRlLmVzL3dlYmJkZS9lcy9zZWNjaW9uZXMvc2VydmljaW8vc29m
dHdhcmUvZWNvbm9tLmh0bWwiPmh0dHA6Ly93d3cuYmRlLmVzL3dlYmJkZS9lcy9zZWNjaW9uZXMv
c2VydmljaW8vc29mdHdhcmUvZWNvbm9tLmh0bWw8L0E+PC9GT05UPjwvRElWPgo8RElWPiZuYnNw
OzwvRElWPgo8RElWPjxGT05UIHNpemU9MiBmYWNlPUFyaWFsPlJlZ2FyZHM8L0ZPTlQ+PC9ESVY+
CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9QXJpYWw+R2lhbmx1Y2E8L0ZPTlQ+PC9ESVY+PC9CT0RZ
PjwvSFRNTD4K

--===============1057892826251121048==--


From svetosch@gmx.net Tue Dec 15 07:13:43 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] win snapshot file corrupted?
Date: Tue, 15 Dec 2009 13:12:48 +0100
Message-ID: <4B277D40.40507@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6577297551509113274=="

--===============6577297551509113274==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
I was trying to download the latest snapshot for win32 today but
couldn't run the file because I got an error message about a corrupted
file.  D/l-ing again didn't help. Is it my current connection or is the
file really bad?

thanks,
sven

--===============6577297551509113274==--


From cottrell@wfu.edu Tue Dec 15 07:33:43 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] win snapshot file corrupted?
Date: Tue, 15 Dec 2009 07:33:42 -0500
Message-ID: <Pine.A41.4.58.0912150732270.2728316@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B277D40.40507@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0749639023512602928=="

--===============0749639023512602928==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 15 Dec 2009, Sven Schreiber wrote:

> I was trying to download the latest snapshot for win32 today but
> couldn't run the file because I got an error message about a corrupted
> file.  D/l-ing again didn't help. Is it my current connection or is the
> file really bad?

It may have been bad for a while, as I had an interrupted upload.
But it should be OK as of now.

Allin



--===============0749639023512602928==--


From svetosch@gmx.net Tue Dec 15 07:49:42 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] win snapshot file corrupted?
Date: Tue, 15 Dec 2009 13:49:03 +0100
Message-ID: <4B2785BF.1070309@gmx.net>
In-Reply-To: Pine.A41.4.58.0912150732270.2728316@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9161270859022493474=="

--===============9161270859022493474==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Tue, 15 Dec 2009, Sven Schreiber wrote:
> 
>> I was trying to download the latest snapshot for win32 today but
>> couldn't run the file because I got an error message about a corrupted
>> file.  D/l-ing again didn't help. Is it my current connection or is the
>> file really bad?
> 
> It may have been bad for a while, as I had an interrupted upload.
> But it should be OK as of now.
> 

yes it looks much better now

thanks,
sven

--===============9161270859022493474==--


From svetosch@gmx.net Thu Dec 17 07:49:34 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] bug/requests collection
Date: Thu, 17 Dec 2009 13:48:57 +0100
Message-ID: <4B2A28B9.2010604@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8745849764494443039=="

--===============8745849764494443039==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

the list has been busy recently with bug reports (and also some feature
requests), and it's absolutely understandable that not all bugs could be
fixed right away. (It still continues to amaze me that a sizeable
proportion of bug reports are addressed immediately by Allin.) So here's
a list of what may still be open issues. After clarification and
discussion I will transfer the remainder of this list into the bug
tracker and feature requests databases.

thanks,
sven

--------

* icon for "code view" in the function package list window: change from
cogwheel to something more intuitive

* icon of function package list window (and others) in taskbar is only
generic (non-gretl) on linux (self-compiled cvs) -- actually, i don't
get any icons for menu items on linux (as opposed to windows), I suppose
that's a bug of my setup?

* the help about invcdf() says P(X<x), but shouldn't it be P(X<=x)?

* the command 'include myfilenamewith.dots' fails even if
'myfilenamewith.dots.inp' exists (and is in the right place/dir),
apparently because gretl interprets .dots as a filename extension

* variable is being treated as discrete should be made optional rather
than automatic (I thought it was already the case after a discussion
some months/years ago)

* function namespace bug; see
http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html

* Estimating one equation with 7 variables and 3 lags with OLS produces
a glitch with one of the variable names: Instead of 'Yield_10yr_1' the
name 'd_Yield_10yr' is printed. (Maybe it has to do with the
underscores in the name?)

* The command 'rmplot' is defined only for the GUI. I (=Ignacio) think
it would be very good if we could use it also in scripts.

* script accessors ($test etc.) for bootstrapped test results

* the exogenous variables in a Johansen test setting aren't reported;
and a warning should be printed that the critical values and p-values
are in general only appropriate in the case without exogenous variables

--===============8745849764494443039==--


From cottrell@wfu.edu Thu Dec 17 11:14:35 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with variable label in estimation table
Date: Thu, 17 Dec 2009 11:14:34 -0500
Message-ID: <Pine.A41.4.58.0912171113030.172206@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B1E7C58.4060402@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8231920709590977075=="

--===============8231920709590977075==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 8 Dec 2009, Sven Schreiber wrote:

> Estimating one equation of an underlying VAR with 7 variables and 3 lags
> by hand with OLS (don't ask why right now) produces a glitch with one of
> the variable names: Instead of 'Yield_10yr_1' the name 'd_Yield_10yr' is
> printed. Strangely, 'Yield_10yr_2' and so forth print ok. The other
> variable names print 100% ok. Fortunately, I verified that it's only the
> label and not a different variable, i.e. the first lag of Yield_10yr is
> used alright, not the difference as it looks at first.

I'll need a test case to see what is going on here.  I haven't
been able to replicate the problem.  You could take a supplied
dataset and rename the variables as in your own data, perhaps.

Allin.

--===============8231920709590977075==--


From cottrell@wfu.edu Thu Dec 17 11:29:37 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug/requests collection
Date: Thu, 17 Dec 2009 11:29:36 -0500
Message-ID: <Pine.A41.4.58.0912171117470.172206@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B2A28B9.2010604@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3015047840704462700=="

--===============3015047840704462700==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Thu, 17 Dec 2009, Sven Schreiber wrote:

> the list has been busy recently with bug reports (and also some feature
> requests), and it's absolutely understandable that not all bugs could be
> fixed right away. (It still continues to amaze me that a sizeable
> proportion of bug reports are addressed immediately by Allin.) So here's
> a list of what may still be open issues. After clarification and
> discussion I will transfer the remainder of this list into the bug
> tracker and feature requests databases.

Thanks for keeping track of these things.  Here are some brief
responses.

> * icon for "code view" in the function package list window: change from
> cogwheel to something more intuitive

"View code" is mapped to GTK_STOCK_PROPERTIES and "Execute" is
mapped to GTK_STOCK_EXECUTE.  These make sense to me.  If the
icons you're seeing don't convery the expected sense, file a bug
report for the GTK theme you're using.  (Here, using the base GTK
icons, I get a cogwheel for Execute and what looks like a spanner
for View code.)

> * icon of function package list window (and others) in taskbar is only
> generic (non-gretl) on linux (self-compiled cvs) -- actually, i don't
> get any icons for menu items on linux (as opposed to windows), I suppose
> that's a bug of my setup?

The installed GTK theme must be specifying no icons in menus.
Nothing gretl can do about that.

> * the help about invcdf() says P(X<x), but shouldn't it be P(X<=x)?

Yes, I suppose it should (for the sake of discrete distributions).

> * the command 'include myfilenamewith.dots' fails even if
> 'myfilenamewith.dots.inp' exists (and is in the right place/dir),
> apparently because gretl interprets .dots as a filename extension

Yes.  Won't fix.  Either don't put dots into filenames, or give
the full name with ".inp" extension.

> * variable is being treated as discrete should be made optional rather
> than automatic (I thought it was already the case after a discussion
> some months/years ago)

I'll try to get to that.

> * function namespace bug; see
> http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html

And that one is on my agenda too.

> * Estimating one equation with 7 variables and 3 lags with OLS produces
> a glitch with one of the variable names: Instead of 'Yield_10yr_1' the
> name 'd_Yield_10yr' is printed. (Maybe it has to do with the
> underscores in the name?)

Can't do anything without a case in point.

> * The command 'rmplot' is defined only for the GUI. I (=Ignacio) think
> it would be very good if we could use it also in scripts.
>
> * script accessors ($test etc.) for bootstrapped test results

Both of the above are on the agenda.

> * the exogenous variables in a Johansen test setting aren't reported;
> and a warning should be printed that the critical values and p-values
> are in general only appropriate in the case without exogenous variables

That too.

Allin.

--===============3015047840704462700==--


From svetosch@gmx.net Fri Dec 18 05:42:16 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug/requests collection
Date: Fri, 18 Dec 2009 11:41:32 +0100
Message-ID: <4B2B5C5C.6090009@gmx.net>
In-Reply-To: Pine.A41.4.58.0912171117470.172206@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7530175045745315523=="

--===============7530175045745315523==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Thu, 17 Dec 2009, Sven Schreiber wrote:
> 

> 
>> * icon for "code view" in the function package list window: change from
>> cogwheel to something more intuitive
> 
> "View code" is mapped to GTK_STOCK_PROPERTIES and "Execute" is
> mapped to GTK_STOCK_EXECUTE.  These make sense to me.  If the
> icons you're seeing don't convery the expected sense, file a bug
> report for the GTK theme you're using.  (Here, using the base GTK
> icons, I get a cogwheel for Execute and what looks like a spanner
> for View code.)

agreed

> 
>> * icon of function package list window (and others) in taskbar is only
>> generic (non-gretl) on linux (self-compiled cvs) -- actually, i don't
>> get any icons for menu items on linux (as opposed to windows), I suppose
>> that's a bug of my setup?
> 
> The installed GTK theme must be specifying no icons in menus.
> Nothing gretl can do about that.

of course

> 
>> * the help about invcdf() says P(X<x), but shouldn't it be P(X<=x)?
> 
> Yes, I suppose it should (for the sake of discrete distributions).

yes; I will try to correct that together with the other doc change
regarding ox compilation that's still on my to-do-list (since I normally
don't mess with gretl's cvs files apart from de.po I want to do it
properly when I'm not in a rush)

> 
>> * the command 'include myfilenamewith.dots' fails even if
>> 'myfilenamewith.dots.inp' exists (and is in the right place/dir),
>> apparently because gretl interprets .dots as a filename extension
> 
> Yes.  Won't fix.  Either don't put dots into filenames, or give
> the full name with ".inp" extension.

fair enough

> 
>> * variable is being treated as discrete should be made optional rather
>> than automatic (I thought it was already the case after a discussion
>> some months/years ago)
> 
> I'll try to get to that.

I will enter it in the feature request tracker

> 
>> * function namespace bug; see
>> http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html
> 
> And that one is on my agenda too.
> 

will enter into bug tracker

>> * Estimating one equation with 7 variables and 3 lags with OLS produces
>> a glitch with one of the variable names: Instead of 'Yield_10yr_1' the
>> name 'd_Yield_10yr' is printed. (Maybe it has to do with the
>> underscores in the name?)
> 
> Can't do anything without a case in point.
> 

sure, will try to provide a minimal example (haven't succeeded so far,
but haven't followed up on the underscore hunch either)

>> * The command 'rmplot' is defined only for the GUI. I (=Ignacio) think
>> it would be very good if we could use it also in scripts.
>>
>> * script accessors ($test etc.) for bootstrapped test results
> 
> Both of the above are on the agenda.

will enter into feature request tracker

> 
>> * the exogenous variables in a Johansen test setting aren't reported;
>> and a warning should be printed that the critical values and p-values
>> are in general only appropriate in the case without exogenous variables
> 
> That too.

will enter into bug tracker

Thanks!

Sven

--===============7530175045745315523==--


From cottrell@wfu.edu Fri Dec 18 06:25:22 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug/requests collection
Date: Fri, 18 Dec 2009 06:25:21 -0500
Message-ID: <Pine.A41.4.58.0912180624220.2564410@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B2B5C5C.6090009@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8854023835733561903=="

--===============8854023835733561903==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Fri, 18 Dec 2009, Sven Schreiber wrote:

> >> * function namespace bug; see
> >> http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html
> >
> > And that one is on my agenda too.
> >
>
> will enter into bug tracker

I think that one should now be fixed in CVS.

Thanks for the processing the others.

Allin.

--===============8854023835733561903==--


From svetosch@gmx.net Fri Dec 18 09:42:53 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug/requests collection
Date: Fri, 18 Dec 2009 15:42:00 +0100
Message-ID: <4B2B94B8.5030703@gmx.net>
In-Reply-To: Pine.A41.4.58.0912180624220.2564410@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3722115083173506176=="

--===============3722115083173506176==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Fri, 18 Dec 2009, Sven Schreiber wrote:
> 
>>>> * function namespace bug; see
>>>> http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002286.html
>>> And that one is on my agenda too.
>>>
>> will enter into bug tracker
> 
> I think that one should now be fixed in CVS.
> 

confirmed!

> Thanks for the processing the others.
> 

done.

cheers,
sven

--===============3722115083173506176==--


From svetosch@gmx.net Tue Dec 22 09:51:36 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] simulation speed
Date: Tue, 22 Dec 2009 15:50:50 +0100
Message-ID: <4B30DCCA.4000409@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4197687420854711430=="

--===============4197687420854711430==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
yet another useless benchmarking exercise: I was playing around a little
comparing the speed of various matrix languages with respect to doing
stochastic simulations. The codes below draw repeated random samples,
compute their means, and find the 95% percent quantile of the empirical
distribution of the means. I distinguish between a "naive" loop
programming variant and one working only with matrix functions. Here are
the results on Ubuntu Linux 9.10 (I ran the scripts/programs several
times and they are pretty robust):

Octave 3.0.5:
loop ca. 3.3 seconds
vectorized ca. 0.8 seconds

Python 2.6.4/Numpy 1.3.0/matplotlib 0.99(?):
loop ca. 2.1 seconds
vectorized ca. 1.5 seconds

gretl 1.8.6cvs:
loop ca. 2.6 seconds
vectorized ca. 2.0 seconds

Ox 5.1:
loop ca. 1.1 seconds
vectorized ca. 0.7 seconds

Ox confirms its reputation about speed, but for me it was surprising
that Octave is almost as fast with the vectorized code. (But Octave has
the slowest loops.) Gretl seems to have the smallest relative gain going
from loops to vectorized code. But considering that gretl is quite new
in the field of matrix programming I think it is doing fine.

cheers,
sven


<Octave-code>
length = 1000;
iterations = 10000;
whichp = 0.95;

tic;

# looping variant
averages = [];
for i=1:iterations;
	mrandom = randn(length,1);
	averages = [averages ; mean(mrandom)];
endfor;
myquant = quantile(averages,whichp);

toc;
printf ("Result: %f\n", myquant);

tic;

# vectorized variant
mrandom2 = randn(length,iterations);
averages2 = mean(mrandom2); # row vector
myquant2 = quantile(averages2',whichp);

toc;

printf ("Result: %f\n", myquant2);
</Octave-code>

<Python-code>
from numpy import matlib as nm
from matplotlib import mlab as ml
import time

length = 1000
iterations = 10000
whichp = 0.95

starttime = time.time()

# looping variant
averages = nm.empty((0,1))
for i in range(iterations):
	mrandom = nm.randn(length,1)
	averages = nm.vstack((averages, nm.mean(mrandom)))
myquant = ml.prctile(averages,whichp*100)	# per cents
endtime1 = time.time()
print "Result: " + str(myquant)
print "Execution time loop variant, length " + str(length) + ",
iterations " + str(iterations) + ": " + str(endtime1-starttime)

# vectorized variant
starttime2 = time.time()
mrandom2 = nm.randn(length,iterations)
averages2 = nm.mean(mrandom2, axis=0)
myquant2 = ml.prctile(averages2,whichp*100)
endtime2 = time.time()
print "Result: " + str(myquant2)
print "Execution time vectorized variant, length " + str(length) + ",
iterations " + str(iterations) + ": " + str(endtime2-starttime2)
</Python-code>

<gretl-code>
length = 1000
iterations = 10000
whichp = 0.95
set echo off
set messages off
set stopwatch

# looping variant (non-vectorized)
matrix averages = {}	# will be col vector
loop iterations
    matrix mrandom = mnormal(length,1)
    matrix averages = averages | meanc(mrandom)
end loop
matrix myquant = quantile(averages, whichp)
time = $stopwatch
printf "Result: %f\n", myquant
printf "Execution time loop variant, length %d, iterations %d: %f\n",
length, iterations, time

time = $stopwatch	# don't count printing overhead
# vectorized variant
matrix mrandom2 = mnormal(length,iterations)
matrix averages2 = transp(meanc(mrandom2))
matrix myquant2 = quantile(averages2, whichp)
time = $stopwatch
printf "Result: %f\n", myquant2
printf "Execution time vectorized variant, length %d, iterations %d:
%f\n", length, iterations, time
</gretl-code>


</Ox-code>
#include <oxstd.h>
const decl length = 1000;
const decl iterations = 10000;
const decl whichp = 0.95;

main(){
decl averages, averages2;
decl myquant, myquant2;
decl mrandom, mrandom2;
decl starttime, endtime;
decl i;

starttime = timer();

// looping variant
averages = <>;
for (i=0; i<iterations; ++i)
{	mrandom = rann(length,1);
	averages = averages | meanc(mrandom);
}
myquant = quantilec(averages,whichp);

endtime = timer();
print("Result: ", myquant, "\n");
print("elapsed time: ", timespan(starttime,endtime));

starttime = timer();

// vectorized variant
mrandom2 = rann(length,iterations);
averages2 = meanc(mrandom2); // row vector
myquant2 = quantiler(averages2,whichp);

endtime = timer();
print("\nResult: ", myquant2,"\n");
print("elapsed time: ", timespan(starttime,endtime),"\n");

}
</Ox-code>

--===============4197687420854711430==--


From bhh@xs4all.nl Tue Dec 22 11:10:46 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Tue, 22 Dec 2009 17:10:43 +0100
Message-ID: <73F614CB-4BB6-4A31-A35D-1E084BA55819@xs4all.nl>
In-Reply-To: 4B30DCCA.4000409@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2534254699426509590=="

--===============2534254699426509590==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On 22-12-2009, at 15:50, Sven Schreiber wrote:

> Hi,
> yet another useless benchmarking exercise: I was playing around a little
> comparing the speed of various matrix languages with respect to doing
> stochastic simulations. The codes below draw repeated random samples,
> compute their means, and find the 95% percent quantile of the empirical
> distribution of the means. I distinguish between a "naive" loop
> programming variant and one working only with matrix functions. Here are
> the results on Ubuntu Linux 9.10 (I ran the scripts/programs several
> times and they are pretty robust):

I ran the test on my iMac for Octave, Gretl 1.8.6 and R 2.10.1
I used your Octave and gretl code. My R code is after the results.
Interestingly enough there isn't a lot of difference between the loop code and the vectorized code in this case.

Berend

Results:
================================================
Mac OS X 10.6.2  iMac late 2006 Intel Core 2 Duo 2.16Ghz 3Gb memory

Length=1000
Iterations=10000

            Version     Loop        Vectorized

Octave      3.23        3.08        0.59
Gretlcli    1.8.6.cvs   2.79        1.62


R version 2.10.1 Patched (2009-12-17 r50777)

Terminal version
------------------  
              Loop                        Vectorized
              user  system elapsed        user  system elapsed
R 32-bit      1.669  0.054   1.729        1.616  0.213   1.829
R 64-bit      1.668  0.051   1.720        1.616  0.217   1.832


R.app GUI 
------------------
              Loop                        Vectorized
              user  system elapsed        user  system elapsed
R 32-bit      2.115  0.039   2.138        1.948  0.219   2.151
R 64-bit      1.696  0.029   1.713        1.628  0.004   1.620      

<R-code>
nlen <- 1000
iterations <- 10000
averages <- numeric(iterations)
whichp <- 0.95
                           
system.time( {
    for(k in 1:iterations) { v <- rnorm(nlen); averages[k] <- mean(v) }
    result <- quantile(averages,probs=c(whichp))
})
                               
print(result) 

system.time({
    averages2 <- colMeans(matrix(data=rnorm(nlen*iterations), nrow=nlen, ncol=iterations))
    result2 <- quantile(averages2,probs=c(whichp))
})

print(result2)
</R-code>

--===============2534254699426509590==--


From r.lucchetti@univpm.it Tue Dec 22 16:24:29 2009
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Tue, 22 Dec 2009 22:24:25 +0100
Message-ID: <alpine.DEB.2.00.0912222210590.13986@ec-4.econ.univpm.it>
In-Reply-To: 73F614CB-4BB6-4A31-A35D-1E084BA55819@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1116411347709735921=="

--===============1116411347709735921==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 22 Dec 2009, Berend Hasselman wrote:

>
> On 22-12-2009, at 15:50, Sven Schreiber wrote:
>
>> Hi,
>> yet another useless benchmarking exercise: ...

Not useless at all, in fact it's extremely interesting. Thanks, Sven.

I have the feeling (and valgrind+callgrind seems to give supporting 
evidence) that gretl spends most of its time generating random numbers. 
The actual matrix operations take very little in comparison. Allin and I 
have been aware that random number generation still has margins for 
optimisation, only we haven't had time to pursue the matter.

By the way, the algorithm we use for generating normals is polar 
Box-Müller (and before you all jump on me on this one: yes, I am aware of 
all the criticism on Box-Müller, but the fact that we are using the 
Mersenne Twister for uniforms instead of a plain congruential generator 
makes the point sort of moot). We may want to switch to Marsaglia's 
ziggurat method, which is said to be very fast and accurate. I don't know 
first-hand, as I never implemented it myself, but there seems to be a 
certain degree on unanimity on this by experts (beside, it was invented by 
George Marsaglia, who is the highest authority on RNG in this solar 
system).

Sven, could you try to tune your script to compute the timings of random 
number generation and matrix operations separately?

Oh, and one last thing: I'll be on holiday from tomorrow, so don't expect 
me to do anything on this or other stuff soon. That said, happy Christmas 
to everyone!


Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti

--===============1116411347709735921==--


From svetosch@gmx.net Tue Dec 22 17:31:18 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Tue, 22 Dec 2009 23:30:41 +0100
Message-ID: <4B314891.4010804@gmx.net>
In-Reply-To: 4B30DCCA.4000409@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8402100992920946052=="

--===============8402100992920946052==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sven Schreiber schrieb:

> 
> Octave 3.0.5:
> loop ca. 3.3 seconds
> vectorized ca. 0.8 seconds
> 
> Python 2.6.4/Numpy 1.3.0/matplotlib 0.99(?):
> loop ca. 2.1 seconds
> vectorized ca. 1.5 seconds
> 
> gretl 1.8.6cvs:
> loop ca. 2.6 seconds
> vectorized ca. 2.0 seconds
> 
> Ox 5.1:
> loop ca. 1.1 seconds
> vectorized ca. 0.7 seconds
> 


Actually Berend's separate treatment of R-terminal and R-GUI made me run
gretl's code in gretlcli as well, as it was the only application that
was using a GUI interface.

The new result:
gretlcli 1.8.6cvs:
loop ca. 2.6 seconds
vectorized ca. 1.8 seconds

So the vectorized code gains 10% while the loop variant stays the same.
The results from Berend (1.6 seconds) and me (1.8 seconds) also seem to
be compatible in terms of nominal CPU speed, where he has a Core2Duo
2.16GHz and mine is a Core2Duo 1.83GHz I think.

cheers,
sven

--===============8402100992920946052==--


From talhayalta@gmail.com Wed Dec 23 01:48:55 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 08:48:52 +0200
Message-ID: <5b1988aa0912222248h3cf31b64u4b173a4acb0b0e6e@mail.gmail.com>
In-Reply-To: alpine.DEB.2.00.0912222210590.13986@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2505464125937756708=="

--===============2505464125937756708==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

> ...  (beside, it was invented by George Marsaglia, who is the
> highest authority on RNG in this solar system).
Ever heard of Pierre L'Ecuyer? ;-)
http://www.iro.umontreal.ca/~lecuyer/
http://www.iro.umontreal.ca/~lecuyer/cva.pdf


-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============2505464125937756708==--


From cottrell@wfu.edu Wed Dec 23 09:44:26 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 09:44:24 -0500
Message-ID: <Pine.A41.4.58.0912230937150.254352@f1n11.sp2net.wfu.edu>
In-Reply-To: alpine.DEB.2.00.0912222210590.13986@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5532476979479560487=="

--===============5532476979479560487==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 22 Dec 2009, Riccardo (Jack) Lucchetti wrote:

> On Tue, 22 Dec 2009, Berend Hasselman wrote:
>
> >
> > On 22-12-2009, at 15:50, Sven Schreiber wrote:
> >
> >> Hi,
> >> yet another useless benchmarking exercise: ...
>
> Not useless at all, in fact it's extremely interesting. Thanks, Sven.
>
> I have the feeling (and valgrind+callgrind seems to give supporting
> evidence) that gretl spends most of its time generating random numbers.

Yes, Jack is right on this.  I have "borrowed" the code Jochen
Voss wrote for gsl to implement the ziggurat method for generating
random normal values.  Here's what I'm seeing after making this
change:

          loop    vectorized
octave    2.59          0.53
gretl     0.87          0.39
ox        0.85          0.56

I've also downloaded the L'Ecuyer/Simard test suite, TestU01, and
once I've figured out how to use it I'll check that this method is
producing good values.

Allin.

--===============5532476979479560487==--


From talhayalta@gmail.com Wed Dec 23 09:58:06 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 16:58:03 +0200
Message-ID: <5b1988aa0912230658n486caebbj2279556dcf8418e7@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.0912230937150.254352@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6949824543984586564=="

--===============6949824543984586564==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

> ...I have "borrowed" the code Jochen
> Voss wrote for gsl to implement the ziggurat method for generating
> random normal values.  Here's what I'm seeing after making this
> change:
>
>          loop    vectorized
> octave    2.59          0.53
> gretl     0.87          0.39
> ox        0.85          0.56
Wow!

-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============6949824543984586564==--


From svetosch@gmx.net Wed Dec 23 10:16:49 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 16:16:10 +0100
Message-ID: <4B32343A.9070408@gmx.net>
In-Reply-To: 5b1988aa0912230658n486caebbj2279556dcf8418e7@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1936411905167418286=="

--===============1936411905167418286==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Talha Yalta schrieb:
>> ...I have "borrowed" the code Jochen
>> Voss wrote for gsl to implement the ziggurat method for generating
>> random normal values.  Here's what I'm seeing after making this
>> change:
>>
>>          loop    vectorized
>> octave    2.59          0.53
>> gretl     0.87          0.39
>> ox        0.85          0.56
> Wow!
> 

Yes I was gonna say that as well!

-- With respect to gsl I'm wondering what's the best approach: borrowing
the code or requiring gsl to build gretl. I believe you (Allin) said at
some point you didn't want to have the gsl dependency...

thanks,
sven

--===============1936411905167418286==--


From cottrell@wfu.edu Wed Dec 23 11:13:56 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 11:13:55 -0500
Message-ID: <Pine.A41.4.58.0912231101390.1974716@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B32343A.9070408@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4866634153911572370=="

--===============4866634153911572370==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Wed, 23 Dec 2009, Sven Schreiber wrote:

> Talha Yalta schrieb:
> >> ...I have "borrowed" the code Jochen
> >> Voss wrote for gsl to implement the ziggurat method for generating
> >> random normal values.  Here's what I'm seeing after making this
> >> change:
> >>
> >>          loop    vectorized
> >> octave    2.59          0.53
> >> gretl     0.87          0.39
> >> ox        0.85          0.56
> > Wow!
> >
>
> Yes I was gonna say that as well!

There is a possible catch: Doornik has an article (google: doornik
ziggurat) arguing that the standard ziggurat method fails a test
for high-dimensional randomness (and that one might expect it to
fail), and he has a workaround which necessarily sacrifices some
of the efficiency of ziggurat. (Unfortunately his code is free
only for non-commercial use so it's incompatible with the GPL and
we can't use it in gretl.)

So far as I can tell Doornik's article hasn't been published and I
can't find any response from Marsaglia, but I'm taking this
seriously.  Right now I'm running the L'Ecuyer "crush" test on the
new gretl code -- should be finished within an hour or two!

> -- With respect to gsl I'm wondering what's the best approach:
> borrowing the code or requiring gsl to build gretl. I believe
> you (Allin) said at some point you didn't want to have the gsl
> dependency...

It's possible we may want to link to libgsl at some point, but
this particular instance wouldn't warrant that: Voss's code is
just a few dozen lines, with no integral dependence on the rest of
gsl.  And the Voss code is under the GPL so borrowing is not a
problem.

Allin.

--===============4866634153911572370==--


From bhh@xs4all.nl Wed Dec 23 14:34:43 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Wed, 23 Dec 2009 20:34:39 +0100
Message-ID: <E2BF82D7-55BE-4F84-97EA-56481C90EB07@xs4all.nl>
In-Reply-To: Pine.A41.4.58.0912231101390.1974716@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3488810757928487052=="

--===============3488810757928487052==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


I did some more tests with R. I have only tested R.app 32 bit.

R has several methods for generating random numbers from a  normal distribution.
Caveat: I have no idea what the different methods actually do.
The Ahrens-Dieter method appears to be the  fastest.

Results:

         RNGmethod     ctype  user system elapsed

1        Inversion      loop 1.676  0.013   1.713
2        Inversion iteration 1.626  0.213   1.842
3 Kinderman-Ramage      loop 1.101   0.05   1.155
4 Kinderman-Ramage iteration 1.012  0.002   1.013
5       Box-Muller      loop 1.509  0.021   1.532
6       Box-Muller iteration 1.419  0.007   1.428
7    Ahrens-Dieter      loop  1.08  0.035   1.115
8    Ahrens-Dieter iteration 0.992  0.001   0.995

Berend

<R-code>
resdata <- data.frame(RNGmethod="",ctype="", user=0, system=0, elapsed=0,stringsAsFactors=FALSE,row.names=NULL)

nlen <- 1000
iterations <- 10000
averages <- numeric(iterations)
whichp <- 0.95

Rmethod="Inversion"
RNGkind(normal.kind=Rmethod)                            

t <- system.time( {
    for(k in 1:iterations) { v <- rnorm(nlen); averages[k] <- mean(v) }
    result <- quantile(averages,probs=c(whichp))
})
                           
resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="loop", user=t[1],system=t[2],elapsed=t[3]))

t <- system.time({
    averages2 <- colMeans(matrix(data=rnorm(nlen*iterations), nrow=nlen, ncol=iterations))
    result2 <- quantile(averages2,probs=c(whichp))
})

resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="iteration", user=t[1],system=t[2],elapsed=t[3]))

Rmethod="Kinderman-Ramage"
RNGkind(normal.kind=Rmethod)                            

t <- system.time( {
    for(k in 1:iterations) { v <- rnorm(nlen); averages[k] <- mean(v) }
    result <- quantile(averages,probs=c(whichp))
})
                           
resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="loop", user=t[1],system=t[2],elapsed=t[3]))

t <- system.time({
    averages2 <- colMeans(matrix(data=rnorm(nlen*iterations), nrow=nlen, ncol=iterations))
    result2 <- quantile(averages2,probs=c(whichp))
})

resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="iteration", user=t[1],system=t[2],elapsed=t[3]))

Rmethod="Box-Muller"
RNGkind(normal.kind=Rmethod)                            

t <- system.time( {
    for(k in 1:iterations) { v <- rnorm(nlen); averages[k] <- mean(v) }
    result <- quantile(averages,probs=c(whichp))
})
                           
resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="loop", user=t[1],system=t[2],elapsed=t[3]))

t <- system.time({
    averages2 <- colMeans(matrix(data=rnorm(nlen*iterations), nrow=nlen, ncol=iterations))
    result2 <- quantile(averages2,probs=c(whichp))
})

resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="iteration", user=t[1],system=t[2],elapsed=t[3]))

Rmethod="Ahrens-Dieter"
RNGkind(normal.kind=Rmethod)                            

t <- system.time( {
    for(k in 1:iterations) { v <- rnorm(nlen); averages[k] <- mean(v) }
    result <- quantile(averages,probs=c(whichp))
})
                           
resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="loop", user=t[1],system=t[2],elapsed=t[3]))

t <- system.time({
    averages2 <- colMeans(matrix(data=rnorm(nlen*iterations), nrow=nlen, ncol=iterations))
    result2 <- quantile(averages2,probs=c(whichp))
})

resdata <- rbind(resdata, c(RNGmethod=Rmethod, ctype="iteration", user=t[1],system=t[2],elapsed=t[3]))

# delete dummy first row
resdata <- resdata[2:nrow(resdata),]
row.names(resdata) <- NULL

print(resdata, digits=4)                              
</R-code>

--===============3488810757928487052==--


From bhh@xs4all.nl Thu Dec 24 03:59:11 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 09:59:07 +0100
Message-ID: <330B39FF-7AD2-4C78-ABA7-38BD82E8A3D3@xs4all.nl>
In-Reply-To: E2BF82D7-55BE-4F84-97EA-56481C90EB07@xs4all.nl
Content-Type: multipart/mixed; boundary="===============5576747859010351982=="

--===============5576747859010351982==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3
JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNp
emU6IDE0cHg7Ij48YnI+PC9zcGFuPjwvZm9udD48ZGl2PjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxl
LXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJB
cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+T24gMjMtMTItMjAwOSwg
YXQgMjA6MzQsIEJlcmVuZCBIYXNzZWxtYW4gd3JvdGU6PC9zcGFuPjwvZm9udD48L2Rpdj48Zm9u
dCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+
PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij48
YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjwvc3Bhbj48L2ZvbnQ+PGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFj
ZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i
IHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij48YnI+SSBkaWQgc29tZSBtb3JlIHRlc3RzIHdpdGgg
Ui4gSSBoYXZlIG9ubHkgdGVzdGVkIFIuYXBwIDMyIGJpdC48YnI+PC9zcGFuPjwvZm9udD48L2Rp
dj48L2Jsb2NrcXVvdGU+PC9kaXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9
IidDb3VyaWVyIE5ldyciIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz
dHlsZT0iZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvc3Bhbj48L2ZvbnQ+PGRpdj48Zm9udCBjbGFz
cz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4g
Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5UaGUgUiBz
Y3JpcHQgb2YgbXkgcHJldmlvdXMgcG9zdCB3YXMgbXVjaCB0b28gbG9uZyBhbmQgaGFkIGEgbWlz
dGFrZSBpbiBhZGRpbmcgYSByb3cgdG8gdGhlIGRhdGEuZnJhbWUgKG1peGluZyBjaGFyYWN0ZXIg
YW5kIG51bWVyaWMgZGF0YSBpbiBhIHZlY3RvcikuIEkgaGF2ZSBhbHNvIGFkZGVkIHRoZSBxdWFu
dGlsZSB2YWx1ZSB0byB0aGUgdGFibGUgdG8gY2hlY2sgKGNvbHVtbiByZXN1bHQpLjwvc3Bhbj48
L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0Nv
dXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl
PSJmb250LXNpemU6IDE0cHg7Ij48YnI+PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGNs
YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48c3Bh
biBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPlRoZSBy
ZXN1bHQgZm9yIHRoZSBjb3JyZWN0ZWQgc2NyaXB0IGlzIChzdGlsbCB1c2luZyBSLmFwcCAzMi1i
aXQpPC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu
IiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUt
c3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxicj48L3NwYW4+PC9mb250PjwvZGl2Pjxk
aXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3
JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNp
emU6IDE0cHg7Ij4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUk5HbWV0aG9kICZu
YnNwOyAmbmJzcDsgY3R5cGUgJm5ic3A7ICZuYnNwOyByZXN1bHQgJm5ic3A7dXNlciBzeXN0ZW0g
ZWxhcHNlZDwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUt
c3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0
eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4xICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO0ludmVyc2lvbiAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvb3AgMC4wNTE4MDA2OCAxLjY4
MSAmbmJzcDswLjAwNiAmbmJzcDsgMS42ODc8L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQg
Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciIHNpemU9IjQiPjxz
cGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+MiAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbnZlcnNpb24gaXRlcmF0aW9uIDAuMDUyMTE0NjIg
MS42NDggJm5ic3A7MC4yMDYgJm5ic3A7IDEuODUzPC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxm
b250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0
Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsi
PjMgS2luZGVybWFuLVJhbWFnZSAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvb3AgMC4wNTIyODE3OSAx
LjEwNSAmbmJzcDswLjA2MSAmbmJzcDsgMS4xNjY8L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PGZv
bnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciIHNpemU9IjQi
PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+
NCBLaW5kZXJtYW4tUmFtYWdlIGl0ZXJhdGlvbiAwLjA1MTc2NjgxIDEuMDI3ICZuYnNwOzAuMDAx
ICZuYnNwOyAxLjAyODwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUt
c3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFw
cGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij41ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IEJveC1NdWxsZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb29wIDAuMDUyMjQ5ODQgMS41
MTMgJm5ic3A7MC4wMTggJm5ic3A7IDEuNTMxPC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250
IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48
c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjYg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQm94LU11bGxlciBpdGVyYXRpb24gMC4wNTIwODY0MiAxLjQx
NyAmbmJzcDswLjAwNSAmbmJzcDsgMS40MjM8L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQg
Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciIHNpemU9IjQiPjxz
cGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+NyAm
bmJzcDsgJm5ic3A7QWhyZW5zLURpZXRlciAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvb3AgMC4wNTIz
Nzk0OCAxLjA3NiAmbmJzcDswLjAyMSAmbmJzcDsgMS4wOTc8L3NwYW4+PC9mb250PjwvZGl2Pjxk
aXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IidDb3VyaWVyIE5ldyciIHNp
emU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAx
NHB4OyI+OCAmbmJzcDsgJm5ic3A7QWhyZW5zLURpZXRlciBpdGVyYXRpb24gMC4wNTE5MjE4NCAw
Ljk5MyAmbmJzcDswLjAwMCAmbmJzcDsgMC45OTM8L3NwYW4+PC9mb250PjwvZGl2Pjxmb250IGNs
YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48c3Bh
biBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxkaXY+
PGJyPjwvZGl2PlRoZSBBaHJlbnMtRGlldGVyIG1ldGhvZCBpcyBzdGlsbCB0aGUgcXVpY2tlc3Qu
PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBm
YWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3Bh
biIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut
bmV3bGluZSI+QmVyZW5kPC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGNsYXNzPSJBcHBs
ZS1zdHlsZS1zcGFuIiBmYWNlPSInQ291cmllciBOZXcnIiBzaXplPSI0Ij48c3BhbiBjbGFzcz0i
QXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxicj48L3NwYW4+PC9m
b250PjwvZGl2PjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IidDb3Vy
aWVyIE5ldyciIHNpemU9IjQiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0i
Zm9udC1zaXplOiAxNHB4OyI+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFz
cz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4g
Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4mbHQ7Ui1j
b2RlJmd0Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUt
c3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0
eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij5yZXNkYXRhICZsdDstIGRhdGEuZnJh
bWUoUk5HbWV0aG9kPSIiLGN0eXBlPSIiLCByZXN1bHQ9MCwgdXNlcj0wLCBzeXN0ZW09MCwgZWxh
cHNlZD0wLHN0cmluZ3NBc0ZhY3RvcnM9RkFMU0Uscm93Lm5hbWVzPU5VTEwpPGJyPjxicj5ubGVu
ICZsdDstIDEwMDA8YnI+aXRlcmF0aW9ucyAmbHQ7LSAxMDAwMDxicj5hdmVyYWdlcyAmbHQ7LSBu
dW1lcmljKGl0ZXJhdGlvbnMpPGJyPndoaWNocCAmbHQ7LSAwLjk1PGJyPjxicj5mb3IoIFJtZXRo
b2QgaW4gYygiSW52ZXJzaW9uIiwiS2luZGVybWFuLVJhbWFnZSIsICJCb3gtTXVsbGVyIiwgIkFo
cmVucy1EaWV0ZXIiKSApIHs8YnI+Jm5ic3A7Jm5ic3A7ICZuYnNwO1JOR2tpbmQobm9ybWFsLmtp
bmQ9Um1ldGhvZCk8YnI+PGJyPiZuYnNwOyZuYnNwOyAmbmJzcDt0ICZsdDstIHN5c3RlbS50aW1l
KCB7PGJyPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvcihrIGluIDE6aXRlcmF0
aW9ucykgeyB2ICZsdDstIHJub3JtKG5sZW4pOyBhdmVyYWdlc1trXSAmbHQ7LSBtZWFuKHYpIH08
YnI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVzdWx0ICZsdDstIHF1YW50aWxl
KGF2ZXJhZ2VzLHByb2JzPWMod2hpY2hwKSk8YnI+Jm5ic3A7Jm5ic3A7ICZuYnNwO30pPGJyPjxi
cj4mbmJzcDsmbmJzcDsgJm5ic3A7cmVzZGF0YSAmbHQ7LSByYmluZChyZXNkYXRhLCBsaXN0KFJO
R21ldGhvZD1SbWV0aG9kLCBjdHlwZT0ibG9vcCIsIHJlc3VsdD1yZXN1bHQsIHVzZXI9dFsxXSxz
eXN0ZW09dFsyXSxlbGFwc2VkPXRbM10pKTxicj48YnI+Jm5ic3A7Jm5ic3A7ICZuYnNwO3QgJmx0
Oy0gc3lzdGVtLnRpbWUoezxicj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthdmVy
YWdlczIgJmx0Oy0gY29sTWVhbnMobWF0cml4KGRhdGE9cm5vcm0obmxlbippdGVyYXRpb25zKSwg
bnJvdz1ubGVuLCBuY29sPWl0ZXJhdGlvbnMpKTxicj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtyZXN1bHQgJmx0Oy0gcXVhbnRpbGUoYXZlcmFnZXMyLHByb2JzPWMod2hpY2hwKSk8
YnI+Jm5ic3A7Jm5ic3A7ICZuYnNwO30pPGJyPjxicj4mbmJzcDsmbmJzcDsgJm5ic3A7cmVzZGF0
YSAmbHQ7LSByYmluZChyZXNkYXRhLCBsaXN0KFJOR21ldGhvZD1SbWV0aG9kLCBjdHlwZT0iaXRl
cmF0aW9uIiwgcmVzdWx0PXJlc3VsdCwgdXNlcj10WzFdLHN5c3RlbT10WzJdLGVsYXBzZWQ9dFsz
XSkpPGJyPn08YnI+PGJyPiMgZGVsZXRlIGR1bW15IGZpcnN0IHJvdzxicj5yZXNkYXRhICZsdDst
IHJlc2RhdGFbMjpucm93KHJlc2RhdGEpLF08YnI+cm93Lm5hbWVzKHJlc2RhdGEpICZsdDstIE5V
TEw8YnI+cmVzZGF0YTwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUt
c3R5bGUtc3BhbiIgZmFjZT0iJ0NvdXJpZXIgTmV3JyIgc2l6ZT0iNCI+PHNwYW4gY2xhc3M9IkFw
cGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij4mbHQ7L1ItY29kZSZndDs8
L3NwYW4+PC9mb250PjwvZGl2PjwvYm9keT48L2h0bWw+

--===============5576747859010351982==--


From svetosch@gmx.net Thu Dec 24 04:03:44 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 10:03:01 +0100
Message-ID: <4B332E45.3030008@gmx.net>
In-Reply-To: Pine.A41.4.58.0912231101390.1974716@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5531299439341785486=="

--===============5531299439341785486==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Wed, 23 Dec 2009, Sven Schreiber wrote:
> 
>> Talha Yalta schrieb:
>>>> ...I have "borrowed" the code Jochen
>>>> Voss wrote for gsl to implement the ziggurat method for generating
>>>> random normal values.  Here's what I'm seeing after making this
>>>> change:
>>>>
>>>>          loop    vectorized
>>>> octave    2.59          0.53
>>>> gretl     0.87          0.39
>>>> ox        0.85          0.56
>>> Wow!
>>>
>> Yes I was gonna say that as well!
> 
> There is a possible catch: Doornik has an article (google: doornik
> ziggurat) arguing that the standard ziggurat method fails a test
> for high-dimensional randomness (and that one might expect it to
> fail), and he has a workaround which necessarily sacrifices some
> of the efficiency of ziggurat. (Unfortunately his code is free
> only for non-commercial use so it's incompatible with the GPL and
> we can't use it in gretl.)
> 
> So far as I can tell Doornik's article hasn't been published and I
> can't find any response from Marsaglia, but I'm taking this
> seriously.  Right now I'm running the L'Ecuyer "crush" test on the
> new gretl code -- should be finished within an hour or two!
> 

It turns out that for the same reason the NumPy people also have not
used the ziggurat so far. Whereas Octave does use it according to its
documentation. Don't know whether they take into account Doornik's
caveat, but it doesn't sound like it and this seems to explain the speed
advantage over Ox (just like in the above new gretl numbers).

What about introducing the (standard, non-Doornik) ziggurat as an
option, configurable through 'set'?

cheers,
sven

--===============5531299439341785486==--


From bhh@xs4all.nl Thu Dec 24 05:03:30 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 11:03:27 +0100
Message-ID: <E0F775A5-D85A-474E-A581-B41912326E54@xs4all.nl>
In-Reply-To: 330B39FF-7AD2-4C78-ABA7-38BD82E8A3D3@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8517815604300164786=="

--===============8517815604300164786==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


I discovered that the results of my previous post today were obtained NOT with 32-bit R but with 64-bit R.
I was running the script within the R-bundle of the editor TextMate; it uses 64-bit R and I don't know how to change that.
Sorry about this.

The correct 32-bit results are

         RNGmethod     ctype     result  user system elapsed
1        Inversion      loop 0.05118006 2.081  0.012   2.093
2        Inversion iteration 0.05154388 1.930  0.226   2.157
3 Kinderman-Ramage      loop 0.05292662 1.503  0.047   1.549
4 Kinderman-Ramage iteration 0.05189927 1.334  0.228   1.562
5       Box-Muller      loop 0.05266636 1.750  0.024   1.773
6       Box-Muller iteration 0.05138073 1.610  0.226   1.836
7    Ahrens-Dieter      loop 0.05259550 1.461  0.025   1.486
8    Ahrens-Dieter iteration 0.05209534 1.298  0.229   1.526


This is more in line with my post of the 22nd december.
It also clearly show that the 64-bit version of R is quite a bit quicker in this case.

There is a package on CRAN: SuppDists which provides the ziggurat method for generating from a normal distribution.
Warning: it only runs correctly in a 32-bit environment.

Results:

  RNGmethod     ctype     result  user system elapsed
1  ziggurat      loop 0.05240394 0.837  0.014   0.851
2  ziggurat iteration 0.05200224 0.541  0.362   0.902

Faster indeed.
But the system overhead in the "iteration" (or vectorized) version is rather large.


Berend

--===============8517815604300164786==--


From talhayalta@gmail.com Thu Dec 24 05:29:16 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 12:29:14 +0200
Message-ID: <5b1988aa0912240229k4ce5344dnad0aeb3597dd501c@mail.gmail.com>
In-Reply-To: 4B332E45.3030008@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2578591013278785501=="

--===============2578591013278785501==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

> It turns out that for the same reason the NumPy people also have not
> used the ziggurat so far. Whereas Octave does use it according to its
> documentation. Don't know whether they take into account Doornik's
> caveat, but it doesn't sound like it and this seems to explain the speed
> advantage over Ox (just like in the above new gretl numbers).
>
> What about introducing the (standard, non-Doornik) ziggurat as an
> option, configurable through 'set'?
There exists studies showing how bad things can happen when using a
deficient RNG for a given purpose. Accuracy and reliability should
always come first. While many programs have more than one RNG, I am
not sure whether  a more limited algorithm should be offered as an
option. I know an expert (L'Ecuyer) saying that there is no reason to
use a RNG if a better one is available.


-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============2578591013278785501==--


From cottrell@wfu.edu Thu Dec 24 12:04:54 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 12:04:54 -0500
Message-ID: <Pine.A41.4.58.0912241152140.2715956@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B332E45.3030008@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3256172480859052484=="

--===============3256172480859052484==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Thu, 24 Dec 2009, Sven Schreiber wrote:

> Allin Cottrell schrieb:
> > There is a possible catch [in the highspeed ziggurat code]:
> > Doornik has an article (google: doornik ziggurat) arguing that
> > the standard ziggurat method fails a test for high-dimensional
> > randomness (and that one might expect it to fail), and he has
> > a workaround which necessarily sacrifices some of the
> > efficiency of ziggurat. (Unfortunately his code is free only
> > for non-commercial use so it's incompatible with the GPL and
> > we can't use it in gretl.)
> >
> > So far as I can tell Doornik's article hasn't been published and I
> > can't find any response from Marsaglia, but I'm taking this
> > seriously.  Right now I'm running the L'Ecuyer "crush" test on the
> > new gretl code -- should be finished within an hour or two!
>
> It turns out that for the same reason the NumPy people also have not
> used the ziggurat so far. Whereas Octave does use it according to its
> documentation. Don't know whether they take into account Doornik's
> caveat, but it doesn't sound like it and this seems to explain the speed
> advantage over Ox (just like in the above new gretl numbers).
>
> What about introducing the (standard, non-Doornik) ziggurat as an
> option, configurable through 'set'?

Well, Doornik's specific claim was that the standard
Marsaglia/Tsang ziggurat fails the "collisions" test in the
"crush" test suite.  I've now run "crush" on the ziggurat code in
gretl (taken from Jochen Voss, but using the Mersenne Twister as
implemented in glib as the uniform input, rather than gsl's
uniform RNG).  It passes all the tests, including "collisions".

We could add a "set" option, but first I think we'd better run
both "crush" and "big crush" (many hours' worth) on both the
ziggurat code and Box-Muller.  Right now we don't really have
any basis for thinking that Box-Muller is "safer".

Allin.

--===============3256172480859052484==--


From cottrell@wfu.edu Thu Dec 24 12:21:42 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 12:21:41 -0500
Message-ID: <Pine.A41.4.58.0912241219260.2715956@f1n11.sp2net.wfu.edu>
In-Reply-To: E0F775A5-D85A-474E-A581-B41912326E54@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9198734550443397842=="

--===============9198734550443397842==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Thu, 24 Dec 2009, Berend Hasselman wrote:

> I discovered that the results of my previous post today were
> obtained NOT with 32-bit R but with 64-bit R. I was running the
> script within the R-bundle of the editor TextMate; it uses
> 64-bit R and I don't know how to change that. Sorry about this.
>
> The correct 32-bit results are
>
>          RNGmethod     ctype     result  user system elapsed
> 1        Inversion      loop 0.05118006 2.081  0.012   2.093

Thanks, but doesn't R have an internal timer?  Results obtained
via the "time" command are not really comparable with the ones
that Sven put up.

Allin.

--===============9198734550443397842==--


From talhayalta@gmail.com Thu Dec 24 12:42:51 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 19:40:22 +0200
Message-ID: <5b1988aa0912240940o4e34c4eepb28d66d859e0d116@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.0912241152140.2715956@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4048257645688831960=="

--===============4048257645688831960==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, Dec 24, 2009 at 7:04 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
>
> On Thu, 24 Dec 2009, Sven Schreiber wrote:
>
>> Allin Cottrell schrieb:
>> > There is a possible catch [in the highspeed ziggurat code]:
>> > Doornik has an article (google: doornik ziggurat) arguing that
>> > the standard ziggurat method fails a test for high-dimensional
>> > randomness (and that one might expect it to fail), and he has
>> > a workaround which necessarily sacrifices some of the
>> > efficiency of ziggurat. (Unfortunately his code is free only
>> > for non-commercial use so it's incompatible with the GPL and
>> > we can't use it in gretl.)
>> >
>> > So far as I can tell Doornik's article hasn't been published and I
>> > can't find any response from Marsaglia, but I'm taking this
>> > seriously.  Right now I'm running the L'Ecuyer "crush" test on the
>> > new gretl code -- should be finished within an hour or two!
>>
>> It turns out that for the same reason the NumPy people also have not
>> used the ziggurat so far. Whereas Octave does use it according to its
>> documentation. Don't know whether they take into account Doornik's
>> caveat, but it doesn't sound like it and this seems to explain the speed
>> advantage over Ox (just like in the above new gretl numbers).
>>
>> What about introducing the (standard, non-Doornik) ziggurat as an
>> option, configurable through 'set'?
>
> Well, Doornik's specific claim was that the standard
> Marsaglia/Tsang ziggurat fails the "collisions" test in the
> "crush" test suite.  I've now run "crush" on the ziggurat code in
> gretl (taken from Jochen Voss, but using the Mersenne Twister as
> implemented in glib as the uniform input, rather than gsl's
> uniform RNG).  It passes all the tests, including "collisions".
>
> We could add a "set" option, but first I think we'd better run
> both "crush" and "big crush" (many hours' worth) on both the
> ziggurat code and Box-Muller.  Right now we don't really have
> any basis for thinking that Box-Muller is "safer".
I think we would be safe to employ any of the two (or another one for
that matter) as long as we can say that the RNG in gretl passes the
big crush test in TestU01.
Talha

-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============4048257645688831960==--


From bhh@xs4all.nl Thu Dec 24 12:43:28 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 18:43:24 +0100
Message-ID: <07244A2D-C130-429D-8083-4FC3FE7158A3@xs4all.nl>
In-Reply-To: Pine.A41.4.58.0912241219260.2715956@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3381133607954716425=="

--===============3381133607954716425==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable


On 24-12-2009, at 18:21, Allin Cottrell wrote:

>=20
> On Thu, 24 Dec 2009, Berend Hasselman wrote:
>=20
>> I discovered that the results of my previous post today were
>> obtained NOT with 32-bit R but with 64-bit R. I was running the
>> script within the R-bundle of the editor TextMate; it uses
>> 64-bit R and I don't know how to change that. Sorry about this.
>>=20
>> The correct 32-bit results are
>>=20
>>         RNGmethod     ctype     result  user system elapsed
>> 1        Inversion      loop 0.05118006 2.081  0.012   2.093
>=20
> Thanks, but doesn't R have an internal timer?  Results obtained
> via the "time" command are not really comparable with the ones
> that Sven put up.


I didn't use an external time command.=20
I used the R provided system.time( { R-expressions } ) function (in the base =
package).
>From the help entry for proc.time:

The =E2=80=98user time=E2=80=99 is the CPU time charged for the execution of =
user instructions of the calling process. The =E2=80=98system time=E2=80=99 i=
s the CPU time charged for execution by the system on behalf of the calling p=
rocess.

I haven't found anything else.

Berend

--===============3381133607954716425==--


From cottrell@wfu.edu Thu Dec 24 13:43:26 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 13:43:26 -0500
Message-ID: <Pine.A41.4.58.0912241340130.2654544@f1n11.sp2net.wfu.edu>
In-Reply-To: 07244A2D-C130-429D-8083-4FC3FE7158A3@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8223624968257373103=="

--===============8223624968257373103==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Thu, 24 Dec 2009, Berend Hasselman wrote:

> On 24-12-2009, at 18:21, Allin Cottrell wrote:
>
> >
> > On Thu, 24 Dec 2009, Berend Hasselman wrote:
> >
> >> I discovered that the results of my previous post today were
> >> obtained NOT with 32-bit R but with 64-bit R. I was running the
> >> script within the R-bundle of the editor TextMate; it uses
> >> 64-bit R and I don't know how to change that. Sorry about this.
> >>
> >> The correct 32-bit results are
> >>
> >>         RNGmethod     ctype     result  user system elapsed
> >> 1        Inversion      loop 0.05118006 2.081  0.012   2.093
> >
> > Thanks, but doesn't R have an internal timer?  Results obtained
> > via the "time" command are not really comparable with the ones
> > that Sven put up.
>
> I didn't use an external time command.
> I used the R provided system.time...

OK, sorry, it looked like output from the unix "time" program. I
suppose, then, that the "elapsed" figure is the comparable one.

Allin.

--===============8223624968257373103==--


From cottrell@wfu.edu Thu Dec 24 13:44:45 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 13:44:45 -0500
Message-ID: <Pine.A41.4.58.0912241343430.2654544@f1n11.sp2net.wfu.edu>
In-Reply-To: 5b1988aa0912240940o4e34c4eepb28d66d859e0d116@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7423489019195239607=="

--===============7423489019195239607==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


On Thu, 24 Dec 2009, Talha Yalta wrote:

> On Thu, Dec 24, 2009 at 7:04 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
> >
> > On Thu, 24 Dec 2009, Sven Schreiber wrote:
> >
> >> Allin Cottrell schrieb:
> >> > There is a possible catch [in the highspeed ziggurat code]:
> >> > Doornik has an article (google: doornik ziggurat) arguing that
> >> > the standard ziggurat method fails a test for high-dimensional
> >> > randomness (and that one might expect it to fail), and he has
> >> > a workaround which necessarily sacrifices some of the
> >> > efficiency of ziggurat. (Unfortunately his code is free only
> >> > for non-commercial use so it's incompatible with the GPL and
> >> > we can't use it in gretl.)
> >> >
> >> > So far as I can tell Doornik's article hasn't been published and I
> >> > can't find any response from Marsaglia, but I'm taking this
> >> > seriously.  Right now I'm running the L'Ecuyer "crush" test on the
> >> > new gretl code -- should be finished within an hour or two!
> >>
> >> It turns out that for the same reason the NumPy people also have not
> >> used the ziggurat so far. Whereas Octave does use it according to its
> >> documentation. Don't know whether they take into account Doornik's
> >> caveat, but it doesn't sound like it and this seems to explain the speed
> >> advantage over Ox (just like in the above new gretl numbers).
> >>
> >> What about introducing the (standard, non-Doornik) ziggurat as an
> >> option, configurable through 'set'?
> >
> > Well, Doornik's specific claim was that the standard
> > Marsaglia/Tsang ziggurat fails the "collisions" test in the
> > "crush" test suite.  I've now run "crush" on the ziggurat code in
> > gretl (taken from Jochen Voss, but using the Mersenne Twister as
> > implemented in glib as the uniform input, rather than gsl's
> > uniform RNG).  It passes all the tests, including "collisions".
> >
> > We could add a "set" option, but first I think we'd better run
> > both "crush" and "big crush" (many hours' worth) on both the
> > ziggurat code and Box-Muller.  Right now we don't really have
> > any basis for thinking that Box-Muller is "safer".
> I think we would be safe to employ any of the two (or another one for
> that matter) as long as we can say that the RNG in gretl passes the
> big crush test in TestU01.

OK, any volunteers to run "big crush" on CVS gretl?

Allin.


--===============7423489019195239607==--


From talhayalta@gmail.com Thu Dec 24 15:08:25 2009
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Thu, 24 Dec 2009 22:08:22 +0200
Message-ID: <5b1988aa0912241208k1fba7d2aqef9f32e34b37a50f@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.0912241343430.2654544@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0962331200795403656=="

--===============0962331200795403656==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

>> > We could add a "set" option, but first I think we'd better run
>> > both "crush" and "big crush" (many hours' worth) on both the
>> > ziggurat code and Box-Muller.  Right now we don't really have
>> > any basis for thinking that Box-Muller is "safer".
>> I think we would be safe to employ any of the two (or another one for
>> that matter) as long as we can say that the RNG in gretl passes the
>> big crush test in TestU01.
>
> OK, any volunteers to run "big crush" on CVS gretl?
I have experience testing various software (including gretl) using the
earlier and now irrelevant DIEHARD test suite of randomness. TESTU01
is now the standard, however, AFAIK it requires the knowledge of
programming in the C language. I am not sure how difficult it would be
to program TESTU01 to test gretl on this front but I can promise to
learn C and attempt to do this in the summer. Given how busy you are
trying to address all sorts of points we keep raising, this is the
least I can do.
Talha



-- 
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--


--===============0962331200795403656==--


From cottrell@wfu.edu Sat Dec 26 06:03:29 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Sat, 26 Dec 2009 06:03:28 -0500
Message-ID: <Pine.A41.4.58.0912260551100.2171008@f1n11.sp2net.wfu.edu>
In-Reply-To: 5b1988aa0912241208k1fba7d2aqef9f32e34b37a50f@mail.gmail.com
Content-Type: multipart/mixed; boundary="===============6990114248192802530=="

--===============6990114248192802530==
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="glib.c"
MIME-Version: 1.0

I2luY2x1ZGUgInVuaWYwMS5oIg0KI2luY2x1ZGUgImJiYXR0ZXJ5LmgiDQoNCiNpbmNsdWRlIDxn
bGliLmg+DQojaW5jbHVkZSA8Z3JldGwvbGliZ3JldGwuaD4NCiNpbmNsdWRlIDxtYXRoLmg+DQoj
aW5jbHVkZSAidGltZS5oIg0KDQpzdGF0aWMgR1JhbmQgKm15X3JhbmQ7DQoNCi8qIHBvc2l0aW9u
IG9mIHJpZ2h0LW1vc3Qgc3RlcCAqLw0KI2RlZmluZSBQQVJBTV9SIDMuNDQ0Mjg2NDc2NzYNCg0K
LyogdGFidWxhdGVkIHZhbHVlcyBmb3IgdGhlIGhlaWdodCBvZiB0aGUgWmlnZ3VyYXQgbGV2ZWxz
ICovDQpzdGF0aWMgY29uc3QgZG91YmxlIHl0YWJbMTI4XSA9IHsNCiAgICAxLCAwLjk2MzU5ODYy
MzAxMSwgMC45MzYyODA4MTMzNTMsIDAuOTEzMDQxMTA0MjUzLA0KICAgIDAuODkyMjc4NTA2Njk2
LCAwLjg3MzIzOTM1NjkxOSwgMC44NTU0OTY0MDc2MzQsIDAuODM4Nzc4OTI4MzQ5LA0KICAgIDAu
ODIyOTAyMDgzNjk5LCAwLjgwNzczMjczODIzNCwgMC43OTMxNzEwNDU1MTksIDAuNzc5MTM5NzI2
NTA1LA0KICAgIDAuNzY1NTc3NDM2MDgyLCAwLjc1MjQzNDQ1NjI0OCwgMC43Mzk2Njk3ODc2Nzcs
IDAuNzI3MjQ5MTIwMjg1LA0KICAgIDAuNzE1MTQzMzc3NDEzLCAwLjcwMzMyNzY0NjQ1NSwgMC42
OTE3ODAzNzcwMzUsIDAuNjgwNDgyNzY4OTEsDQogICAgMC42Njk0MTgyOTcyMzMsIDAuNjU4NTcy
MzM5MTIsIDAuNjQ3OTMxODc2MTg5LCAwLjYzNzQ4NTI1NDg5NiwNCiAgICAwLjYyNzIyMTk5MTQ1
LCAwLjYxNzEzMjYxMTUzMiwgMC42MDcyMDg1MTc0NjcsIDAuNTk3NDQxODc3Mjk2LA0KICAgIDAu
NTg3ODI1NTMxNDY1LCAwLjU3ODM1MjkxMzgwMywgMC41NjkwMTc5ODQxOTgsIDAuNTU5ODE1MTcw
OTExLA0KICAgIDAuNTUwNzM5MzIwODc3LCAwLjU0MTc4NTY1NjY4MiwgMC41MzI5NDk3MzkxNDUs
IDAuNTI0MjI3NDM0NjI4LA0KICAgIDAuNTE1NjE0ODg2MzczLCAwLjUwNzEwODQ4OTI1MywgMC40
OTg3MDQ4Njc0NzgsIDAuNDkwNDAwODU0ODEyLA0KICAgIDAuNDgyMTkzNDc2OTg2LCAwLjQ3NDA3
OTkzNjAxLCAwLjQ2NjA1NzU5NjEyNSwgMC40NTgxMjM5NzEyMTQsDQogICAgMC40NTAyNzY3MTM0
NjcsIDAuNDQyNTEzNjAzMTcxLCAwLjQzNDgzMjUzOTQ3MywgMC40MjcyMzE1MzIwMjIsDQogICAg
MC40MTk3MDg2OTMzNzksIDAuNDEyMjYyMjMyMTIsIDAuNDA0ODkwNDQ2NTQ4LCAwLjM5NzU5MTcx
ODk1NSwNCiAgICAwLjM5MDM2NDUxMDM4MiwgMC4zODMyMDczNTU4MTYsIDAuMzc2MTE4ODU5Nzg4
LCAwLjM2OTA5NzY5MjMzNCwNCiAgICAwLjM2MjE0MjU4NTI4MiwgMC4zNTUyNTIzMjg4MzQsIDAu
MzQ4NDI1NzY4NDE1LCAwLjM0MTY2MTgwMTc3NiwNCiAgICAwLjMzNDk1OTM3NjMxMSwgMC4zMjgz
MTc0ODY1ODgsIDAuMzIxNzM1MTcyMDYzLCAwLjMxNTIxMTUxNDk3LA0KICAgIDAuMzA4NzQ1NjM4
MzY3LCAwLjMwMjMzNjcwNDMzOCwgMC4yOTU5ODM5MTIzMiwgMC4yODk2ODY0OTc1NzEsDQogICAg
MC4yODM0NDM3Mjk3MzksIDAuMjc3MjU0OTExNTYsIDAuMjcxMTE5Mzc3NjQ5LCAwLjI2NTAzNjQ5
MzM4NywNCiAgICAwLjI1OTAwNTY1MzkxMiwgMC4yNTMwMjYyODMxODMsIDAuMjQ3MDk3ODMzMTM5
LCAwLjI0MTIxOTc4MjkzMiwNCiAgICAwLjIzNTM5MTYzODIzOSwgMC4yMjk2MTI5MzA2NDksIDAu
MjIzODgzMjE3MTIyLCAwLjIxODIwMjA3OTUxOCwNCiAgICAwLjIxMjU2OTEyNDIwMSwgMC4yMDY5
ODM5ODE3MDksIDAuMjAxNDQ2MzA2NDk2LCAwLjE5NTk1NTc3Njc0NSwNCiAgICAwLjE5MDUxMjA5
NDI1NiwgMC4xODUxMTQ5ODQ0MDYsIDAuMTc5NzY0MTk2MTg1LCAwLjE3NDQ1OTUwMjMyNCwNCiAg
ICAwLjE2OTIwMDY5OTQ5MiwgMC4xNjM5ODc2MDg2LCAwLjE1ODgyMDA3NTE5NSwgMC4xNTM2OTc5
Njk5NjQsDQogICAgMC4xNDg2MjExODkzNDgsIDAuMTQzNTg5NjU2Mjk1LCAwLjEzODYwMzMyMTE0
MywgMC4xMzM2NjIxNjI2NjksDQogICAgMC4xMjg3NjYxODkzMDksIDAuMTIzOTE1NDQwNTgyLCAw
LjExOTEwOTk4ODc0NSwgMC4xMTQzNDk5NDA3MDMsDQogICAgMC4xMDk2MzU0NDAyMywgMC4xMDQ5
NjY2NzA1MzMsIDAuMTAwMzQzODU3MjMyLCAwLjA5NTc2NzI3MTgyNjYsDQogICAgMC4wOTEyMzcy
MzU3MzI5LCAwLjA4Njc1NDEyNTAxMjcsIDAuMDgyMzE4Mzc1OTMyLCAwLjA3NzkzMDQ5MTUyOTUs
DQogICAgMC4wNzM1OTEwNDk0MjY2LCAwLjA2OTMwMDcxMTE3NDIsIDAuMDY1MDYwMjMzNTI5LCAw
LjA2MDg3MDQ4MjE3NDUsDQogICAgMC4wNTY3MzI0NDg1ODQsIDAuMDUyNjQ3MjcwOTgsIDAuMDQ4
NjE2MjYwNzE2MywgMC4wNDQ2NDA5MzU5NzY5LA0KICAgIDAuMDQwNzIzMDY1NTQxNSwgMC4wMzY4
NjQ3MjY3Mzg2LCAwLjAzMzA2ODM4MzkzNzgsIDAuMDI5MzM2OTk3NzQxMSwNCiAgICAwLjAyNTY3
NDE4MTgyODgsIDAuMDIyMDg0NDM3MjYzNCwgMC4wMTg1NzM1MjAwNTc3LCAwLjAxNTE0OTA1NTI4
NTQsDQogICAgMC4wMTE4MjE2NTMyNjE0LCAwLjAwODYwNzE5NDgzMDc5LCAwLjAwNTUzMjQ1Mjcy
NjE0LCAwLjAwMjY1NDM1MjE0NTY1DQp9Ow0KDQovKiB0YWJ1bGF0ZWQgdmFsdWVzIGZvciAyXjI0
IHRpbWVzIHhbaV0veFtpKzFdLA0KICogdXNlZCB0byBhY2NlcHQgZm9yIFUqeFtpKzFdPD14W2ld
IHdpdGhvdXQgYW55IGZsb2F0aW5nIHBvaW50IG9wZXJhdGlvbnMgKi8NCnN0YXRpYyBjb25zdCBn
dWludDMyIGt0YWJbMTI4XSA9IHsNCiAgICAwLCAxMjU5MDY0NCwgMTQyNzI2NTMsIDE0OTg4OTM5
LA0KICAgIDE1Mzg0NTg0LCAxNTYzNTAwOSwgMTU4MDc1NjEsIDE1OTMzNTc3LA0KICAgIDE2MDI5
NTk0LCAxNjEwNTE1NSwgMTYxNjYxNDcsIDE2MjE2Mzk5LA0KICAgIDE2MjU4NTA4LCAxNjI5NDI5
NSwgMTYzMjUwNzgsIDE2MzUxODMxLA0KICAgIDE2Mzc1MjkxLCAxNjM5NjAyNiwgMTY0MTQ0Nzks
IDE2NDMxMDAyLA0KICAgIDE2NDQ1ODgwLCAxNjQ1OTM0MywgMTY0NzE1NzgsIDE2NDgyNzQ0LA0K
ICAgIDE2NDkyOTcwLCAxNjUwMjM2OCwgMTY1MTEwMzEsIDE2NTE5MDM5LA0KICAgIDE2NTI2NDU5
LCAxNjUzMzM1MiwgMTY1Mzk3NjksIDE2NTQ1NzU1LA0KICAgIDE2NTUxMzQ4LCAxNjU1NjU4NCwg
MTY1NjE0OTMsIDE2NTY2MTAxLA0KICAgIDE2NTcwNDMzLCAxNjU3NDUxMSwgMTY1NzgzNTMsIDE2
NTgxOTc3LA0KICAgIDE2NTg1Mzk4LCAxNjU4ODYyOSwgMTY1OTE2ODUsIDE2NTk0NTc1LA0KICAg
IDE2NTk3MzExLCAxNjU5OTkwMSwgMTY2MDIzNTQsIDE2NjA0Njc5LA0KICAgIDE2NjA2ODgxLCAx
NjYwODk2OCwgMTY2MTA5NDUsIDE2NjEyODE4LA0KICAgIDE2NjE0NTkyLCAxNjYxNjI3MiwgMTY2
MTc4NjEsIDE2NjE5MzYzLA0KICAgIDE2NjIwNzgyLCAxNjYyMjEyMSwgMTY2MjMzODMsIDE2NjI0
NTcwLA0KICAgIDE2NjI1Njg1LCAxNjYyNjczMCwgMTY2Mjc3MDgsIDE2NjI4NjE5LA0KICAgIDE2
NjI5NDY1LCAxNjYzMDI0OCwgMTY2MzA5NjksIDE2NjMxNjI4LA0KICAgIDE2NjMyMjI4LCAxNjYz
Mjc2OCwgMTY2MzMyNDgsIDE2NjMzNjcxLA0KICAgIDE2NjM0MDM0LCAxNjYzNDM0MCwgMTY2MzQ1
ODYsIDE2NjM0Nzc0LA0KICAgIDE2NjM0OTAzLCAxNjYzNDk3MiwgMTY2MzQ5ODAsIDE2NjM0OTI2
LA0KICAgIDE2NjM0ODEwLCAxNjYzNDYyOCwgMTY2MzQzODEsIDE2NjM0MDY2LA0KICAgIDE2NjMz
NjgwLCAxNjYzMzIyMiwgMTY2MzI2ODgsIDE2NjMyMDc1LA0KICAgIDE2NjMxMzgwLCAxNjYzMDU5
OCwgMTY2Mjk3MjYsIDE2NjI4NzU3LA0KICAgIDE2NjI3Njg2LCAxNjYyNjUwNywgMTY2MjUyMTIs
IDE2NjIzNzk0LA0KICAgIDE2NjIyMjQzLCAxNjYyMDU0OCwgMTY2MTg2OTgsIDE2NjE2Njc5LA0K
ICAgIDE2NjE0NDc2LCAxNjYxMjA3MSwgMTY2MDk0NDQsIDE2NjA2NTcxLA0KICAgIDE2NjAzNDI1
LCAxNjU5OTk3MywgMTY1OTYxNzgsIDE2NTkxOTk1LA0KICAgIDE2NTg3MzY5LCAxNjU4MjIzNywg
MTY1NzY1MjAsIDE2NTcwMTIwLA0KICAgIDE2NTYyOTE3LCAxNjU1NDc1OCwgMTY1NDU0NTAsIDE2
NTM0NzM5LA0KICAgIDE2NTIyMjg3LCAxNjUwNzYzOCwgMTY0OTAxNTIsIDE2NDY4OTA3LA0KICAg
IDE2NDQyNTE4LCAxNjQwODgwNCwgMTYzNjQwOTUsIDE2MzAxNjgzLA0KICAgIDE2MjA3NzM4LCAx
NjA0Nzk5NCwgMTU3MDQyNDgsIDE1NDcyOTI2DQp9Ow0KDQovKiB0YWJ1bGF0ZWQgdmFsdWVzIG9m
IDJeey0yNH0qeFtpXSAqLw0Kc3RhdGljIGNvbnN0IGRvdWJsZSB3dGFiWzEyOF0gPSB7DQogICAg
MS42MjMxODMxNDgxN2UtMDgsIDIuMTYyOTE1MDUyMTRlLTA4LCAyLjU0MjQ2MzA1MDg3ZS0wOCwg
Mi44NDU3OTUyNTkzOGUtMDgsDQogICAgMy4xMDM0MDAyMjQ4MmUtMDgsIDMuMzMwMTE3MjYyNDNl
LTA4LCAzLjUzNDM5MDYwMzQ1ZS0wOCwgMy43MjE1MjY3MjY1OGUtMDgsDQogICAgMy44OTUwOTg5
NTcyZS0wOCwgNC4wNTc2Mzk2NDc2NGUtMDgsIDQuMjExMDE1NDg5MTVlLTA4LCA0LjM1NjY0NjI0
OTA0ZS0wOCwNCiAgICA0LjQ5NTYzOTY4MzM2ZS0wOCwgNC42Mjg4Nzg2NDAyOWUtMDgsIDQuNzU3
MDc5NDU3MzVlLTA4LCA0Ljg4MDgzMjM3MjU3ZS0wOCwNCiAgICA1LjAwMDYzMDI1Mzg0ZS0wOCwg
NS4xMTY4ODk1MDQyOGUtMDgsIDUuMjI5OTY1NTg2MTZlLTA4LCA1LjM0MDE2NDc1NjI0ZS0wOCwN
CiAgICA1LjQ0Nzc1MzA3ODcxZS0wOCwgNS41NTI5NjM0NDU4MWUtMDgsIDUuNjU2MDAxMTE2NTll
LTA4LCA1Ljc1NzA0ODEzNjk1ZS0wOCwNCiAgICA1Ljg1NjI2NjkwNDEyZS0wOCwgNS45NTM4MDMw
Njg2MmUtMDgsIDYuMDQ5Nzg3OTE3NzZlLTA4LCA2LjE0NDM0MDM0OTAxZS0wOCwNCiAgICA2LjIz
NzU2ODUxNjI2ZS0wOCwgNi4zMjk1NzEyMTI1OWUtMDgsIDYuNDIwNDM5MDM5MzdlLTA4LCA2LjUx
MDI1NTQwMDc3ZS0wOCwNCiAgICA2LjU5OTA5NzM1NDQ3ZS0wOCwgNi42ODcwMzYzNDM0MWUtMDgs
IDYuNzc0MTM4ODI4NDhlLTA4LCA2Ljg2MDQ2NjgzODFlLTA4LA0KICAgIDYuOTQ2MDc4NDQ4MDRl
LTA4LCA3LjAzMTAyODIwMjAzZS0wOCwgNy4xMTUzNjc0ODIyOWUtMDgsIDcuMTk5MTQ0ODM3MmUt
MDgsDQogICAgNy4yODI0MDYyNzIzZS0wOCwgNy4zNjUxOTU1MDk5MmUtMDgsIDcuNDQ3NTU0MjIx
NThlLTA4LCA3LjUyOTUyMjIzNzAzZS0wOCwNCiAgICA3LjYxMTEzNzczMzA4ZS0wOCwgNy42OTI0
Mzc0MDQ2N2UtMDgsIDcuNzczNDU2NjIwODZlLTA4LCA3Ljg1NDIyOTU2NzQzZS0wOCwNCiAgICA3
LjkzNDc4OTM3NzkzZS0wOCwgOC4wMTUxNjgyNTQ3MWUtMDgsIDguMDk1Mzk3NTgxMjhlLTA4LCA4
LjE3NTUwODAyNjk5ZS0wOCwNCiAgICA4LjI1NTUyOTY0NTM1ZS0wOCwgOC4zMzU0OTE5NjY2MWUt
MDgsIDguNDE1NDI0MDg1NjllLTA4LCA4LjQ5NTM1NDc0NjAxZS0wOCwNCiAgICA4LjU3NTMxMjQy
MDA2ZS0wOCwgOC42NTUzMjUzODcyM2UtMDgsIDguNzM1NDIxODA5NTVlLTA4LCA4LjgxNTYyOTgw
NTllLTA4LA0KICAgIDguODk1OTc3NTI1MjFlLTA4LCA4Ljk3NjQ5MzIxOTA4ZS0wOCwgOS4wNTcy
MDUzMTQ1MWUtMDgsIDkuMTM4MTQyNDg3ZS0wOCwNCiAgICA5LjIxOTMzMzczNDcxZS0wOCwgOS4z
MDA4MDg0NTQwN2UtMDgsIDkuMzgyNTk2NTE3MzhlLTA4LCA5LjQ2NDcyODM1Mjk4ZS0wOCwNCiAg
ICA5LjU0NzIzNTAyODQ3ZS0wOCwgOS42MzAxNDgzMzc2OWUtMDgsIDkuNzEzNTAwODkyMDFlLTA4
LCA5Ljc5NzMyNjIxNjY5ZS0wOCwNCiAgICA5Ljg4MTY1ODg1Mjk3ZS0wOCwgOS45NjY1MzQ0NjY5
M2UtMDgsIDEuMDA1MTk4OTk2NThlLTA3LCAxLjAxMzgwNjM2MjNlLTA3LA0KICAgIDEuMDIyNDc5
NTIxMjZlLTA3LCAxLjAzMTIyMjYxNTU0ZS0wNywgMS4wNDAwMzk5Njc2OWUtMDcsIDEuMDQ4OTM2
MDk3OTVlLTA3LA0KICAgIDEuMDU3OTE1NzQzMTNlLTA3LCAxLjA2Njk4Mzg3NzI1ZS0wNywgMS4w
NzYxNDU3MzQyM2UtMDcsIDEuMDg1NDA2ODMyOTZlLTA3LA0KICAgIDEuMDk0NzczMDA1MDhlLTA3
LCAxLjEwNDI1MDQyNTdlLTA3LCAxLjExMzg0NTY0NzcxZS0wNywgMS4xMjM1NjU2NDAwN2UtMDcs
DQogICAgMS4xMzM0MTc4MzA3MWUtMDcsIDEuMTQzNDEwMTU0NzVlLTA3LCAxLjE1MzU1MTEwODg3
ZS0wNywgMS4xNjM4NDk4MTI5MWUtMDcsDQogICAgMS4xNzQzMTYwNzk3N2UtMDcsIDEuMTg0OTYw
NDk1MTRlLTA3LCAxLjE5NTc5NDUwODcyZS0wNywgMS4yMDY4MzA1MzkwOWUtMDcsDQogICAgMS4y
MTgwODIwOTQ2OGUtMDcsIDEuMjI5NTYzOTE0MWUtMDcsIDEuMjQxMjkyMTI5NTJlLTA3LCAxLjI1
MzI4NDQ1Nzk3ZS0wNywNCiAgICAxLjI2NTU2MDQyNjU4ZS0wNywgMS4yNzgxNDE2MzkxNmUtMDcs
IDEuMjkxMDUyMDkzNzVlLTA3LCAxLjMwNDMxODU2MzQxZS0wNywNCiAgICAxLjMxNzk3MTA1NTk4
ZS0wNywgMS4zMzIwNDMzNzM2ZS0wNywgMS4zNDY1NzM3OTkxNGUtMDcsIDEuMzYxNjA1OTQ2MDZl
LTA3LA0KICAgIDEuMzc3MTg5ODIxMDNlLTA3LCAxLjM5MzM4MzE2Njc5ZS0wNywgMS40MTAyNTMx
Nzk3MWUtMDcsIDEuNDI3ODc4NzM1MzVlLTA3LA0KICAgIDEuNDQ2MzUzMzE0OTllLTA3LCAxLjQ2
NTc4ODkxNzNlLTA3LCAxLjQ4NjMyMTM4NDM2ZS0wNywgMS41MDgxMTc4MDcxOWUtMDcsDQogICAg
MS41MzEzODcwNzQwMmUtMDcsIDEuNTU2Mzk1MzIwNDdlLTA3LCAxLjU4MzQ4OTMxNDI2ZS0wNywg
MS42MTMxMzMyNTkwOGUtMDcsDQogICAgMS42NDU5Njk1Mjg1NmUtMDcsIDEuNjgyOTI0OTUyMDNl
LTA3LCAxLjcyNTQxMTI4Njk0ZS0wNywgMS43NzU3NDI3OTQ5NmUtMDcsDQogICAgMS44MzgxMzU1
MDQ3N2UtMDcsIDEuOTIxNjYwNDA4ODVlLTA3LCAyLjA1Mjk1NDcxOTUyZS0wNywgMi4yMjYwMDgz
OTg5M2UtMDcNCn07DQoNCnN0YXRpYyBkb3VibGUgcmFuX25vcm1hbF96aWdndXJhdCAodm9pZCkN
CnsNCiAgICBndWludDMyIFUsIHNpZ24sIGksIGo7DQogICAgZG91YmxlIHgsIHk7DQoNCiAgICB3
aGlsZSAoMSkgew0KCVUgPSBnX3JhbmRfaW50KG15X3JhbmQpOw0KCWkgPSBVICYgMHgwMDAwMDA3
RjsJLyogNyBiaXRzIHRvIGNob29zZSB0aGUgc3RlcCAqLw0KCXNpZ24gPSBVICYgMHgwMDAwMDA4
MDsJLyogMSBiaXQgZm9yIHRoZSBzaWduICovDQoJaiA9IFUgPj4gODsJCS8qIDI0IGJpdHMgZm9y
IHRoZSB4LXZhbHVlICovDQoNCgl4ID0gaiAqIHd0YWJbaV07DQoNCglpZiAoaiA8IGt0YWJbaV0p
IHsNCgkgICAgYnJlYWs7DQoJfQ0KDQoJaWYgKGkgPCAxMjcpIHsNCgkgICAgZG91YmxlIHkwID0g
eXRhYltpXSwgeTEgPSB5dGFiW2krMV07DQoNCgkgICAgeSA9IHkxICsgKHkwIC0geTEpICogZ19y
YW5kX2RvdWJsZShteV9yYW5kKTsNCgl9IGVsc2Ugew0KCSAgICB4ID0gUEFSQU1fUiAtIGxvZygx
LjAgLSBnX3JhbmRfZG91YmxlKG15X3JhbmQpKSAvIFBBUkFNX1I7DQoJICAgIHkgPSBleHAoLVBB
UkFNX1IgKiAoeCAtIDAuNSAqIFBBUkFNX1IpKSAqIGdfcmFuZF9kb3VibGUobXlfcmFuZCk7DQoJ
fQ0KDQoJaWYgKHkgPCBleHAoLTAuNSAqIHggKiB4KSkgew0KCSAgICBicmVhazsNCgl9DQogICAg
fQ0KDQogICAgcmV0dXJuIHNpZ24gPyB4IDogLXg7DQp9DQoNCiNpZiAwDQpzdGF0aWMgZG91Ymxl
IGdsaWJfcmFuZG9tX2RvdWJsZSAodm9pZCkNCnsNCiAgICBpZiAobXlfcmFuZCA9PSBOVUxMKSB7
DQoJbXlfcmFuZCA9IGdfcmFuZF9uZXcoKTsNCglnX3JhbmRfc2V0X3NlZWQobXlfcmFuZCwgdGlt
ZShOVUxMKSk7DQogICAgfQ0KDQogICAgcmV0dXJuIGdfcmFuZF9kb3VibGUobXlfcmFuZCk7DQp9
DQojZW5kaWYNCg0Kc3RhdGljIGRvdWJsZSB6aWdfcmFuZG9tX2RvdWJsZSAodm9pZCkNCnsNCiAg
ICBkb3VibGUgeDsNCg0KICAgIGlmIChteV9yYW5kID09IE5VTEwpIHsNCglteV9yYW5kID0gZ19y
YW5kX25ldygpOw0KCWdfcmFuZF9zZXRfc2VlZChteV9yYW5kLCB0aW1lKE5VTEwpKTsNCiAgICB9
DQoNCiAgICB4ID0gcmFuX25vcm1hbF96aWdndXJhdCgpOw0KICAgIHJldHVybiBub3JtYWxfY2Rm
KHgpOw0KfQ0KDQppbnQgbWFpbiAodm9pZCkNCnsNCiAgICB1bmlmMDFfR2VuICpnZW47DQoNCiAg
ICBnZW4gPSB1bmlmMDFfQ3JlYXRlRXh0ZXJuR2VuMDEoImdyZXRsIiwgemlnX3JhbmRvbV9kb3Vi
bGUpOw0KICAgIC8qIGNob29vc2UgdGhlIHRlc3QgYmF0dGVyeSBiZWxvdyAqLw0KICAgIGJiYXR0
ZXJ5X0JpZ0NydXNoKGdlbik7DQogICAgdW5pZjAxX0RlbGV0ZUV4dGVybkdlbjAxKGdlbik7IA0K
DQogICAgcmV0dXJuIDA7DQp9DQo=

--===============6990114248192802530==--


From annen@web-reg.de Sat Dec 26 08:41:24 2009
From: Kurt Annen <annen@web-reg.de>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] code fragments
Date: Sat, 26 Dec 2009 14:41:13 +0100
Message-ID: <4B361279.9080404@web-reg.de>
Content-Type: multipart/mixed; boundary="===============0620189698321775153=="

--===============0620189698321775153==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgo8aGVhZD4KPC9oZWFkPgo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIiB0ZXh0
PSIjMDAwMDAwIj4KaGksPGJyPgo8YnI+Cmkgd3JvdGUgYW4gZXZpZXdzIHRvIHhscyBpbXBvcnRl
ciBpbiBhbnNpIGMgb25lIHllYXIgYWdvLiBzaW5jZSBpIGhhdmUKbm8gdGltZSB0byBhZGQgdGhl
IGNvZGUgaW50byBncmV0bCwgaSB3b29sZCBnaXZlIHNvbWVvbmUgdGhpcyBjb2RlIHRvCmFkZCBp
dCBpbiBncmV0bC48YnI+Cjxicj4KPGJyPgo8ZGl2IGNsYXNzPSJtb3otc2lnbmF0dXJlIj4tLSA8
YnI+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyAi
Pgo8bWV0YSBjb250ZW50PSJXb3JkLkRvY3VtZW50IiBuYW1lPSJQcm9nSWQiPgo8bWV0YSBjb250
ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjI5NjMiIG5hbWU9IkdFTkVSQVRPUiI+CjxtZXRhIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDExIiBuYW1lPSJPcmlnaW5hdG9yIj4KPGxpbmsgaHJlZj0iU2ln
bmF0dXJlMi1EYXRlaWVuL2ZpbGVsaXN0LnhtbCIgcmVsPSJGaWxlLUxpc3QiPgo8bGluayBocmVm
PSJTaWduYXR1cmUyLURhdGVpZW4vZWRpdGRhdGEubXNvIiByZWw9IkVkaXQtVGltZS1EYXRhIj4K
PCEtLVtpZiAhbXNvXT4KPFNUWUxFPnZcOiogewoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwp
Cn0Kb1w6KiB7CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkKfQp3XDoqIHsKCUJFSEFWSU9S
OiB1cmwoI2RlZmF1bHQjVk1MKQp9Ci5zaGFwZSB7CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZN
TCkKfQo8L1NUWUxFPgo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KIDxvOkRv
Y3VtZW50UHJvcGVydGllcz4KICA8bzpMYXN0QXV0aG9yPkt1cnQgQW5uZW48L286TGFzdEF1dGhv
cj4KICA8bzpSZXZpc2lvbj40PC9vOlJldmlzaW9uPgogIDxvOkNyZWF0ZWQ+MjAwNi0xMC0wMlQx
MzozOTowMFo8L286Q3JlYXRlZD4KICA8bzpMYXN0U2F2ZWQ+MjAwNi0xMC0wMlQxMzo0NDowMFo8
L286TGFzdFNhdmVkPgogIDxvOlBhZ2VzPjE8L286UGFnZXM+CiAgPG86V29yZHM+MTczPC9vOldv
cmRzPgogIDxvOkNoYXJhY3RlcnM+MTA5MDwvbzpDaGFyYWN0ZXJzPgogIDxvOkNvbXBhbnk+IDwv
bzpDb21wYW55PgogIDxvOkxpbmVzPjk8L286TGluZXM+CiAgPG86UGFyYWdyYXBocz4yPC9vOlBh
cmFncmFwaHM+CiAgPG86Q2hhcmFjdGVyc1dpdGhTcGFjZXM+MTI2MTwvbzpDaGFyYWN0ZXJzV2l0
aFNwYWNlcz4KICA8bzpWZXJzaW9uPjExLjU2MDY8L286VmVyc2lvbj4KIDwvbzpEb2N1bWVudFBy
b3BlcnRpZXM+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgogPHc6
V29yZERvY3VtZW50PgogIDx3OlZpZXc+Tm9ybWFsPC93OlZpZXc+CiAgPHc6U3BlbGxpbmdTdGF0
ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPgogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpHcmFt
bWFyU3RhdGU+CiAgPHc6SHlwaGVuYXRpb25ab25lPjIxPC93Okh5cGhlbmF0aW9uWm9uZT4KICA8
dzpQdW5jdHVhdGlvbktlcm5pbmcvPgogIDx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPgogIDx3
OlNhdmVJZlhNTEludmFsaWQ+ZmEKbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+CiAgPHc6SWdub3Jl
TWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4KICA8dzpBbHdheXNTaG93
UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+CiAgPHc6
RG9Ob3RTaGFkZUZvcm1EYXRhLz4KICA8dzpDb21wYXRpYmlsaXR5PgogICA8dzpCcmVha1dyYXBw
ZWRUYWJsZXMvPgogICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4KICAgPHc6V3JhcFRleHRXaXRoUHVu
Y3QvPgogICA8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPgogICA8dzpEb250R3Jvd0F1dG9maXQvPgog
IDwvdzpDb21wYXRpYmlsaXR5PgogIDx3OkJyb3dzZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4
cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+CiA8L3c6V29yZERvY3VtZW50Pgo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KIDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRT
dGF0ZT0iZmFsc2UiIExhdGVudFN0eWxlQ291bnQ9IjE1NiI+CiA8L3c6TGF0ZW50U3R5bGVzPgo8
L3htbD48IVtlbmRpZl0tLT4KPHN0eWxlPkBwYWdlIFNlY3Rpb24xIHtzaXplOiA2MTIuMHB0IDc5
Mi4wcHQ7IG1hcmdpbjogNzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7IG1zby1oZWFkZXIt
bWFyZ2luOiAzNi4wcHQ7IG1zby1mb290ZXItbWFyZ2luOiAzNi4wcHQ7IG1zby1wYXBlci1zb3Vy
Y2U6IDA7IH0KUC5Nc29Ob3JtYWwgewoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBjbSAwY20g
MHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IG1zby1zdHlsZS1wYXJlbnQ6ICIi
OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog
IlRpbWVzIE5ldyBSb21hbiIKfQpMSS5Nc29Ob3JtYWwgewoJRk9OVC1TSVpFOiAxMnB0OyBNQVJH
SU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IG1zby1zdHls
ZS1wYXJlbnQ6ICIiOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tZmFyZWFzdC1m
b250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiIKfQpESVYuTXNvTm9ybWFsIHsKCUZPTlQtU0la
RTogMTJwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t
YW4iOyBtc28tc3R5bGUtcGFyZW50OiAiIjsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsg
bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iCn0KQTpsaW5rIHsKCUNP
TE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgdGV4dC11bmRlcmxpbmU6IHNp
bmdsZQp9ClNQQU4uTXNvSHlwZXJsaW5rIHsKCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046
IHVuZGVybGluZTsgdGV4dC11bmRlcmxpbmU6IHNpbmdsZQp9CkE6dmlzaXRlZCB7CglDT0xPUjog
cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgdGV4dC11bmRlcmxpbmU6IHNpbmds
ZQp9ClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgewoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNP
UkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5lOiBzaW5nbGUKfQpQLk1zb0F1dG9TaWcg
ewoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRp
bWVzIE5ldyBSb21hbiI7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1mYXJlYXN0
LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIgp9CkxJLk1zb0F1dG9TaWcgewoJRk9OVC1T
SVpFOiAxMnB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBS
b21hbiI7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1mYXJlYXN0LWZvbnQtZmFt
aWx5OiAiVGltZXMgTmV3IFJvbWFuIgp9CkRJVi5Nc29BdXRvU2lnIHsKCUZPTlQtU0laRTogMTJw
dDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBt
c28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogIlRp
bWVzIE5ldyBSb21hbiIKfQpQIHsKCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBjbTsg
TUFSR0lOLVJJR0hUOiAwY207IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLXBh
Z2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1lcyBO
ZXcgUm9tYW4iOyBtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFs
dDogYXV0bwp9ClNQQU4uU3BlbGxFIHsKCW1zby1zdHlsZS1uYW1lOiAiIjsgbXNvLXNwbC1lOiB5
ZXMKfQpESVYuU2VjdGlvbjEgewoJcGFnZTogU2VjdGlvbjEKfQo8L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyAxMF0+CjxzdHlsZT4KIC8qIFN0eWxlIERlZmluaXRpb25zICovCiB0YWJsZS5Nc29Ob3Jt
YWxUYWJsZQoJe21zby1zdHlsZS1uYW1lOiJOb3JtYWxlIFRhYmVsbGUiOwoJbXNvLXRzdHlsZS1y
b3diYW5kLXNpemU6MDsKCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7Cgltc28tc3R5bGUtbm9z
aG93OnllczsKCW1zby1zdHlsZS1wYXJlbnQ6IiI7Cgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0
IDBjbSA1LjRwdDsKCW1zby1wYXJhLW1hcmdpbjowY207Cgltc28tcGFyYS1tYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7Cgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47Cglmb250LXNpemU6MTAuMHB0
OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Cgltc28tYW5zaS1sYW5ndWFnZTojMDQw
MDsKCW1zby1mYXJlYXN0LWxhbmd1YWdlOiMwNDAwOwoJbXNvLWJpZGktbGFuZ3VhZ2U6IzA0MDA7
fQo8L3N0eWxlPgo8IVtlbmRpZl0tLT4KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPgo8ZGl2IGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0Ij4KPGhyIHN0eWxlPSJ3aWR0aDogMTk1cHQ7IiBhbGln
bj0ibGVmdCIgY29sb3I9ImdyYXkiIG5vc2hhZGU9Im5vc2hhZGUiCiBzaXplPSIyIiB3aWR0aD0i
MjYwIj48L2Rpdj4KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgc3R5bGU9IndpZHRoOiAx
ODcuNXB0OyIgYm9yZGVyPSIwIgogY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIyNTAiPgogIDx0Ym9k
eT4KICAgIDx0ciBzdHlsZT0iIj4KICAgICAgPHRkIHN0eWxlPSJwYWRkaW5nOiAwLjc1cHQ7Ij4K
ICAgICAgPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFy
aWFsOyI+S3VydApBbm5lbjwvc3Bhbj48L2I+PGJyPgogICAgICA8c3BhbiBzdHlsZT0iZm9udC1z
aXplOiA3LjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyI+RGlwbG9tClZvbGtzd2lydCAoVW5pKTxi
cj4KICAgICAgPC9zcGFuPjxicj4KICAgICAgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg
Zm9udC1mYW1pbHk6IEFyaWFsOyI+SW0gSGFzcGVsZmVsZGUKMzxicj4KMzAxNzMgSGFubm92ZXI8
L3NwYW4+PC9wPgogICAgICA8L3RkPgogICAgPC90cj4KICA8L3Rib2R5Pgo8L3RhYmxlPgo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZGlzcGxheTogbm9uZTsiPjxvOnA+oDwvbzpw
Pjwvc3Bhbj48L3A+Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIHN0eWxlPSIiIGJvcmRl
cj0iMCIgY2VsbHBhZGRpbmc9IjAiCiBjZWxsc3BhY2luZz0iMCI+CiAgPHRib2R5PgogICAgPHRy
IHN0eWxlPSIiPgogICAgICA8dGQgc3R5bGU9InBhZGRpbmc6IDBjbTsiPgogICAgICA8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3Bhbgogc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6
IEFyaWFsOyI+UGhvbmWgoKCgPC9zcGFuPjwvcD4KICAgICAgPC90ZD4KICAgICAgPHRkIHN0eWxl
PSJwYWRkaW5nOiAwY207Ij4KICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4KIHN0eWxl
PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsiPis0OSAoMCkgNTExIC0gMzcw
NjY4MTk8L3NwYW4+PC9wPgogICAgICA8L3RkPgogICAgPC90cj4KICAgIDx0ciBzdHlsZT0iIj4K
ICAgICAgPHRkIHN0eWxlPSJwYWRkaW5nOiAwY207IiB2YWxpZ249InRvcCI+CiAgICAgIDxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuCiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls
eTogQXJpYWw7Ij5Nb2JpbGWgoKCgoDwvc3Bhbj48L3A+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCBz
dHlsZT0icGFkZGluZzogMGNtOyI+CiAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuCiBz
dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7Ij4rNDkgKDApIDE3OSAt
IDExNDkzNjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgIDwvdGQ+CiAgICA8L3RyPgogICAg
PHRyIHN0eWxlPSIiPgogICAgICA8dGQgc3R5bGU9InBhZGRpbmc6IDBjbTsiPgogICAgICA8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3Bhbgogc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p
bHk6IEFyaWFsOyI+RS1NYWlsoKCgoDwvc3Bhbj48L3A+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCBz
dHlsZT0icGFkZGluZzogMGNtOyI+CiAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuCiBz
dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7Ij48YQogaHJlZj0ibWFp
bHRvOmFubmVuQHdlYi1yZWcuZGUiPmFubmVuQHdlYi1yZWcuZGU8L2E+PC9zcGFuPjwvcD4KICAg
ICAgPC90ZD4KICAgIDwvdHI+CiAgICA8dHIgc3R5bGU9IiI+CiAgICAgIDx0ZCBzdHlsZT0icGFk
ZGluZzogMGNtOyI+CiAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuCiBzdHlsZT0iZm9u
dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7Ij5JbnRlcm5ldKCgPC9zcGFuPjwvcD4K
ICAgICAgPC90ZD4KICAgICAgPHRkIHN0eWxlPSJwYWRkaW5nOiAwY207Ij4KICAgICAgPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4KIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5
OiBBcmlhbDsiPjxhCiBocmVmPSJodHRwOi8vd3d3LndlYi1yZWcuZGUvIj5odHRwOi8vd3d3Lndl
Yi1yZWcuZGU8L2E+PC9zcGFuPiA8L3A+CiAgICAgIDwvdGQ+CiAgICA8L3RyPgogIDwvdGJvZHk+
CjwvdGFibGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBzdHlsZT0iIj4KPCEtLVtpZiAhc3Vw
cG9ydExpbmVCcmVha05ld0xpbmVdLS0+PGJyIHN0eWxlPSIiPgo8IS0tW2VuZGlmXS0tPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDcuNXB0OyBmb250LWZhbWlseTogQXJpYWw7Ij48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDcuNXB0OyBmb250LWZhbWlseTogQXJpYWw7Ij48bzpwPqA8L286cD48L3NwYW4+PC9wPgo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3LjVwdDsgZm9udC1mYW1p
bHk6IEFyaWFsOyIKIGxhbmc9IkVOLUdCIj5UaGlzIHRyYW5zbWlzc2lvbiBtYXkgY29udGFpbiBp
bmZvcm1hdGlvbiB0aGF0IGlzCnByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgbGVnYWxseSBwcml2
aWxlZ2VkLCBhbmQvb3IgZXhlbXB0IGZyb20KZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNhYmxlIGxh
dy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwKeW91IGFyZSBoZXJlYnkg
bm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uLCBvcgp1
c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gKGluY2x1ZGluZyBhbnkgcmVs
aWFuY2UKdGhlcmVvbikgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gQWx0aG91Z2ggdGhpcyB0cmFu
c21pc3Npb24gYW5kIGFueQphdHRhY2htZW50cyBhcmUgYmVsaWV2ZWQgdG8gYmUgZnJlZSBvZiBh
bnkgdmlydXMgb3Igb3RoZXIgZGVmZWN0IHRoYXQKbWlnaHQgYWZmZWN0IGFueSBjb21wdXRlciBz
eXN0ZW0gaW50byB3aGljaCBpdCBpcyByZWNlaXZlZCBhbmQgb3BlbmVkLAppdCBpcyB0aGUgcmVz
cG9uc2liaWxpdHkgb2YgdGhlIHJlY2lwaWVudCB0byBlbnN1cmUgdGhhdCBpdCBpcyB2aXJ1cwpm
cmVlIGFuZCBubyByZXNwb25zaWJpbGl0eSBpcyBhY2NlcHRlZCBieSBLdXJ0IEFubmVuLiwgaXRz
IHN1YnNpZGlhcmllcwphbmQgYWZmaWxpYXRlcywgYXMgYXBwbGljYWJsZSwgZm9yIGFueSBsb3Nz
IG9yIGRhbWFnZSBhcmlzaW5nIGluIGFueQp3YXkgZnJvbSBpdHMgdXNlLiBJZiB5b3UgcmVjZWl2
ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQppbW1lZGlhdGVseSBjb250YWN0
IHRoZSBzZW5kZXIgYW5kIGRlc3Ryb3kgdGhlIG1hdGVyaWFsIGluIGl0cwplbnRpcmV0eSwgd2hl
dGhlciBpbiBlbGVjdHJvbmljIG9yIGhhcmQgY29weSBmb3JtYXQuIDwvc3Bhbj48c3BhbgogY2xh
c3M9IlNwZWxsRSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGZvbnQtZmFtaWx5OiBB
cmlhbDsiPlRoYW5rPC9zcGFuPjwvc3Bhbj48c3Bhbgogc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7
IGZvbnQtZmFtaWx5OiBBcmlhbDsiPiA8c3BhbiBjbGFzcz0iU3BlbGxFIj55b3U8L3NwYW4+Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+oDwvcD4KPHAgY2xhc3M9
Ik1zb0F1dG9TaWciPjxvOnA+oDwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8L2JvZHk+CjwvaHRt
bD4K

--===============0620189698321775153==
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="annen.vcf"
MIME-Version: 1.0

YmVnaW46dmNhcmQKZm46S3VydCBBbm5lbgpuOkFubmVuO0t1cnQKYWRyOjs7SW0gSGFzcGVsZmVs
ZGUgMztIYW5ub3ZlcjtOaWVkZXJzYWNoc2VuOzMwMTczO0RldXRzY2hsYW5kCmVtYWlsO2ludGVy
bmV0OmFubmVuQHdlYi1yZWcuZGUKdGVsO2hvbWU6KzQ5IDUxMSAzNyAwNiA2OCAxOQp0ZWw7Y2Vs
bDorNDkgMTc5IDExIDQ5IDM2OQp2ZXJzaW9uOjIuMQplbmQ6dmNhcmQKCg==

--===============0620189698321775153==--


From G.A.Hughes@ed.ac.uk Sat Dec 26 14:41:03 2009
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Sat, 26 Dec 2009 19:41:23 +0000
Message-ID: <E1NOcVX-0007JS-Ic@relay05.mail.eu.clara.net>
In-Reply-To: mailman.9.1261846802.13388.gretl-devel@lists.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8007302358100447374=="

--===============8007302358100447374==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I have a spare Ubuntu machine (not very fast - dual core 1.66 Ghz) 
that I can leave running on its own for 24 hours or longer without 
any problem - I use it for Monte Carlo runs under Stata.  However, I 
simply don't have enough familiarity with either shell scripts or C 
compilation to convert your instructions into a functioning 
program.  If you could give somewhat more detailed instructions, I 
would be happy to run the test program to the end.

Gordon


>As I mentioned, I ran the Crush suite on gretl without any
>failures.  I've now run most of Big Crush.  I had to unplug my
>laptop after about 14 hours, and got through 80 out of 106 tests,
>again with no failures.  The completed tests include all of the
>"collisions" variants, on which Doornik said that standard
>ziggurat failed.  Obviously, though, it would be nice to run the
>whole thing, which would require about 16 hours on my machine.
>
>I'm attaching the source for the test program I used. I built the
>program with:
>
>CC = gcc -Wall -O2
>CFLAGS = `pkg-config --cflags glib-2.0 gretl`
>LIBS = `pkg-config --libs glib-2.0 gretl`
>
>glibtest: glib.c
>         $(CC) $(CFLAGS) -o $@ $< -ltestu01 $(LIBS)
>
>Allin.


--===============8007302358100447374==--


From svetosch@gmx.net Sun Dec 27 06:29:55 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] code fragments
Date: Sun, 27 Dec 2009 12:29:33 +0100
Message-ID: <4B37451D.4020305@gmx.net>
In-Reply-To: 4B361279.9080404@web-reg.de
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3954917137994076824=="

--===============3954917137994076824==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Kurt,

gretl already has the capability of opening eviews (and of course
spreadsheet) files. A converter from eviews to excel surely is a useful
thing, too, but not directly related to gretl AFAICS. Or am I missing
something?

thanks,
sven

Kurt Annen schrieb:
> hi,
> 
> i wrote an eviews to xls importer in ansi c one year ago. since i have
> no time to add the code into gretl, i woold give someone this code to
> add it in gretl.
> 
> 
> -- 
> ------------------------------------------------------------------------
> 
> *Kurt Annen*
> Diplom Volkswirt (Uni)
> 
> Im Haspelfelde 3
> 30173 Hannover
> 
>  
> 
> Phone    
> 
> 	
> 
> +49 (0) 511 - 37066819
> 
> Mobile     
> 
> 	
> 
> +49 (0) 179 - 1149369
> 
> E-Mail    
> 
> 	
> 
> annen(a)web-reg.de <mailto:annen(a)web-reg.de>
> 
> Internet  
> 
> 	
> 
> http://www.web-reg.de <http://www.web-reg.de/>
> 
> 
> 
>  
> 
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance thereon) is
> STRICTLY PROHIBITED. Although this transmission and any attachments are
> believed to be free of any virus or other defect that might affect any
> computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no
> responsibility is accepted by Kurt Annen., its subsidiaries and
> affiliates, as applicable, for any loss or damage arising in any way
> from its use. If you received this transmission in error, please
> immediately contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
> 
>  
> 
>  
> 
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel


--===============3954917137994076824==--


From svetosch@gmx.net Sun Dec 27 11:01:29 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Sun, 27 Dec 2009 17:01:05 +0100
Message-ID: <4B3784C1.5000204@gmx.net>
In-Reply-To: E1NOcVX-0007JS-Ic@relay05.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3379425835407973878=="

--===============3379425835407973878==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

*) build and install the test suite (./configure, make, install)
http://www.iro.umontreal.ca/~simardr/testu01/install.html

*) set paths (<install directory> likely is /usr/local, and maybe this
isn't necessary...?)

export LD_LIBRARY_PATH=<install directory>/lib:${LD_LIBRARY_PATH}
export LIBRARY_PATH=<install directory>/lib:${LIBRARY_PATH}
export C_INCLUDE_PATH=<install directory>/include:${C_INCLUDE_PATH}

*) copy Allin's instructions into a text file called "Makefile"

*) copy Allin's .c file side by side with the Makefile

*) in this directory, type 'make' in a shell -- you should get an
executable file 'glibtest'

However, when I run './glibtest' (glibtest built without error) I get
the error:
./glibtest: error while loading shared libraries: libtestu01.so.0:
cannot open shared object file: No such file or directory

...even though I had previously installed testu01??

BTW, I'm not an expert but it seems to me that it would be a waste if we
all run this in parallel on the same platform (Linux on Core2Duo). If
any parallel effort is done, it may be more useful to do it on various
platforms and/or hardware, like Mac, or AMD, or whatever.

thanks,
sven

Gordon Hughes schrieb:
> I have a spare Ubuntu machine (not very fast - dual core 1.66 Ghz) 
> that I can leave running on its own for 24 hours or longer without 
> any problem - I use it for Monte Carlo runs under Stata.  However, I 
> simply don't have enough familiarity with either shell scripts or C 
> compilation to convert your instructions into a functioning 
> program.  If you could give somewhat more detailed instructions, I 
> would be happy to run the test program to the end.
> 
> Gordon
> 
> 
>> As I mentioned, I ran the Crush suite on gretl without any
>> failures.  I've now run most of Big Crush.  I had to unplug my
>> laptop after about 14 hours, and got through 80 out of 106 tests,
>> again with no failures.  The completed tests include all of the
>> "collisions" variants, on which Doornik said that standard
>> ziggurat failed.  Obviously, though, it would be nice to run the
>> whole thing, which would require about 16 hours on my machine.
>>
>> I'm attaching the source for the test program I used. I built the
>> program with:
>>
>> CC = gcc -Wall -O2
>> CFLAGS = `pkg-config --cflags glib-2.0 gretl`
>> LIBS = `pkg-config --libs glib-2.0 gretl`
>>
>> glibtest: glib.c
>>         $(CC) $(CFLAGS) -o $@ $< -ltestu01 $(LIBS)
>>
>> Allin.
> 
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
> 


--===============3379425835407973878==--


From henrique.coelho@gmail.com Sun Dec 27 12:05:09 2009
From: Henrique <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Sun, 27 Dec 2009 14:04:46 -0300
Message-ID: <b3173c600912270904p7af38d59q60ab1d42d72037cf@mail.gmail.com>
In-Reply-To: 4B3784C1.5000204@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0859155478034320994=="

--===============0859155478034320994==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Em 27 de dezembro de 2009 Sven escreveu:

> BTW, I'm not an expert but it seems to me that it would be a waste if we
> all run this in parallel on the same platform (Linux on Core2Duo). If
> any parallel effort is done, it may be more useful to do it on various
> platforms and/or hardware, like Mac, or AMD, or whatever.

I'm a Mac user (Core2Duo, 2.2 GHz, 4 GB RAM) and I would like to help
but, unfortunately, I don't have enough
programming knowledge.

Best,
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge

--===============0859155478034320994==--


From G.A.Hughes@ed.ac.uk Sun Dec 27 14:36:49 2009
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed (Sven Schreiber)
Date: Sun, 27 Dec 2009 19:34:37 +0000
Message-ID: <E1NOyuz-0005MM-1h@relay00.mail.eu.clara.net>
In-Reply-To: mailman.7.1261933201.23435.gretl-devel@lists.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6641824807546417335=="

--===============6641824807546417335==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

OK, thank you for the help.  Following your instructions, I have 
generated a working version of glibtest which is able to resolve the 
libraries, so I am not sure why your version failed to find them.

I will leave glibtest running for as long as necessary to complete 
and report the results in due course.

On your last point, the testu01 instructions say that the program 
will run under Windows or Linux but makes no reference to OS-X.  Even 
under Windows it relies upon an emulation layer (Cygwin or 
equivalent), so I am not sure how much one would learn about the 
Windows behaviour of the programs rather than about the Linux 
emulation.  I will leave that to someone else.  What I can do is run 
testu01 in a Linux virtual machine on a Mac if anyone thinks that 
this would be useful.

Gordon


>*) build and install the test suite (./configure, make, install)
>http://www.iro.umontreal.ca/~simardr/testu01/install.html
>
>*) set paths (<install directory> likely is /usr/local, and maybe this
>isn't necessary...?)
>
>export LD_LIBRARY_PATH=<install directory>/lib:${LD_LIBRARY_PATH}
>export LIBRARY_PATH=<install directory>/lib:${LIBRARY_PATH}
>export C_INCLUDE_PATH=<install directory>/include:${C_INCLUDE_PATH}
>
>*) copy Allin's instructions into a text file called "Makefile"
>
>*) copy Allin's .c file side by side with the Makefile
>
>*) in this directory, type 'make' in a shell -- you should get an
>executable file 'glibtest'
>
>However, when I run './glibtest' (glibtest built without error) I get
>the error:
>./glibtest: error while loading shared libraries: libtestu01.so.0:
>cannot open shared object file: No such file or directory
>
>...even though I had previously installed testu01??
>
>BTW, I'm not an expert but it seems to me that it would be a waste if we
>all run this in parallel on the same platform (Linux on Core2Duo). If
>any parallel effort is done, it may be more useful to do it on various
>platforms and/or hardware, like Mac, or AMD, or whatever.
>
>thanks,
>sven


--===============6641824807546417335==--


From svetosch@gmx.net Sun Dec 27 15:11:05 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed (Sven Schreiber)
Date: Sun, 27 Dec 2009 21:10:41 +0100
Message-ID: <4B37BF41.3090905@gmx.net>
In-Reply-To: E1NOyuz-0005MM-1h@relay00.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3270199623159127345=="

--===============3270199623159127345==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Gordon Hughes schrieb:

> 
> I will leave glibtest running for as long as necessary to complete 
> and report the results in due course.

ok great.

> 
> On your last point, the testu01 instructions say that the program 
> will run under Windows or Linux but makes no reference to OS-X.  Even 
> under Windows it relies upon an emulation layer (Cygwin or 
> equivalent), so I am not sure how much one would learn about the 
> Windows behaviour of the programs rather than about the Linux 
> emulation.  I will leave that to someone else.  What I can do is run 
> testu01 in a Linux virtual machine on a Mac if anyone thinks that 
> this would be useful.
> 

Note I'm *not* claiming that it should be done on several platforms. I
simply don't know if that's useful in the sense that I don't know if the
test is theoretically platform-dependent. All I'm saying is that I'm
pretty sure it's *not* very useful if the test is replicated on more or
less identical setups.

Having said that, I would normally expect the unixy OS X to be
manageable if the source code for a posix-type system exists (as it does
here). But let's just wait for your results and not get into a "big
crushing" frenzy.

thanks,
sven

--===============3270199623159127345==--


From cottrell@wfu.edu Mon Dec 28 10:32:30 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Mon, 28 Dec 2009 10:32:29 -0500
Message-ID: <Pine.A41.4.58.0912280956080.2064560@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B3784C1.5000204@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5258005667719494718=="

--===============5258005667719494718==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Sun, 27 Dec 2009, Sven Schreiber wrote in

http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002356.html

> *) build and install the test suite (./configure, make, install)
> http://www.iro.umontreal.ca/~simardr/testu01/install.html

[etc.]

These instructions are perfectly correct.

> However, when I run './glibtest' (glibtest built without error) I get
> the error:
> ./glibtest: error while loading shared libraries: libtestu01.so.0:
> cannot open shared object file: No such file or directory

sudo ldconfig

However, people might hold off for a bit with the crush tests.  I
think I now see what's going on.  I'm no expert on RNGs, but here
goes...

1) The main speed advantage from ziggurat is that (in the original
Marsaglia/Tsang version) it requires the generation of only one
random 32-bit integer per normal sample, where Box-Muller requires
two.

2) However, Doornik points out that there's a problem with this,
which emerges if you want to generate normally distributed
"doubles" (64-bit floating point values -- the original ziggurat
generated 32-bit "floats").  The trouble is that if you use just
one set of 32 bits to select the ziggurat box or level and for the
uniform value to be tested for acceptance at that level, you get a
certain sort of subtle dependence, and the symptom is that the
normal RNG fails Knuth's collisions test (on the regular crush
suite as well as big crush).

3) I took Jochen Voss's ziggurat code and adapted it for gretl,
and it passed all the tests.  So at first I thought we'd somehow
got around Doornik's problem (maybe by using a better RNG for the
initial uniform input).

4) But then I took a closer look at the Voss code, and I see that
it dodges the dependence problem by a means that Doornik mentions
but does not recommend.  Namely, from the initial 32-bit input it
uses:

7 bits for the ziggurat level
1 bit for the sign
24 bits for the value to be tested

There's no dependence problem because Voss uses non-overlapping
bits for the box selector and the test value (and so one can quite
confidently predict that this generator will pass the collisions
test), but the drawback is that one can then generate "only" about
30 million distinct normal values.

5) To get better coverage of the real line one can use one and a
quarter random ints per normal draw.  For example, one can use 7
bits for selecting a box, one for the sign, and 30 for the test
value, to get about 10^9 distinct normal values (with 2 bits of
"wastage").

I've now implemented this in gretl and I'm running the crush suite
right now.  If it passes (in principle it should, but I might have
screwed something up in regard to the quarter-ints), I'll commit
it to CVS and then people can try attacking it with big crush.

Allin.


--===============5258005667719494718==--


From cottrell@wfu.edu Mon Dec 28 12:47:15 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Mon, 28 Dec 2009 12:47:14 -0500
Message-ID: <Pine.A41.4.58.0912281245300.2064560@f1n11.sp2net.wfu.edu>
In-Reply-To: Pine.A41.4.58.0912280956080.2064560@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6619187250019660156=="

--===============6619187250019660156==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Mon, 28 Dec 2009, Allin Cottrell wrote:

> I've now implemented [a ziggurat that covers the real line
> better] in gretl and I'm running the crush suite right now.  If
> it passes ... I'll commit it to CVS and then people can try
> attacking it with big crush.

It passed crush, and it's in CVS.

Allin.

--===============6619187250019660156==--


From svetosch@gmx.net Tue Dec 29 06:11:03 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] simulation speed
Date: Tue, 29 Dec 2009 12:10:39 +0100
Message-ID: <4B39E3AF.8050605@gmx.net>
In-Reply-To: Pine.A41.4.58.0912281245300.2064560@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9171905087601425449=="

--===============9171905087601425449==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Mon, 28 Dec 2009, Allin Cottrell wrote:
> 
>> I've now implemented [a ziggurat that covers the real line
>> better] in gretl and I'm running the crush suite right now.  If
>> it passes ... I'll commit it to CVS and then people can try
>> attacking it with big crush.
> 
> It passed crush, and it's in CVS.
> 

old result gretl 1.8.6cvs:
loop ca. 2.6 seconds
vectorized ca. 2.0 seconds

new result gretl 1.8.6cvs w/ modified ziggurat:
loop ca. 1.6 seconds
vectorized ca. 0.8 seconds

(of course the precision of the timing decreases the less time it takes)

I think this is a remarkable change. The vectorized speed is now on par
with Ox (the above results weren't for gretlcli). What's more (assuming
that the new method also passes Big Crush), the process of Allin
incorporating the ziggurat method was lightning-fast -- Alan Isaac, if
you're still on the NumPy list maybe Allin's implementation could be
interesting for them.

cheers,
sven

--===============9171905087601425449==--


From G.A.Hughes@ed.ac.uk Tue Dec 29 08:45:09 2009
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 13:44:50 +0000
Message-ID: <E1NPcNi-00037q-Kn@relay06.mail.eu.clara.net>
In-Reply-To: mailman.9.1262019602.1350.gretl-devel@lists.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1382306701216906322=="

--===============1382306701216906322==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I did not receive this message until the Big Crush test was well 
advanced, so I let it finish.

It took almost 30 hours to run on the system that I described and 
reported that all of the tests were passed.  I will rerun the test on 
the new CVS version when you are satisfied with it.

Gordon


>However, people might hold off for a bit with the crush tests.  I
>think I now see what's going on.  I'm no expert on RNGs, but here
>goes...
>
>1) The main speed advantage from ziggurat is that (in the original
>Marsaglia/Tsang version) it requires the generation of only one
>random 32-bit integer per normal sample, where Box-Muller requires
>two.
>
>2) However, Doornik points out that there's a problem with this,
>which emerges if you want to generate normally distributed
>"doubles" (64-bit floating point values -- the original ziggurat
>generated 32-bit "floats").  The trouble is that if you use just
>one set of 32 bits to select the ziggurat box or level and for the
>uniform value to be tested for acceptance at that level, you get a
>certain sort of subtle dependence, and the symptom is that the
>normal RNG fails Knuth's collisions test (on the regular crush
>suite as well as big crush).
>
>3) I took Jochen Voss's ziggurat code and adapted it for gretl,
>and it passed all the tests.  So at first I thought we'd somehow
>got around Doornik's problem (maybe by using a better RNG for the
>initial uniform input).
>
>4) But then I took a closer look at the Voss code, and I see that
>it dodges the dependence problem by a means that Doornik mentions
>but does not recommend.  Namely, from the initial 32-bit input it
>uses:
>
>7 bits for the ziggurat level
>1 bit for the sign
>24 bits for the value to be tested
>
>There's no dependence problem because Voss uses non-overlapping
>bits for the box selector and the test value (and so one can quite
>confidently predict that this generator will pass the collisions
>test), but the drawback is that one can then generate "only" about
>30 million distinct normal values.
>
>5) To get better coverage of the real line one can use one and a
>quarter random ints per normal draw.  For example, one can use 7
>bits for selecting a box, one for the sign, and 30 for the test
>value, to get about 10^9 distinct normal values (with 2 bits of
>"wastage").
>
>I've now implemented this in gretl and I'm running the crush suite
>right now.  If it passes (in principle it should, but I might have
>screwed something up in regard to the quarter-ints), I'll commit
>it to CVS and then people can try attacking it with big crush.
>
>Allin.
>
>
>
>------------------------------
>
>_______________________________________________
>Gretl-devel mailing list
>Gretl-devel(a)lists.wfu.edu
>http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
>End of Gretl-devel Digest, Vol 35, Issue 23
>*******************************************


--===============1382306701216906322==--


From cottrell@wfu.edu Tue Dec 29 10:03:14 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 10:03:13 -0500
Message-ID: <Pine.A41.4.58.0912290954310.2736354@f1n11.sp2net.wfu.edu>
In-Reply-To: E1NPcNi-00037q-Kn@relay06.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3552414386486275023=="

--===============3552414386486275023==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 29 Dec 2009, Gordon Hughes wrote:

> I did not receive this message until the Big Crush test was well
> advanced, so I let it finish.
>
> It took almost 30 hours to run on the system that I described and
> reported that all of the tests were passed.  I will rerun the test on
> the new CVS version when you are satisfied with it.

Thanks, Gordon.  There's now a revised test program plus Makefile
at http://www.wfu.edu/~cottrell/gretlrand/

And I've just committed some changes to CVS (these shouldn't
affect the properties of the RNG, but better to ensure you're
using the latest).  For now, I've made the ziggurat the default
normal RNG but have added a "set" switch to get the old behavior:

set normal_rand box-muller

This may be useful for regression testing: if you have old scripts
with user-supplied random seeds, then the command above should
give you the same random values that were generated previously.

One more thing: I've run "crush" on two more systems: a Pentium D
machine running Ubuntu and an iMac running OS X 10.4.  All tests
were passed.

Allin Cottrell


--===============3552414386486275023==--


From cottrell@wfu.edu Tue Dec 29 10:06:51 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 10:06:50 -0500
Message-ID: <Pine.A41.4.58.0912291006050.2736354@f1n11.sp2net.wfu.edu>
In-Reply-To: Pine.A41.4.58.0912290954310.2736354@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5690944050820988456=="

--===============5690944050820988456==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Tue, 29 Dec 2009, Allin Cottrell wrote:

> One more thing: I've run "crush" on two more systems: a Pentium D
> machine running Ubuntu and an iMac running OS X 10.4.  All tests
> were passed.

It would be nice if someone could test on a 64-bit system.

Allin

--===============5690944050820988456==--


From svetosch@gmx.net Tue Dec 29 10:25:11 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 16:24:36 +0100
Message-ID: <4B3A1F34.4030902@gmx.net>
In-Reply-To: Pine.A41.4.58.0912291006050.2736354@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1569197023903937452=="

--===============1569197023903937452==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Tue, 29 Dec 2009, Allin Cottrell wrote:
> 
>> One more thing: I've run "crush" on two more systems: a Pentium D
>> machine running Ubuntu and an iMac running OS X 10.4.  All tests
>> were passed.
> 
> It would be nice if someone could test on a 64-bit system.
> 

Does Mac OS 10.6 (Snow Leopard) qualify? If so, I guess I could do it.

-sven

--===============1569197023903937452==--


From bhh@xs4all.nl Tue Dec 29 10:59:20 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 16:59:17 +0100
Message-ID: <DDB36EFD-84D1-417C-AE90-5756CE934182@xs4all.nl>
In-Reply-To: 4B3A1F34.4030902@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2599262526643149482=="

--===============2599262526643149482==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On 29-12-2009, at 16:24, Sven Schreiber wrote:

> Allin Cottrell schrieb:
>> On Tue, 29 Dec 2009, Allin Cottrell wrote:
>> 
>>> One more thing: I've run "crush" on two more systems: a Pentium D
>>> machine running Ubuntu and an iMac running OS X 10.4.  All tests
>>> were passed.
>> 
>> It would be nice if someone could test on a 64-bit system.
>> 
> 
> Does Mac OS 10.6 (Snow Leopard) qualify? If so, I guess I could do it.
> 

In theory it should be possible.
However the GTK framework is 32-bit.
In order to make a 64-bit executable all libraries used must be 64-bit.

Berend

--===============2599262526643149482==--


From svetosch@gmx.net Tue Dec 29 11:16:11 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 17:15:51 +0100
Message-ID: <4B3A2B37.8030805@gmx.net>
In-Reply-To: DDB36EFD-84D1-417C-AE90-5756CE934182@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4673643237789271252=="

--===============4673643237789271252==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Berend Hasselman schrieb:
> On 29-12-2009, at 16:24, Sven Schreiber wrote:
> 
>> Allin Cottrell schrieb:
>>> On Tue, 29 Dec 2009, Allin Cottrell wrote:
>>>
>>>> One more thing: I've run "crush" on two more systems: a Pentium D
>>>> machine running Ubuntu and an iMac running OS X 10.4.  All tests
>>>> were passed.
>>> It would be nice if someone could test on a 64-bit system.
>>>
>> Does Mac OS 10.6 (Snow Leopard) qualify? If so, I guess I could do it.
>>
> 
> In theory it should be possible.
> However the GTK framework is 32-bit.
> In order to make a 64-bit executable all libraries used must be 64-bit.
> 

hm, ok. so maybe it's easier to just download a 64bit Virtual Ubuntu
machine and run the test on the VM?

-sven

--===============4673643237789271252==--


From bhh@xs4all.nl Tue Dec 29 12:01:51 2009
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Tue, 29 Dec 2009 18:01:48 +0100
Message-ID: <A30C99DF-6321-4B03-B83C-19E7034B0F47@xs4all.nl>
In-Reply-To: 4B3A2B37.8030805@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4688674170177310731=="

--===============4688674170177310731==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On 29-12-2009, at 17:15, Sven Schreiber wrote:

>> 
>> In theory it should be possible.
>> However the GTK framework is 32-bit.
>> In order to make a 64-bit executable all libraries used must be 64-bit.
>> 
> 
> hm, ok. so maybe it's easier to just download a 64bit Virtual Ubuntu
> machine and run the test on the VM?
> 

Probably. But your VM environment would have to support 64-bits.
VirtualBox seems able to do that. I have no idea if it would work.
I've neven thought of trying.

Berend

--===============4688674170177310731==--


From svetosch@gmx.net Wed Dec 30 17:59:28 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Wed, 30 Dec 2009 23:59:07 +0100
Message-ID: <4B3BDB3B.9030800@gmx.net>
In-Reply-To: A30C99DF-6321-4B03-B83C-19E7034B0F47@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3013651126878990070=="

--===============3013651126878990070==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Berend Hasselman schrieb:
> On 29-12-2009, at 17:15, Sven Schreiber wrote:
> 
>>> In theory it should be possible.
>>> However the GTK framework is 32-bit.
>>> In order to make a 64-bit executable all libraries used must be 64-bit.
>>>
>> hm, ok. so maybe it's easier to just download a 64bit Virtual Ubuntu
>> machine and run the test on the VM?
>>
> 
> Probably. But your VM environment would have to support 64-bits.
> VirtualBox seems able to do that. I have no idea if it would work.
> I've neven thought of trying.
> 
>

Big Crush w/ libgretl is now running here on 64bit Ubuntu inside
VirtualBox (host is a Mac Mini with Core2Duo and OS X 10.6). Let's see
what happens but probably not this year anymore (GMT+1) ...

cheers,
sven

--===============3013651126878990070==--


From cottrell@wfu.edu Wed Dec 30 19:15:37 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Wed, 30 Dec 2009 19:15:37 -0500
Message-ID: <Pine.A41.4.58.0912301913490.2744610@f1n11.sp2net.wfu.edu>
In-Reply-To: 4B3BDB3B.9030800@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4758528293148462719=="

--===============4758528293148462719==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Wed, 30 Dec 2009, Sven Schreiber wrote:

> Berend Hasselman schrieb:
> > On 29-12-2009, at 17:15, Sven Schreiber wrote:
> >
> >>> In theory it should be possible.
> >>> However the GTK framework is 32-bit.
> >>> In order to make a 64-bit executable all libraries used must be 64-bit.
> >>>
> >> hm, ok. so maybe it's easier to just download a 64bit Virtual Ubuntu
> >> machine and run the test on the VM?
> >
> > Probably. But your VM environment would have to support 64-bits.
> > VirtualBox seems able to do that. I have no idea if it would work.
> > I've neven thought of trying.
>
> Big Crush w/ libgretl is now running here on 64bit Ubuntu inside
> VirtualBox (host is a Mac Mini with Core2Duo and OS X 10.6). Let's see
> what happens but probably not this year anymore (GMT+1) ...

Great way to see in the New Year!  Thanks, Sven.

Allin.

--===============4758528293148462719==--


From G.A.Hughes@ed.ac.uk Thu Dec 31 03:27:44 2009
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Subject: Re:  simulation speed
Date: Thu, 31 Dec 2009 08:27:19 +0000
Message-ID: <E1NQGNe-0002oV-1y@relay00.mail.eu.clara.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4662963355933397068=="

--===============4662963355933397068==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

A word of warning about running the BigCrush test.  Looking through 
the results of the first run I noticed that some of the tests 
generate test statistics that would reject the relevant hypothesis at 
the 1% confidence level, even though all of the tests were reported 
as having passed (since the criterion is p in the range 
[0.001,0.999]).  Since we are dealing with a random number generator 
it is possible that one run may lead to no failures but another may 
generate a number of failures.

Hence I ran the same test a second time.  The execution times were 
very similar (29h 40m vs 29h 41m).  The second run reported a single 
failure - Test 89 PeriodsInStrings , r = 20 with a p-value of 
6.4e-4.  Hence, one should really run these tests several times to 
get a proper assessment of the frequency of failures - a bit tedious 
given the amount of time required but essential.  Further, 
comparisons across operating systems or hardware shouldn't be based 
on a single run only.

I am now running the revised version of glibtest with the Dec 29th 
version of glib.c and will report the results when they 
finish.  However, I have one initial observation.  Sven reported that 
the updated version of the ziggurat executes substantially faster 
than the earlier version.  The early tests in the BigCrush suite give 
a different picture - the execution times are all slightly longer 
using the new gretl_one_snormal than using the previous 
ran_normal_ziggurat.  Is this a consequence of the change needed to 
use one and a quarter random ints per normal draw, since the previous 
code in ran_normal_ziggurat seems to correspond to the Voss 
procedure?  As a rough guess the increase in execution time is of the 
order of 5-10%.

Gordon


--===============4662963355933397068==--


From svetosch@gmx.net Thu Dec 31 06:59:44 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Thu, 31 Dec 2009 12:59:11 +0100
Message-ID: <4B3C920F.2070705@gmx.net>
In-Reply-To: E1NQGNe-0002oV-1y@relay00.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2939785092049888007=="

--===============2939785092049888007==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Gordon Hughes schrieb:

> finish.  However, I have one initial observation.  Sven reported that 
> the updated version of the ziggurat executes substantially faster 
> than the earlier version.  

Sorry that's not what I had meant. I was comparing the modified ziggurat
with the algorithm that was in gretl before this whole discussion
started. According to the Doornik paper a slight slowdown of the
modified ziggurat with respect to the plain ziggurat is expected I think.

cheers,
sven


--===============2939785092049888007==--


From svetosch@gmx.net Thu Dec 31 07:05:43 2009
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Thu, 31 Dec 2009 13:05:24 +0100
Message-ID: <4B3C9384.5050706@gmx.net>
In-Reply-To: Pine.A41.4.58.0912301913490.2744610@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4660428975890821876=="

--===============4660428975890821876==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> On Wed, 30 Dec 2009, Sven Schreiber wrote:
> 
>> Berend Hasselman schrieb:
>>> On 29-12-2009, at 17:15, Sven Schreiber wrote:
>>>
>>>>> In theory it should be possible.
>>>>> However the GTK framework is 32-bit.
>>>>> In order to make a 64-bit executable all libraries used must be 64-bit.
>>>>>
>>>> hm, ok. so maybe it's easier to just download a 64bit Virtual Ubuntu
>>>> machine and run the test on the VM?
>>> Probably. But your VM environment would have to support 64-bits.
>>> VirtualBox seems able to do that. I have no idea if it would work.
>>> I've neven thought of trying.
>> Big Crush w/ libgretl is now running here on 64bit Ubuntu inside
>> VirtualBox (host is a Mac Mini with Core2Duo and OS X 10.6). Let's see
>> what happens but probably not this year anymore (GMT+1) ...
> 
> Great way to see in the New Year!  Thanks, Sven.
> 

Hm, sorry to say that the memory requirements of glibtest exceed the
capacity of that computer. The VM was quickly starting to be swapping as
hell, almost using no CPU anymore, just waiting for the hard disk. I was
planning to upgrade the Ram anyway, but with the Mac Mini it's a bit
tricky, so it'll have to wait a bit.

Next week I can transfer the Ubuntu 64bit VM on my office computer and
let it run there.

happy new year's eve,

sven

--===============4660428975890821876==--


From cottrell@wfu.edu Thu Dec 31 08:19:06 2009
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Subject: Re:  simulation speed
Date: Thu, 31 Dec 2009 08:19:05 -0500
Message-ID: <Pine.A41.4.58.0912310806130.2662876@f1n11.sp2net.wfu.edu>
In-Reply-To: E1NQGNe-0002oV-1y@relay00.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3477611196123447623=="

--===============3477611196123447623==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


On Thu, 31 Dec 2009, Gordon Hughes wrote:

> A word of warning about running the BigCrush test.  Looking through
> the results of the first run I noticed that some of the tests
> generate test statistics that would reject the relevant hypothesis at
> the 1% confidence level, even though all of the tests were reported
> as having passed (since the criterion is p in the range
> [0.001,0.999]).  Since we are dealing with a random number generator
> it is possible that one run may lead to no failures but another may
> generate a number of failures.

If all is well, one expects to see p-values randomly distributed
on (0, 1): if you didn't get some values < .01 on a large set of
tests that would itself be suspicious.

It would require a modified test program, but in case one gets
p-values that look "too small" on some tests, it's possible to
rerun those tests in particular rather than redoing the whole
thing.

> Hence I ran the same test a second time.  The execution times were
> very similar (29h 40m vs 29h 41m).  The second run reported a single
> failure - Test 89 PeriodsInStrings , r = 20 with a p-value of
> 6.4e-4.

Personally I wouldn't be too worried about that -- it looks
within the bounds of what you might expect.  P-values of less
than, say, 10^{-6} would be problematic.  The failures that
Doornik talks about are values < 10^{-300} and I've seen nothing
like that with our code.

> Sven reported that the updated version of the ziggurat executes
> substantially faster than the earlier version.  The early tests
> in the BigCrush suite give a different picture - the execution
> times are all slightly longer using the new gretl_one_snormal
> than using the previous ran_normal_ziggurat.

As Sven said later, this is expected.  The new code is
substantially faster than what we had before we started down the
Ziggurat road; but it's necessarily a little slower than the Voss
code, which uses 24-bit values.

Allin.

--===============3477611196123447623==--