From cottrell@wfu.edu Sun Apr  4 19:42:04 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] "break" bug fixed
Date: Sun, 04 Apr 2010 19:42:03 -0400
Message-ID: <Pine.A41.4.58.1004041929260.2920566@f1n11.sp2net.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6065943693868760509=="

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


I'm embarrassed to say that there has been a bug in the "break"
command (for loops) since it was introduced, probably.

Up till now, the effect of "break" has been to invalidate the loop
continuation condition. The loop would not proceed to the next
iteration -- but it would, however, continue to the end of the
current iteration. The new behavior, which I'm sure is what users
would expect, is that the thread of execution of the current loop
breaks immediately after the "break" command.

Simple test case:

<script>
loop 100
  print "One"
  break
  print "Two"
endloop
</script>

Up till now you'd see "One" and "Two" printed once; now you see
just "One". I hope this hasn't caused anyone grief in writing
complex scripts.

Allin

--===============6065943693868760509==--


From henrique.coelho@gmail.com Thu Apr  8 14:41:10 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] VAR Results Tabulation
Date: Thu, 08 Apr 2010 15:40:47 -0300
Message-ID: <h2ub3173c601004081140laddb7ae6q429a44458108090f@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============0373487859794567356=="

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

RGVhciBHcmV0bCBkZXZlbG9wZXJzLDxicj48YnI+SSYjMzk7ZCBvYnNlcnZlZCBhbiBvZGQgdGFi
dWxhdGlvbiBvZiB0aGUgRi10ZXN0cyBpbiB0aGUgVkFSIGVzdGltYXRpb25zIHJlc3VsdHMgd2hl
biBJIHVzZSBHcmV0bCBpbiBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLiBQbGVhc2UgdGFr
ZSBhIGxvb2sgYXQgdGhlIHNjcmlwdDo8YnI+PGJyPiZsdDtzY3JpcHQmZ3Q7PGJyPm9wZW4gYXVz
dHJhbGlhLmdkdDxicj4KCnZhciA0IGxwdXMgbGUgbHBhdSAtLXJvYnVzdDxicj4mbHQ7L3Njcmlw
dCZndDs8YnI+PGJyPlRoZSByZXN1bHRzIGluIHRoZSBFbmdsaXNoIHZlcnNpb24gYXJlOjxicj48
YnI+PGZvbnQgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBjb3VyaWVyIG5ldyxt
b25vc3BhY2U7Ij5GLXRlc3RzIG9mIHplcm8gcmVzdHJpY3Rpb25zOjwvc3Bhbj48YnIgc3R5bGU9
ImZvbnQtZmFtaWx5OiBjb3VyaWVyIG5ldyxtb25vc3BhY2U7Ij4KCjxiciBzdHlsZT0iZm9udC1m
YW1pbHk6IGNvdXJpZXIgbmV3LG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog
Y291cmllciBuZXcsbW9ub3NwYWNlOyI+QWxsIGxhZ3Mgb2YgbHB1c6CgoKCgoKCgoKCgoKCgoCBG
KDQsIDYwKSA9oKAgNzYwLjUzIFswLjAwMDBdPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6
IGNvdXJpZXIgbmV3LG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogY291cmll
ciBuZXcsbW9ub3NwYWNlOyI+QWxsIGxhZ3Mgb2YgbGWgoKCgoKCgoKCgoKCgoKCgoCBGKDQsIDYw
KSA9oCAwLjIzMzAzIFswLjkxODddPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IGNvdXJp
ZXIgbmV3LG1vbm9zcGFjZTsiPgoKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBjb3VyaWVyIG5l
dyxtb25vc3BhY2U7Ij5BbGwgbGFncyBvZiBscGF1oKCgoKCgoKCgoKCgoKCgIEYoNCwgNjApID2g
oCAxLjM5MzkgWzAuMjQ2OV08L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogY291cmllciBu
ZXcsbW9ub3NwYWNlOyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBjb3VyaWVyIG5ldyxtb25v
c3BhY2U7Ij5BbGwgdmFycywgbGFnIDSgoKCgoKCgoKCgoKCgoKCgIEYoMywgNjApID2goCA2LjA1
OTAgWzAuMDAxMV08L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogY291cmllciBuZXcsbW9u
b3NwYWNlOyI+Cgo8L2ZvbnQ+PGJyPkFuZCBpbiBQb3J0dWd1ZXNlIGFyZTo8YnI+PGJyPjxmb250
IHNpemU9IjEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogY291cmllciBuZXcsbW9ub3NwYWNl
OyI+VGVzdGVzLUYgY29tIHplcm8gcmVzdHJp5/Vlczo8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh
bWlseTogY291cmllciBuZXcsbW9ub3NwYWNlOyI+PGJyIHN0eWxlPSJmb250LWZhbWlseTogY291
cmllciBuZXcsbW9ub3NwYWNlOyI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGNvdXJpZXIg
bmV3LG1vbm9zcGFjZTsiPlRvZGFzIGFzIGRlZmFzYWdlbnMgZGUgbHB1c6CgoKCgoKCgoKCgoKCg
oCBGKDQsIDYwKSA9oKAgNzYwLDUzIFswLDAwMDBdPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p
bHk6IGNvdXJpZXIgbmV3LG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogY291
cmllciBuZXcsbW9ub3NwYWNlOyI+VG9kYXMgYXMgZGVmYXNhZ2VucyBkZSBsZaCgoKCgoKCgoKCg
oKCgoKCgIEYoNCwgNjApID2gIDAsMjMzMDMgWzAsOTE4N108L3NwYW4+PGJyIHN0eWxlPSJmb250
LWZhbWlseTogY291cmllciBuZXcsbW9ub3NwYWNlOyI+Cgo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6IGNvdXJpZXIgbmV3LG1vbm9zcGFjZTsiPlRvZGFzIGFzIGRlZmFzYWdlbnMgZGUgbHBhdaCg
oKCgoKCgoKCgoKCgoCBGKDQsIDYwKSA9oKAgMSwzOTM5IFswLDI0NjldPC9zcGFuPjxiciBzdHls
ZT0iZm9udC1mYW1pbHk6IGNvdXJpZXIgbmV3LG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTogY291cmllciBuZXcsbW9ub3NwYWNlOyI+VG9kYXMgYXMgdmFyaeF2ZWlzLCBkZWZh
c2FnZW0gNKCgoKCgoKCgoKCgoKCgoKAgRigzLCA2MCkgPaCgIDYsMDU5MCBbMCwwMDExXTwvc3Bh
bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBjb3VyaWVyIG5ldyxtb25vc3BhY2U7Ij4KCjwvZm9u
dD48YnI+PGJyPkkga25vdyB0aGF0IHRoaXMgaXMgbm90IGEgYmlnIGRlYWwsIGJ1dCwgaWYgdGhp
cyB0YXNrIGlzIG5vdCBhIGRpZmZpY3VsdHkgb25lLCBpcyBpdCBwb3NzaWJsZSB0byBmaXggdGhp
cz8gSTxicj48YnI+PGJyPkJlc3QgcmVnYXJkcywgPGJyPkhlbnJpcXVlIEMuIGRlIEFuZHJhZGU8
YnI+RG91dG9yYW5kbyBlbSBFY29ub21pYSBBcGxpY2FkYTxicj5Vbml2ZXJzaWRhZGUgRmVkZXJh
bCBkbyBSaW8gR3JhbmRlIGRvIFN1bDxicj4KCjxhIGhyZWY9Imh0dHA6Ly93d3cudWZyZ3MuYnIv
cHBnZSI+d3d3LnVmcmdzLmJyL3BwZ2U8L2E+PGJyPgo=

--===============0373487859794567356==--


From cottrell@wfu.edu Thu Apr  8 16:28:47 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VAR Results Tabulation
Date: Thu, 08 Apr 2010 16:28:46 -0400
Message-ID: <Pine.A41.4.58.1004081627380.2420994@f1n11.sp2net.wfu.edu>
In-Reply-To: h2ub3173c601004081140laddb7ae6q429a44458108090f@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7557247715917881403=="

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


On Thu, 8 Apr 2010, Henrique Andrade wrote:

> I'd observed an odd tabulation of the F-tests in the VAR estimations results
> when I use Gretl in languages other than English...

The length of multi-byte characters is not being properly taken
into account. I'll fix that shortly.

Allin Cottrell

--===============7557247715917881403==--


From cottrell@wfu.edu Fri Apr  9 14:32:18 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VAR Results Tabulation
Date: Fri, 09 Apr 2010 14:32:17 -0400
Message-ID: <Pine.A41.4.58.1004091431440.315812@f1n11.sp2net.wfu.edu>
In-Reply-To: h2ub3173c601004081140laddb7ae6q429a44458108090f@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3709967396565194378=="

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


On Thu, 8 Apr 2010, Henrique Andrade wrote:

> I'd observed an odd tabulation of the F-tests in the VAR
> estimations results when I use Gretl in languages other than
> English...

This should now be fixed in CVS and snapshots.

Allin

--===============3709967396565194378==--


From henrique.coelho@gmail.com Fri Apr  9 15:03:15 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VAR Results Tabulation
Date: Fri, 09 Apr 2010 16:02:53 -0300
Message-ID: <l2pb3173c601004091202mc93a8490i8f467d82c694922a@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.1004091431440.315812@f1n11.sp2net.wfu.edu
Content-Type: multipart/mixed; boundary="===============7380180833860064859=="

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

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkVtIDkgZGUgYWJyaWwgZGUgMjAxMCBBbGxpbiA8c3Bh
biBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpjb3R0cmVsbEB3ZnUuZWR1Ij5jb3R0cmVs
bEB3ZnUuZWR1PC9hPiZndDs8L3NwYW4+IGVzY3JldmV1Ojxicj48YnI+PGJsb2NrcXVvdGUgY2xh
c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgYm9yZGVy
LWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+
Cgo8ZGl2IGNsYXNzPSJpbSI+Ck9uIFRodSwgOCBBcHIgMjAxMCwgSGVucmlxdWUgQW5kcmFkZSB3
cm90ZTo8YnI+Cjxicj4KPC9kaXY+PGRpdiBjbGFzcz0iaW0iPiZndDsgSSYjMzk7ZCBvYnNlcnZl
ZCBhbiBvZGQgdGFidWxhdGlvbiBvZiB0aGUgRi10ZXN0cyBpbiB0aGUgVkFSPGJyPgomZ3Q7IGVz
dGltYXRpb25zIHJlc3VsdHMgd2hlbiBJIHVzZSBHcmV0bCBpbiBsYW5ndWFnZXMgb3RoZXIgdGhh
bjxicj4KPC9kaXY+Jmd0OyBFbmdsaXNoLi4uPGJyPgo8YnI+ClRoaXMgc2hvdWxkIG5vdyBiZSBm
aXhlZCBpbiBDVlMgYW5kIHNuYXBzaG90cy48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPkkmIzM5
O2QgdGVzdGVkIHVuZGVyIE1hYyBPUyBYIGFuZCBXaW5kb3dzIFhQIHVzaW5nIEJyYXppbGlhbiBQ
b3J0dWd1ZXNlPGJyPmFuZCBUdXJraXNoIGFuZCB0aGUgdGFidWxhdGlvbiAmcXVvdDtwcm9ibGVt
JnF1b3Q7IGRpc2FwcGVhcmVkIGZyb20gdGhlIE1hYyB2ZXJzaW9uLDxicj4KCmJ1dCByZW1haW5z
IChqdXN0IGZvciAxIHNpbmdsZSBzcGFjZSkgaW4gV2luZG93cy48YnI+PGJyPkJlc3QsPGJyPkhl
bnJpcXVlPGJyPjwvZGl2PjwvZGl2Pgo=

--===============7380180833860064859==--


From svetosch@gmx.net Sat Apr 10 15:48:52 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] time trend variable
Date: Sat, 10 Apr 2010 21:48:34 +0200
Message-ID: <4BC0D612.8020004@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5627217019823113114=="

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

Hi,

is 'series time' supposed to work as an alias for 'genr time'?

Does it work for you? (It doesn't seem to work here.)

thanks,
sven

--===============5627217019823113114==--


From henrique.coelho@gmail.com Sat Apr 10 16:34:22 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time trend variable
Date: Sat, 10 Apr 2010 17:34:00 -0300
Message-ID: <x2lb3173c601004101334l77f0e3el5611eaab65363e69@mail.gmail.com>
In-Reply-To: 4BC0D612.8020004@gmx.net
Content-Type: multipart/mixed; boundary="===============7081782624154036803=="

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

RW0gMTAgZGUgYWJyaWwgZGUgMjAxMCBTdmVuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0i
bWFpbHRvOnN2ZXRvc2NoQGdteC5uZXQiPnN2ZXRvc2NoQGdteC5uZXQ8L2E+Jmd0OyBlc2NyZXZl
dTo8YnI+PGJyPjwvc3Bhbj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xh
c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgYm9yZGVy
LWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+
CgpIaSw8YnI+Cjxicj4KaXMgJiMzOTtzZXJpZXMgdGltZSYjMzk7IHN1cHBvc2VkIHRvIHdvcmsg
YXMgYW4gYWxpYXMgZm9yICYjMzk7Z2VuciB0aW1lJiMzOTs/PGJyPgo8YnI+CkRvZXMgaXQgd29y
ayBmb3IgeW91PyAoSXQgZG9lc24mIzM5O3Qgc2VlbSB0byB3b3JrIGhlcmUuKTxicj48L2Jsb2Nr
cXVvdGU+PGRpdj48YnI+VHJ5ICZxdW90O3NlcmllcyBBX05BTUUgPSB0aW1lJnF1b3Q7Ljxicj48
YnI+QmVzdCw8YnI+SGVucmlxdWU8YnI+PC9kaXY+PC9kaXY+Cg==

--===============7081782624154036803==--


From cottrell@wfu.edu Sat Apr 10 16:55:19 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time trend variable
Date: Sat, 10 Apr 2010 16:55:17 -0400
Message-ID: <Pine.A41.4.58.1004101655001.2953448@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC0D612.8020004@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4856235387459286518=="

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


On Sat, 10 Apr 2010, Sven Schreiber wrote:

> is 'series time' supposed to work as an alias for 'genr time'?

No ;-)

Allin

--===============4856235387459286518==--


From svetosch@gmx.net Sat Apr 10 18:08:57 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] several 'uhat'
Date: Sun, 11 Apr 2010 00:08:24 +0200
Message-ID: <4BC0F6D8.901@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0888160116941550576=="

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

Hi again,

it just happened to me that after repeatedly saving residuals (from
different VARs) via the GUI with name 'uhat5' I got several series named
'uhat5'. I thought they would get overwritten instead. I didn't know
that having several variables with the same names (althought different
Id numbers) is possible. Is that behavior a bug?

(cvs from last month running here)

thanks,
sven

--===============0888160116941550576==--


From cottrell@wfu.edu Sat Apr 10 18:53:42 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] several 'uhat'
Date: Sat, 10 Apr 2010 18:53:41 -0400
Message-ID: <Pine.A41.4.58.1004101853080.2658730@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC0F6D8.901@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4877452754347161789=="

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


On Sun, 11 Apr 2010, Sven Schreiber wrote:

> it just happened to me that after repeatedly saving residuals (from
> different VARs) via the GUI with name 'uhat5' I got several series named
> 'uhat5'. I thought they would get overwritten instead. I didn't know
> that having several variables with the same names (althought different
> Id numbers) is possible. Is that behavior a bug?

It certainly sounds like it. I'll investigate.

Allin

--===============4877452754347161789==--


From svetosch@gmx.net Sun Apr 11 11:00:10 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] multivariate lrvar
Date: Sun, 11 Apr 2010 16:59:52 +0200
Message-ID: <4BC1E3E8.2010406@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5358570807711402104=="

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

Hi,
when I wanted to use lrvar() I discovered it's only for single series.
So I ported some code to gretl to estimate the long-run covariance
matrix for multivariate series (along with a helper function
autocovar()). I haven't tested it yet, probably some bugs remaining.

Actually I wanted  to ask whether it would make sense to allow the
multivariate case in built-in lrvar()?

thanks,
sven

-----------

function matrix autocovar(matrix indatamat, int lag[0], bool demeaned[0])
    /*	computes the autocovariance at lag "lag" for a multivariate time
series
        returns a NxN covariance matrix
    */

    N = cols(indatamat)
    T = rows(indatamat)
    if demeaned=0
        matrix datademeaned = cdemean(indatamat)
    else
        matrix datademeaned = indatamat
    endif

    matrix result = transp(datademeaned[lag+1:T,])*datademeaned[1:T-lag,]
    matrix result /= T
    return result
end function

function matrix longrunvar(matrix indatamat, bool demeaned[0], lagtrunc[4])
    /* indatamat is a TxN time series matrix
       Bartlett window
       returns an NxN matrix (spectral density at frequency zero)
    */

    N = cols(indatamat)
    matrix result = zeros(N,N)
    loop for tau=1..lagtrunc
        matrix Gamma = autocovar(indatamat,tau,demeaned)
        # positive and negative tau range together:
        matrix result += (1 -tau/(lagtrunc+1)) * (Gamma+Gamma')
    endloop
    # add the tau=0 part:
    matrix result += autocovar(indatamat,0,demeaned)
    return result
end function


--===============5358570807711402104==--


From svetosch@gmx.net Sun Apr 11 11:36:40 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] (further) aliases for series, matrix etc.
Date: Sun, 11 Apr 2010 17:36:09 +0200
Message-ID: <4BC1EC69.2000700@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0719721517628558094=="

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

Hi,

just a thought:

There was the idea that maybe (just maybe) it could make sense to
enforce clear programming by requiring to use 'matrix', 'series' etc.
instead of the generic 'genr', at least in scripts.

However, when doing that (as I do) the long keywords appearing almost
everywhere are a bit annoying. So what about introducing 'mat' as alias
for 'matrix', 'ser' for 'series', 'sca' for 'scalar', 'str' for
'string'; 'list' could stay like that I guess, or maybe to have 3-letter
conformity also introduce 'lis'.

As I said, just a thought...

cheers,
sven

--===============0719721517628558094==--


From helioxentric@gmail.com Sun Apr 11 11:52:29 2010
From: =?utf-8?q?H=C3=A9lio?= Guilherme <helioxentric@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] (further) aliases for series, matrix etc.
Date: Sun, 11 Apr 2010 16:52:27 +0100
Message-ID: <q2m5be765951004110852s84a244d3qc30759b2b507823c@mail.gmail.com>
In-Reply-To: 4BC1EC69.2000700@gmx.net
Content-Type: multipart/mixed; boundary="===============0650589776834707568=="

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

SSByZWFsbHkgZG9uJiMzOTt0IGxpa2UgdG8gYWJicmV2aWF0ZSBjb21tYW5kcy4gSXQgbWF5IG1h
a2Ugc2Vuc2UgdG8geW91LCBidXQgaWYgb3RoZXIgcmVhZGVycyB3b3VsZCBzZWUgeW91ciBzY3Jp
cHQgdGhleSB3aWxsIG5lZWQgbW9yZSBicmFpbiBwcm9jZXNzaW5nIHRpbWUgdG8gZGVjb2RlIHRo
ZSBtZWFuaW5nIG9mIHRoZSBjb21tYW5kcy48YnI+PGJyPkkgd291bGQgcHJvcG9zZSB0byBoYXZl
IGEgJnF1b3Q7YWxpYXMmcXVvdDsgY29tbWFuZCBsaWtlIHdlIGhhdmUgaW4gTGludXgsIHNvIGZv
ciBleGFtcGxlIHlvdSB3b3VsZCBkZWZpbmUgaW4gdGhlIHN0YXJ0IG9mIHlvdXIgc2NyaXB0cyB0
aGUgbmVlZGVkIGFsaWFzZXMuPGJyPgo8YnI+YWxpYXMgbWF0IG1hdHJpeDxicj48YnI+VGhpcyBj
b3VsZCBiZSBleHBhbmRlZCB0byBoYXZlIHRoZW0gYWxsIGluIGEgdXNlciBmaWxlIHRoYXQgd291
bGQgYmUgaW5jbHVkZWQgYWx3YXlzIGluIHlvdXIgc2NyaXB0cy4gVGhpcyBsaXN0IHdvdWxkIGJl
IGFjdHVhbGx5IHdyaXR0ZW4gaW4gdGhlIHNjcmlwdCBmaWxlLCBmb3IgcmVwcm9kdWNpYmlsaXR5
Ljxicj48YnI+T3B0aW9uYWxseSwgdGhlIGVkaXRvciBjb3VsZCBoYXZlIHNvbWUgaGlkaW5nIGZl
YXR1cmUgb2YgdGhlIGFsaWFzZXMgbGlzdCwgaW5kaWNhdGVkIGJ5IGEgdGFnLCBmb3IgZXhhbXBs
ZTo8YnI+CiNhbGlhc2RlZmluaXRpb248YnI+PGJyPlRoZSBkb3duc2lkZSBvZiB0aGlzIGFsaWFz
IGNvbW1hbmQgd291bGQgYmUgbW9yZSBwYXJzaW5nIHRpbWUgZm9yIGEgc2NyaXB0IGZpbGUgb3Ig
Y29tbWFuZHMuPGJyPjxicj5XaGF0IGRvIHlvdSB0aGluaz8gwqAgPGJyPjxicj48ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMTEsIDIwMTAgYXQgNDozNiBQTSwgU3ZlbiBTY2hy
ZWliZXIgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86c3ZldG9zY2hAZ214Lm5l
dCI+c3ZldG9zY2hAZ214Lm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+CjxibG9ja3F1b3Rl
IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IGJv
cmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFl
eDsiPkhpLDxicj4KPGJyPgpqdXN0IGEgdGhvdWdodDo8YnI+Cjxicj4KVGhlcmUgd2FzIHRoZSBp
ZGVhIHRoYXQgbWF5YmUgKGp1c3QgbWF5YmUpIGl0IGNvdWxkIG1ha2Ugc2Vuc2UgdG88YnI+CmVu
Zm9yY2UgY2xlYXIgcHJvZ3JhbW1pbmcgYnkgcmVxdWlyaW5nIHRvIHVzZSAmIzM5O21hdHJpeCYj
Mzk7LCAmIzM5O3NlcmllcyYjMzk7IGV0Yy48YnI+Cmluc3RlYWQgb2YgdGhlIGdlbmVyaWMgJiMz
OTtnZW5yJiMzOTssIGF0IGxlYXN0IGluIHNjcmlwdHMuPGJyPgo8YnI+Ckhvd2V2ZXIsIHdoZW4g
ZG9pbmcgdGhhdCAoYXMgSSBkbykgdGhlIGxvbmcga2V5d29yZHMgYXBwZWFyaW5nIGFsbW9zdDxi
cj4KZXZlcnl3aGVyZSBhcmUgYSBiaXQgYW5ub3lpbmcuIFNvIHdoYXQgYWJvdXQgaW50cm9kdWNp
bmcgJiMzOTttYXQmIzM5OyBhcyBhbGlhczxicj4KZm9yICYjMzk7bWF0cml4JiMzOTssICYjMzk7
c2VyJiMzOTsgZm9yICYjMzk7c2VyaWVzJiMzOTssICYjMzk7c2NhJiMzOTsgZm9yICYjMzk7c2Nh
bGFyJiMzOTssICYjMzk7c3RyJiMzOTsgZm9yPGJyPgomIzM5O3N0cmluZyYjMzk7OyAmIzM5O2xp
c3QmIzM5OyBjb3VsZCBzdGF5IGxpa2UgdGhhdCBJIGd1ZXNzLCBvciBtYXliZSB0byBoYXZlIDMt
bGV0dGVyPGJyPgpjb25mb3JtaXR5IGFsc28gaW50cm9kdWNlICYjMzk7bGlzJiMzOTsuPGJyPgo8
YnI+CkFzIEkgc2FpZCwganVzdCBhIHRob3VnaHQuLi48YnI+Cjxicj4KY2hlZXJzLDxicj4Kc3Zl
bjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
CkdyZXRsLWRldmVsIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOkdyZXRsLWRldmVs
QGxpc3RzLndmdS5lZHUiPkdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHU8L2E+PGJyPgo8YSBocmVm
PSJodHRwOi8vbGlzdHMud2Z1LmVkdS9tYWlsbWFuL2xpc3RpbmZvL2dyZXRsLWRldmVsIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLndmdS5lZHUvbWFpbG1hbi9saXN0aW5mby9ncmV0bC1k
ZXZlbDwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg==

--===============0650589776834707568==--


From svetosch@gmx.net Sun Apr 11 17:22:07 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] (further) aliases for series, matrix etc.
Date: Sun, 11 Apr 2010 23:21:31 +0200
Message-ID: <4BC23D5B.7030709@gmx.net>
In-Reply-To: q2m5be765951004110852s84a244d3qc30759b2b507823c@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7828072219952098295=="

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

Hélio Guilherme schrieb:
> I really don't like to abbreviate commands. It may make sense to you,
> but if other readers would see your script they will need more brain
> processing time to decode the meaning of the commands.
> 
> I would propose to have a "alias" command like we have in Linux, so for
> example you would define in the start of your scripts the needed aliases.
> 
> alias mat matrix
> 

I agree there's a tradeoff between readability and conciseness. But I
actually think that if each user defines his own aliases then the
tradeoff gets worse, because you're not used to the shortcuts somebody
else likes to use. So I still think it would make more sense to have
shortcuts defined in the gretl syntax itself.

Let me add that in general I think if it's the first three letters of a
command then it's quite easy to recognize and to read.

Of course, the whole thing is less important for the current status quo
where 'matrix' etc. is not mandatory. (although I would still like it
personally) But if the use of 'series', 'matrix' etc. is enforced, then
IMHO it's a real issue.

anyway, so much for that,

sven




--===============7828072219952098295==--


From cottrell@wfu.edu Mon Apr 12 22:21:56 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] several 'uhat'
Date: Mon, 12 Apr 2010 22:21:55 -0400
Message-ID: <Pine.A41.4.58.1004122212310.2707906@f1n11.sp2net.wfu.edu>
In-Reply-To: Pine.A41.4.58.1004101853080.2658730@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3719768119408354245=="

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


On Sat, 10 Apr 2010, Allin Cottrell wrote:

> On Sun, 11 Apr 2010, Sven Schreiber wrote:
>
> > it just happened to me that after repeatedly saving residuals (from
> > different VARs) via the GUI with name 'uhat5' I got several series named
> > 'uhat5'. I thought they would get overwritten instead. I didn't know
> > that having several variables with the same names (althought different
> > Id numbers) is possible. Is that behavior a bug?
>
> It certainly sounds like it. I'll investigate.

I think this is now fixed. I've given the GUI mechanism for saving
model-related series an overhaul. (It was pretty much OK for
single-equation models, not so for VARs.) The intent is as
follows, and any departure from the intent can be considered a
bug:

* When you go to save a series, the default name that you're given
should be unique (does not conflict with any existing series).

* If you don't accept the default, but type in your own choice,
then if there's an existing series of that name we check if it's
"safe" to overwrite the original. If not, you get an error message
and a chance to choose a different name; if yes, you get a dialog
asking for confirmation that you want to overwrite the old series.

* In no case should it be possible to create multiple series with
the same name.

Allin

--===============3719768119408354245==--


From svetosch@gmx.net Tue Apr 13 07:10:18 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] several 'uhat'
Date: Tue, 13 Apr 2010 13:09:37 +0200
Message-ID: <4BC450F1.8080304@gmx.net>
In-Reply-To: Pine.A41.4.58.1004122212310.2707906@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2347073679484520340=="

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

Allin Cottrell schrieb:
> On Sat, 10 Apr 2010, Allin Cottrell wrote:
> 
>> On Sun, 11 Apr 2010, Sven Schreiber wrote:
>>
>>> it just happened to me that after repeatedly saving residuals (from
>>> different VARs) via the GUI with name 'uhat5' I got several series named
>>> 'uhat5'. I thought they would get overwritten instead. I didn't know
>>> that having several variables with the same names (althought different
>>> Id numbers) is possible. Is that behavior a bug?
>> It certainly sounds like it. I'll investigate.
> 
> I think this is now fixed. I've given the GUI mechanism for saving
> model-related series an overhaul. (It was pretty much OK for
> single-equation models, not so for VARs.) The intent is as
> follows, and any departure from the intent can be considered a
> bug:

Thanks!

> 
> * When you go to save a series, the default name that you're given
> should be unique (does not conflict with any existing series).
> 
> * If you don't accept the default, but type in your own choice,
> then if there's an existing series of that name we check if it's
> "safe" to overwrite the original. If not, you get an error message
> and a chance to choose a different name; if yes, you get a dialog
> asking for confirmation that you want to overwrite the old series.

what's your definition of "safe" in this context?

-sven

--===============2347073679484520340==--


From svetosch@gmx.net Tue Apr 13 07:13:16 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 13:12:53 +0200
Message-ID: <4BC451B5.6080202@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4455730810101972384=="

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

Hi,

I discovered what's IMHO a relative severe bug (severe because it can go
unnoticed and would lead to rubbish afterwards):

Missing values are not propagated when multiplying dummy variables. Example:

open greene14_1
series check1 = (Q>100)
series check2 = zeromiss(LF <0.5)
series checkmult = check1*check2

and 'checkmult' should have missings where check2 has them but it doesn't.

I discovered it in a panel context but I haven't tested whether it's
more general than that.

thanks,
sven

--===============4455730810101972384==--


From cottrell@wfu.edu Tue Apr 13 09:16:45 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] several 'uhat'
Date: Tue, 13 Apr 2010 09:16:44 -0400
Message-ID: <Pine.A41.4.58.1004130911530.3096684@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC450F1.8080304@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6700211407851116799=="

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


On Tue, 13 Apr 2010, Sven Schreiber wrote:

> Allin Cottrell schrieb:
> > On Sat, 10 Apr 2010, Allin Cottrell wrote:
> >
> >> On Sun, 11 Apr 2010, Sven Schreiber wrote:
> >>
> >>> it just happened to me that after repeatedly saving residuals (from
> >>> different VARs) via the GUI with name 'uhat5' I got several series named
> >>> 'uhat5'. I thought they would get overwritten instead. I didn't know
> >>> that having several variables with the same names (althought different
> >>> Id numbers) is possible. Is that behavior a bug?
> >> It certainly sounds like it. I'll investigate.
> >
> > I think this is now fixed. I've given the GUI mechanism for saving
> > model-related series an overhaul. (It was pretty much OK for
> > single-equation models, not so for VARs.) The intent is as
> > follows, and any departure from the intent can be considered a
> > bug:
>
> Thanks!
> >
> > * When you go to save a series, the default name that you're given
> > should be unique (does not conflict with any existing series).
> >
> > * If you don't accept the default, but type in your own choice,
> > then if there's an existing series of that name we check if it's
> > "safe" to overwrite the original. If not, you get an error message
> > and a chance to choose a different name; if yes, you get a dialog
> > asking for confirmation that you want to overwrite the old series.
>
> what's your definition of "safe" in this context?

I'm being conservative. The criterion is twofold: first, the
series to be overwritten should not be a "parent" variable for
secondary series such as lags; second, it should meet the
condition for deletion being OK, namely it has a higher ID number
than any series that's used in a saved model.

Allin



--===============6700211407851116799==--


From cottrell@wfu.edu Tue Apr 13 09:34:23 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 09:34:22 -0400
Message-ID: <Pine.A41.4.58.1004130919460.3096684@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC451B5.6080202@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6403544235047601666=="

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


On Tue, 13 Apr 2010, Sven Schreiber wrote:

> I discovered what's IMHO a relative severe bug (severe because it can go
> unnoticed and would lead to rubbish afterwards):
>
> Missing values are not propagated when multiplying dummy variables. Example:
>
> open greene14_1
> series check1 = (Q>100)
> series check2 = zeromiss(LF <0.5)
> series checkmult = check1*check2
>
> and 'checkmult' should have missings where check2 has them but it doesn't.

That behavior is by design and IMO it's not a bug, since zero
times any value is zero. (This is the one exception we make to the
rule that NAs always propagate to the result, and it's explained
in section 5.7 of the User's Guide, "Handling missing values".)

To get the behavior you were expecting:

checkmult = !ok(check2) ? NA : check1*check2

Allin



--===============6403544235047601666==--


From r.lucchetti@univpm.it Tue Apr 13 10:15:13 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 16:15:08 +0200
Message-ID: <alpine.DEB.2.00.1004131602120.31200@ec-4.econ.univpm.it>
In-Reply-To: Pine.A41.4.58.1004130919460.3096684@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8439190911320152704=="

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

On Tue, 13 Apr 2010, Allin Cottrell wrote:

> That behavior is by design and IMO it's not a bug, since zero
> times any value is zero. (This is the one exception we make to the
> rule that NAs always propagate to the result, and it's explained
> in section 5.7 of the User's Guide, "Handling missing values".)

FWIW, let me back Allin on this one. The idea that NA*0 should return 0 
troubled me in the past, until I realised that setting something to NA is 
often a shortcut we use when we really mean 'I don't want this observation 
in my sample'. In fact, NA simply stands for 'I don't know what this cell 
contains', and when you think about it this way, then NA*0==0 makes 
perfect sense.

Example: suppose you have wage data for individuals who may be unemployed. 
For those cases, you'd obviously have NA. Now suppose you want to 
"interact" wage with a gender dummy (suppose 1==male, 0==female). Clearly, 
if you multiply wage by gender (w_male = wage * gender) you'd get 
w_male==NA for unemployed men and w_male==0 for unemployed women, which is 
counter-intuitive only if you expect things to work if you screen 
unemployed people by checking for ok(w_g). The "proper" way to go in this 
case would be to define w_male as

w_male = ok(wage) ? wage * gender : NA


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

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

--===============8439190911320152704==--


From svetosch@gmx.net Tue Apr 13 11:06:45 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 17:06:36 +0200
Message-ID: <4BC4887C.6060800@gmx.net>
In-Reply-To: alpine.DEB.2.00.1004131602120.31200@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7737054047596894957=="

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

Riccardo (Jack) Lucchetti schrieb:
> On Tue, 13 Apr 2010, Allin Cottrell wrote:
> 
>> That behavior is by design and IMO it's not a bug, since zero
>> times any value is zero. (This is the one exception we make to the
>> rule that NAs always propagate to the result, and it's explained
>> in section 5.7 of the User's Guide, "Handling missing values".)
> 
> FWIW, let me back Allin on this one. The idea that NA*0 should return 0
> troubled me in the past, until I realised that setting something to NA
> is often a shortcut we use when we really mean 'I don't want this
> observation in my sample'. In fact, NA simply stands for 'I don't know
> what this cell contains', and when you think about it this way, then
> NA*0==0 makes perfect sense.
> 

Thanks for the explanation. I have two reactions to this:

1) Is this a gretl idiosyncracy? (In the sense of: "do all other
softwares treat missings differently, e.g. similar to floating-point
'NaN' according to things like IEEE standards which AFAIK always
propagate?") Then I think I would be fairly strongly against gretl's
behavior. At least I was quite surprised and according to my intuition
it was clearly a bug. (that's why I didn't check in the manual)

2) I think that Jack's reasoning is partly correct, but not in full
generality: it's *not* always true that na stands for "don't know the
exact number", sometimes it stands for "not applicable", "not a
meaningful (numeric) value", etc. And consider the literal meaning of
"NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
number, which you simply don't know if you have a missing. (Often it
will indeed be an unknown number, but not always, that's my point.)

So I'm sorry, but I have to say I'm not convinced.

thanks,
sven

--===============7737054047596894957==--


From bhh@xs4all.nl Tue Apr 13 11:19:17 2010
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 17:19:13 +0200
Message-ID: <BEA744DB-0C91-4C3C-AC14-107C6B08872B@xs4all.nl>
In-Reply-To: 4BC4887C.6060800@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6576430166947196675=="

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


On 13-04-2010, at 17:06, Sven Schreiber wrote:

> Riccardo (Jack) Lucchetti schrieb:
>> On Tue, 13 Apr 2010, Allin Cottrell wrote:
>> 
>>> That behavior is by design and IMO it's not a bug, since zero
>>> times any value is zero. (This is the one exception we make to the
>>> rule that NAs always propagate to the result, and it's explained
>>> in section 5.7 of the User's Guide, "Handling missing values".)
>> 
>> FWIW, let me back Allin on this one. The idea that NA*0 should return 0
>> troubled me in the past, until I realised that setting something to NA
>> is often a shortcut we use when we really mean 'I don't want this
>> observation in my sample'. In fact, NA simply stands for 'I don't know
>> what this cell contains', and when you think about it this way, then
>> NA*0==0 makes perfect sense.
>> 
> 
> Thanks for the explanation. I have two reactions to this:
> 
> 1) Is this a gretl idiosyncracy? (In the sense of: "do all other
> softwares treat missings differently, e.g. similar to floating-point
> 'NaN' according to things like IEEE standards which AFAIK always
> propagate?") Then I think I would be fairly strongly against gretl's
> behavior. At least I was quite surprised and according to my intuition
> it was clearly a bug. (that's why I didn't check in the manual)
> 
> 2) I think that Jack's reasoning is partly correct, but not in full
> generality: it's *not* always true that na stands for "don't know the
> exact number", sometimes it stands for "not applicable", "not a
> meaningful (numeric) value", etc. And consider the literal meaning of
> "NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
> number, which you simply don't know if you have a missing. (Often it
> will indeed be an unknown number, but not always, that's my point.)
> 
> So I'm sorry, but I have to say I'm not convinced.

In R

xna <- NA		# Not Available
xnan <- NaN
xpinf <- Inf
xminf <- -Inf

> 0*xna
[1] NA
> 0*xnan
[1] NaN
> 0*xpinf
[1] NaN
> 0*xminf
[1] NaN

I'm also not convinced.

Berend



--===============6576430166947196675==--


From bhh@xs4all.nl Tue Apr 13 11:30:13 2010
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 17:30:06 +0200
Message-ID: <61528DA8-0C99-4348-B4DA-444B10333F80@xs4all.nl>
In-Reply-To: BEA744DB-0C91-4C3C-AC14-107C6B08872B@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2354753222703016934=="

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


On 13-04-2010, at 17:19, Berend Hasselman wrote:

> 
> In R
> 
> xna <- NA		# Not Available
> xnan <- NaN
> xpinf <- Inf
> xminf <- -Inf
> 
>> 0*xna
> [1] NA
>> 0*xnan
> [1] NaN
>> 0*xpinf
> [1] NaN
>> 0*xminf
> [1] NaN


I just tried Octave 3.2.3 (on Mac OS X 10.6.3)
Same result as R.

Berend

--===============2354753222703016934==--


From r.lucchetti@univpm.it Tue Apr 13 11:51:44 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 17:51:42 +0200
Message-ID: <alpine.DEB.2.00.1004131738070.31200@ec-4.econ.univpm.it>
In-Reply-To: BEA744DB-0C91-4C3C-AC14-107C6B08872B@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6141050993470597822=="

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

On Tue, 13 Apr 2010, Berend Hasselman wrote:

>> 2) I think that Jack's reasoning is partly correct, but not in full
>> generality: it's *not* always true that na stands for "don't know the
>> exact number", sometimes it stands for "not applicable", "not a
>> meaningful (numeric) value", etc. And consider the literal meaning of
>> "NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
>> number, which you simply don't know if you have a missing. (Often it
>> will indeed be an unknown number, but not always, that's my point.)
>>
>> So I'm sorry, but I have to say I'm not convinced.

In my view, NA and NaN are two very different things. As you say, NaN*0 
== NaN, by the definition of NaN. If you restrict the interpretation of NA 
to "unknown numbwer (but still a number)", then NA*0==0 makes sense. Let 
me give another example: suppose you have individuals whose income Y may be 
missing, and their tax rate R (with no missing). Of course Y*R gives you 
the amount due. If Y is NA, but R==0, why should you doubt that the amount 
due is 0?

So I think that NA and NaN are fundamentally different, and should be 
treated as such; note that we don't do this at present: if you try

series foo = ln(normal())

you get NAs rather NaNs. I accept that behaviour such as this should be 
fixed, although not a priority IMO.


> In R
>
> xna <- NA		# Not Available
> xnan <- NaN
> xpinf <- Inf
> xminf <- -Inf
>
>> 0*xna
> [1] NA
>> 0*xnan
> [1] NaN
>> 0*xpinf
> [1] NaN
>> 0*xminf
> [1] NaN
>
> I'm also not convinced.

On the basis of my reasoning above, I consider the first example above 
wrong, with due respect to R (and octave).


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

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

--===============6141050993470597822==--


From svetosch@gmx.net Tue Apr 13 12:25:46 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 18:25:09 +0200
Message-ID: <4BC49AE5.9020800@gmx.net>
In-Reply-To: alpine.DEB.2.00.1004131738070.31200@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7579332664598248325=="

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

Riccardo (Jack) Lucchetti schrieb:

> In my view, NA and NaN are two very different things. As you say, NaN*0
> == NaN, by the definition of NaN. If you restrict the interpretation of
> NA to "unknown numbwer (but still a number)", then NA*0==0 makes sense.
>

I agree!

> So I think that NA and NaN are fundamentally different, and should be
> treated as such; note that we don't do this at present

exactly; instead gretl implicitly assumes always NA which is not
justified IMHO

> 
> you get NAs rather NaNs. I accept that behaviour such as this should be
> fixed, although not a priority IMO.

I certainly won't argue about priorities...


> 
> On the basis of my reasoning above, I consider the first example above
> wrong, with due respect to R (and octave).
> 

Maybe; although I have to say this could mean to eventually dig further
why octave does it (does Matlab do it? why?). But it's not the main
issue here.

thanks,
sven

--===============7579332664598248325==--


From bhh@xs4all.nl Tue Apr 13 12:55:02 2010
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 18:49:36 +0200
Message-ID: <CD537370-8FA3-40A1-85FB-F95F68BB13E4@xs4all.nl>
In-Reply-To: 4BC49AE5.9020800@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4548625408654509503=="

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


On 13-04-2010, at 18:25, Sven Schreiber wrote:

> Riccardo (Jack) Lucchetti schrieb:
> 
>> In my view, NA and NaN are two very different things. As you say, NaN*0
>> == NaN, by the definition of NaN. If you restrict the interpretation of
>> NA to "unknown numbwer (but still a number)", then NA*0==0 makes sense.
>> 
> 
> I agree!
> 

I don't. 
NA == Not Available.

Assume that it is an unknown number. It could be +Inf or -Inf or even NaN.
Even in a numeric context 0*NA = 0 does not make sense.

I feel that The R and Octave result of NA for 0*NA is perfect reasonable (in a numeric context).
I prefer it.

In a string context 0*Na, R will give an error message.

Berend



--===============4548625408654509503==--


From lee.adkins@okstate.edu Tue Apr 13 13:02:21 2010
From: Lee Adkins <lee.adkins@okstate.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missing dummies?
Date: Tue, 13 Apr 2010 12:02:17 -0500
Message-ID: <q2t596c77551004131002v597fd975y8430d84b03d32e89@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============6079013688315338685=="

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

SGkgYWxsLDxicj5BbHRob3VnaCB0aGUgbG9naWMgb2Ygd2hhdCBKYWNrIHNheXMgaXMgdmFsaWQs
IEkgdGhpbmsgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaXMgYSBiaXQgY29uZnVzaW5nLS1i
YXNpY2FsbHkgYmVjYXVzZSBpdCYjMzk7cyB1bmV4cGVjdGVkLqAgSSBjYW4mIzM5O3QgdGhpbmsg
b2YgYW5vdGhlciBwcm9ncmFtIHRoYXQgZG9lcyB0aGlzLCB0aG91Z2ggSSYjMzk7bSBzdXJlIHRo
ZXJlIG11c3QgYmUgc29tZS6gIFRoZSBvdGhlcnMgdGhhdCBJIHVzZSAoUiwgU3RhdGEsIEdhdXNz
KSBkb24mIzM5O3QuIDxicj4KPGJyPlNpbmNlIHRoZSBjb2Rpbmcgb2YgZHVtbXkgdmFyaWFibGUg
aXMgYXJiaXRyYXJ5IChlLmcuLCB5b3UgY291bGQgdXNlIDEgLTEpIHdoeSBzaG91bGQgemVybyBi
ZSB0cmVhdGVkIGRpZmZlcmVudGx5IGZyb20gYWxsIG90aGVyIHNjYWxhcnMgYW5kIHJlYWwgbnVt
YmVycz+gIEkgdGhpbmsgaXQgY291bGQgbGVhZCB0byBzb21lIHVuZXhwZWN0ZWQgcmVzdWx0cyAo
Zm9yIHRob3NlIHdobyBkb24mIzM5O3QgZGl2ZSBpbnRvIHRoZSBtYW51YWwpLqAgRm9yIHRoZSBz
YWtlIG9mIGNvbnNpc3RlbmN5IEkgd291bGQgcHJlZmVyIHRoYXQgYWxsIG51bWJlcnMgYmUgdHJl
YXRlZCBhbGlrZS6gIDxicj4KCjxicj5PbiB0aGUgb3RoZXIgaGFuZCBpZiB0aGUgemVybypOQSB3
ZXJlIHRyZWF0ZWQgYXMgdGhlIGV4Y2VwdGlvbiBhbmSgIGhhbmRsZWQgd2l0aCBhIHNwZWNpYWwg
Y29tbWFuZCwgdGhhdCB3b3VsZCBtYWtlIG1vcmUgbG9naWNhbCBzZW5zZS0tYXQgbGVhc3QgdG8g
bWUuoCBJIGZpbmQgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaXMga2luZCBvZiBjb25mdXNp
bmcsIGVzcGVjaWFsbHkgZm9yIGdyZXRsJiMzOTtzIG1haW4gYXVkaWVuY2UgKG5vbiBwcm9ncmFt
bWVycyBsaWtlIG1lKSBhbnMgc3R1ZGVudHMgY29taW5nIGZyb20gb3RoZXIgcHJvZ3JhbXMgdGhh
dCB0cmVhdCB0aGUgaW50ZXJhY3Rpb24gbGlrZXdpc2UgKGUuZy4sIFN0YXRhIGFuZCBSKS6goCBK
dXN0IG15IDIgY2VudHMsIGJ1dCBJIHRoaW5rICYjMzk7bSB3aXRoIEJlcmVuZCBvbiB0aGlzIG9u
ZS4uLi48YnI+Cgo8YnI+Q2hlZXJzLDxicj5MZWU8YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5M
ZWUgQWRraW5zPGJyPlByb2Zlc3NvciBvZiBFY29ub21pY3M8YnI+PGEgaHJlZj0ibWFpbHRvOmxl
ZS5hZGtpbnNAb2tzdGF0ZS5lZHUiIHRhcmdldD0iX2JsYW5rIj5sZWUuYWRraW5zQG9rc3RhdGUu
ZWR1PC9hPjxicj48YnI+PGEgaHJlZj0iaHR0cDovL2xlYXJuZWNvbm9tZXRyaWNzLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmxlYXJuZWNvbm9tZXRyaWNzLmNvbTwvYT48YnI+CgoK

--===============6079013688315338685==--


From r.lucchetti@univpm.it Tue Apr 13 13:13:30 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 19:13:26 +0200
Message-ID: <alpine.DEB.2.00.1004131909390.31200@ec-4.econ.univpm.it>
In-Reply-To: CD537370-8FA3-40A1-85FB-F95F68BB13E4@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6785012434670326185=="

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

On Tue, 13 Apr 2010, Berend Hasselman wrote:

>
> On 13-04-2010, at 18:25, Sven Schreiber wrote:
>
>> Riccardo (Jack) Lucchetti schrieb:
>>
>>> In my view, NA and NaN are two very different things. As you say, NaN*0
>>> == NaN, by the definition of NaN. If you restrict the interpretation of
>>> NA to "unknown numbwer (but still a number)", then NA*0==0 makes sense.
>>>
>>
>> I agree!
>>
>
> I don't.
> NA == Not Available.
>
> Assume that it is an unknown number. It could be +Inf or -Inf or even NaN.
> Even in a numeric context 0*NA = 0 does not make sense.

No. +Inf, -Inf or NaN are _not_ numbers. As long as x _is_ a number, 
0*x==0 is true whatever the value of x (known or otherwise).

> I feel that The R and Octave result of NA for 0*NA is perfect reasonable 
> (in a numeric context). I prefer it.

Matter of taste.

> In a string context 0*Na, R will give an error message.

Irrelevant in the present discussion IMO. Besides, R is not the gospel.

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

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

--===============6785012434670326185==--


From bhh@xs4all.nl Tue Apr 13 14:02:55 2010
From: Berend Hasselman <bhh@xs4all.nl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missing dummies?
Date: Tue, 13 Apr 2010 20:02:52 +0200
Message-ID: <A878B373-8374-4E4D-88F7-9CDC554C7BCF@xs4all.nl>
In-Reply-To: q2t596c77551004131002v597fd975y8430d84b03d32e89@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7249927159178038932=="

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


On 13-04-2010, at 19:02, Lee Adkins wrote:

> Hi all,
> Although the logic of what Jack says is valid, I think the current implementation is a bit confusing--basically because it's unexpected.  I can't think of another program that does this, though I'm sure there must be some.  The others that I use (R, Stata, Gauss) don't. 
> 
> Since the coding of dummy variable is arbitrary (e.g., you could use 1 -1) why should zero be treated differently from all other scalars and real numbers?  I think it could lead to some unexpected results (for those who don't dive into the manual).  For the sake of consistency I would prefer that all numbers be treated alike.  
> 
> On the other hand if the zero*NA were treated as the exception and  handled with a special command, that would make more logical sense--at least to me.  I find the current implementation is kind of confusing, especially for gretl's main audience (non programmers like me) ans students coming from other programs that treat the interaction likewise (e.g., Stata and R).   Just my 2 cents, but I think 'm with Berend on this one....

I just did this in a Gretl console

gretl console: type 'help' for a list of commands
? scalar x

? x=10/0
Replaced scalar x = NA
Warning: generated missing values

? y=0*x
Generated scalar y = 0

? z1 = tanh(y)
Generated scalar z1 = 0

? z1 = tanh(10/0)
Replaced scalar z1 = NA

? z1 = tanh(10/0.0000000000000000000001)
Replaced scalar z1 = 1

? a=0*(10/0)
Generated scalar a = 0

This doesn't make sense to me.
This is dangerous.

Berend

--===============7249927159178038932==--


From cottrell@wfu.edu Tue Apr 13 14:19:46 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 14:19:45 -0400
Message-ID: <Pine.A41.4.58.1004131409240.3096684@f1n11.sp2net.wfu.edu>
In-Reply-To: alpine.DEB.2.00.1004131738070.31200@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5558316078038277033=="

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


On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:

> In my view, NA and NaN are two very different things. As you say, NaN*0
> == NaN, by the definition of NaN. If you restrict the interpretation of NA
> to "unknown numbwer (but still a number)", then NA*0==0 makes sense. Let
> me give another example: suppose you have individuals whose income Y may be
> missing, and their tax rate R (with no missing). Of course Y*R gives you
> the amount due. If Y is NA, but R==0, why should you doubt that the amount
> due is 0?
>
> So I think that NA and NaN are fundamentally different, and should be
> treated as such; note that we don't do this at present: if you try
>
> series foo = ln(normal())
>
> you get NAs rather NaNs. I accept that behaviour such as this should be
> fixed, although not a priority IMO.

Good point. I still believe that 0*NA = 0 is fine, so long as NA
(unknown value) and NaN (invalid value) are not conflated. So I
agree we should ensure that the "genr" mechanism does not convert
NaN results to NA.

Strictly, NAs should be confined to values marked as such in
incoming data, values propagated via "genr" on NA input (other
than multiplication by zero), and values marked explicitly by the
user, as in "x[3] = NA" or via "zeromiss()".

Allin


--===============5558316078038277033==--


From r.lucchetti@univpm.it Tue Apr 13 16:08:09 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missing dummies?
Date: Tue, 13 Apr 2010 22:08:05 +0200
Message-ID: <alpine.DEB.2.00.1004132203270.6074@ec-4.econ.univpm.it>
In-Reply-To: A878B373-8374-4E4D-88F7-9CDC554C7BCF@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5738115320578622372=="

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

On Tue, 13 Apr 2010, Berend Hasselman wrote:

> I just did this in a Gretl console
>
> gretl console: type 'help' for a list of commands
> ? scalar x
>
> ? x=10/0
> Replaced scalar x = NA
> Warning: generated missing values
>
> ? y=0*x
> Generated scalar y = 0
>
> ? z1 = tanh(y)
> Generated scalar z1 = 0
>
> ? z1 = tanh(10/0)
> Replaced scalar z1 = NA
>
> ? z1 = tanh(10/0.0000000000000000000001)
> Replaced scalar z1 = 1
>
> ? a=0*(10/0)
> Generated scalar a = 0
>
> This doesn't make sense to me.

Neither it does to me: this is a consequence, as Allin said, of the fact 
that at the moment we erroneously treat NaNs and ±Infs as if they were 
NAs.

> This is dangerous.

Inconvenient, sure. But dangerous?

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

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

--===============5738115320578622372==--


From cottrell@wfu.edu Tue Apr 13 19:48:57 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] NA and nan: next steps
Date: Tue, 13 Apr 2010 19:48:56 -0400
Message-ID: <Pine.A41.4.58.1004131932350.2609662@f1n11.sp2net.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0063862974603316775=="

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


If we want to distinguish between true NAs and nan/inf (as we
probably should), some other design questions come up, as a
consequence of the fact that we would be allowing non-finite
values in series and scalar variables. (Unless, that is, we make
it an error to put non-finite values into such variables.)

I presume that in simple, per observation, calculations such as y
= log(x) or y = x*z we'd want to let IEEE rules prevail, but what
about more complex calculations?

At present we automatically exclude observations with NAs from
regression calculations, means and variances and so on.  Should we
do the same for nan/inf, or should we let IEEE rules prevail -- or
should we add a "set" switch to control this?

A practical use case is this:

series lx = log(x)
ols y 0 lx

where the series x contains non-positive values. Right now the bad
log x values are converted to NA and skipped. If we leave them as
nan or -inf then what should we do?

Allin


--===============0063862974603316775==--


From cottrell@wfu.edu Tue Apr 13 20:26:14 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Tue, 13 Apr 2010 20:26:12 -0400
Message-ID: <Pine.A41.4.58.1004132008430.2646290@f1n11.sp2net.wfu.edu>
In-Reply-To: alpine.DEB.2.00.1004131909390.31200@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4602500937466970969=="

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


On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:

> On Tue, 13 Apr 2010, Berend Hasselman wrote:
> > I feel that The R and Octave result of NA for 0*NA is perfect reasonable
> > (in a numeric context). I prefer it.
>
> Matter of taste.

Actually, I think it's a bit more than a matter of taste. If a
program evaluates 0*NA as NA I submit that shows that the program
does not implement the concept of "NA" as missing value.

The original source of "true" NAs in econometrics is observations
that were not made, were lost, or are otherwise unavailable. In
that context, as Jack said, "NA" is a place-holder for an unknown
value, but if it's the unknown value of a measurable quantity it
cannot be infinity or "Not a Number" (which is a place-holder for
a mathematical error), and multiplication by zero yields zero for
any such unknown but in principle valid value.

If a program has 0*NA = NA it is treating NAs as if they were
nans, which in general is not correct (though is is convenient for
the coder not to have to make the distinction).

Allin




--===============4602500937466970969==--


From talhayalta@gmail.com Wed Apr 14 01:42:53 2010
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Wed, 14 Apr 2010 08:42:50 +0300
Message-ID: <r2w5b1988aa1004132242r4a45e83byb914fdd221fccd6@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.1004132008430.2646290@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2434297184302899475=="

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

Sorry for joining late. I think gretl handles missing values rather
well. I am saying this because I have applied the so called Wilkinson
Tests to gretl, which assesses the handling of missing values among
other basic statistical functionality. (The test results are available
here: http://ideas.repec.org/h/ehu/ehucha/01-16.html )

Suppose we have a series called MISS consisting of missing values
series NEW =MISS+1
returns all missing values because we cannot know what happens if 1 is
added to a missing (unknown) number.
series NEW=MISS*0
on the other hand returns zeroes because we know (as Allin mentioned)
the result here.
Similarly
series NEW=MISS/0
returns missing values.

This behavior is, of course, valid when all values are numerical and
finite, which is IMO OK considering our standard methods such as using
dummies etc. Finally, I have to mention that Eviews retuns
MISS*0=MISS.
Cheers
Talha



On Wed, Apr 14, 2010 at 3:26 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
>
> On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:
>
>> On Tue, 13 Apr 2010, Berend Hasselman wrote:
>> > I feel that The R and Octave result of NA for 0*NA is perfect reasonable
>> > (in a numeric context). I prefer it.
>>
>> Matter of taste.
>
> Actually, I think it's a bit more than a matter of taste. If a
> program evaluates 0*NA as NA I submit that shows that the program
> does not implement the concept of "NA" as missing value.
>
> The original source of "true" NAs in econometrics is observations
> that were not made, were lost, or are otherwise unavailable. In
> that context, as Jack said, "NA" is a place-holder for an unknown
> value, but if it's the unknown value of a measurable quantity it
> cannot be infinity or "Not a Number" (which is a place-holder for
> a mathematical error), and multiplication by zero yields zero for
> any such unknown but in principle valid value.
>
> If a program has 0*NA = NA it is treating NAs as if they were
> nans, which in general is not correct (though is is convenient for
> the coder not to have to make the distinction).
>
> 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)
--


--===============2434297184302899475==--


From talhayalta@gmail.com Wed Apr 14 01:49:54 2010
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Wed, 14 Apr 2010 08:49:52 +0300
Message-ID: <g2i5b1988aa1004132249p1ebb037fy97362502059cabea@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.1004131932350.2609662@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6831911579323290752=="

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

I would think infinity as an outlier :-) Also, nothing can be done
with something not a number from a regression point of view.
Talha



On Wed, Apr 14, 2010 at 2:48 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
>
> If we want to distinguish between true NAs and nan/inf (as we
> probably should), some other design questions come up, as a
> consequence of the fact that we would be allowing non-finite
> values in series and scalar variables. (Unless, that is, we make
> it an error to put non-finite values into such variables.)
>
> I presume that in simple, per observation, calculations such as y
> = log(x) or y = x*z we'd want to let IEEE rules prevail, but what
> about more complex calculations?
>
> At present we automatically exclude observations with NAs from
> regression calculations, means and variances and so on.  Should we
> do the same for nan/inf, or should we let IEEE rules prevail -- or
> should we add a "set" switch to control this?
>
> A practical use case is this:
>
> series lx = log(x)
> ols y 0 lx
>
> where the series x contains non-positive values. Right now the bad
> log x values are converted to NA and skipped. If we leave them as
> nan or -inf then what should we 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)
--


--===============6831911579323290752==--


From talhayalta@gmail.com Wed Apr 14 02:01:16 2010
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missing dummies?
Date: Wed, 14 Apr 2010 09:01:14 +0300
Message-ID: <i2w5b1988aa1004132301z4ad8ec12i214ee83b03bce43b@mail.gmail.com>
In-Reply-To: A878B373-8374-4E4D-88F7-9CDC554C7BCF@xs4all.nl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9008361398253077497=="

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

Considering the further cases that Brend brings, I also think
something needs to be done here. These are dangerous in the sense of
creating seriously misleading results.
Talha


On Tue, Apr 13, 2010 at 9:02 PM, Berend Hasselman <bhh(a)xs4all.nl> wrote:
>
> On 13-04-2010, at 19:02, Lee Adkins wrote:
>
>> Hi all,
>> Although the logic of what Jack says is valid, I think the current impleme=
ntation is a bit confusing--basically because it's unexpected. =C2=A0I can't =
think of another program that does this, though I'm sure there must be some. =
=C2=A0The others that I use (R, Stata, Gauss) don't.
>>
>> Since the coding of dummy variable is arbitrary (e.g., you could use 1 -1)=
 why should zero be treated differently from all other scalars and real numbe=
rs? =C2=A0I think it could lead to some unexpected results (for those who don=
't dive into the manual). =C2=A0For the sake of consistency I would prefer th=
at all numbers be treated alike.
>>
>> On the other hand if the zero*NA were treated as the exception and =C2=A0h=
andled with a special command, that would make more logical sense--at least t=
o me. =C2=A0I find the current implementation is kind of confusing, especiall=
y for gretl's main audience (non programmers like me) ans students coming fro=
m other programs that treat the interaction likewise (e.g., Stata and R). =C2=
=A0 Just my 2 cents, but I think 'm with Berend on this one....
>
> I just did this in a Gretl console
>
> gretl console: type 'help' for a list of commands
> ? scalar x
>
> ? x=3D10/0
> Replaced scalar x =3D NA
> Warning: generated missing values
>
> ? y=3D0*x
> Generated scalar y =3D 0
>
> ? z1 =3D tanh(y)
> Generated scalar z1 =3D 0
>
> ? z1 =3D tanh(10/0)
> Replaced scalar z1 =3D NA
>
> ? z1 =3D tanh(10/0.0000000000000000000001)
> Replaced scalar z1 =3D 1
>
> ? a=3D0*(10/0)
> Generated scalar a =3D 0
>
> This doesn't make sense to me.
> This is dangerous.
>
> Berend
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>



--=20
=E2=80=9CRemember 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.=E2=80=9D - Benjamin Franklin (1706-1790)
--


--===============9008361398253077497==--


From svetosch@gmx.net Wed Apr 14 12:04:04 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Wed, 14 Apr 2010 18:03:46 +0200
Message-ID: <4BC5E762.8020506@gmx.net>
In-Reply-To: Pine.A41.4.58.1004131932350.2609662@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5701421696902158248=="

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

Hi,
I appreciate it that the problem is being properly and thoroughly
addressed, but before I can comment (if at all) on such fundamental
stuff I need to think about it in a quiet moment. Right now I'm not sure
when that will be.

cheers,
sven

Allin Cottrell schrieb:
> If we want to distinguish between true NAs and nan/inf (as we
> probably should), some other design questions come up, as a
> consequence of the fact that we would be allowing non-finite
> values in series and scalar variables. (Unless, that is, we make
> it an error to put non-finite values into such variables.)
> 
> I presume that in simple, per observation, calculations such as y
> = log(x) or y = x*z we'd want to let IEEE rules prevail, but what
> about more complex calculations?
> 
> At present we automatically exclude observations with NAs from
> regression calculations, means and variances and so on.  Should we
> do the same for nan/inf, or should we let IEEE rules prevail -- or
> should we add a "set" switch to control this?
> 
> A practical use case is this:
> 
> series lx = log(x)
> ols y 0 lx
> 
> where the series x contains non-positive values. Right now the bad
> log x values are converted to NA and skipped. If we leave them as
> nan or -inf then what should we do?
> 
> Allin
> 
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
> 


--===============5701421696902158248==--


From marcin@nsb.pl Wed Apr 14 16:18:46 2010
From: Marcin =?utf-8?q?B=C5=82a=C5=BCejowski?= <marcin@nsb.pl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl and openmp
Date: Wed, 14 Apr 2010 22:18:41 +0200
Message-ID: <4BC62321.8040904@wrzosy.nsb.pl>
In-Reply-To: Pine.A41.4.58.1003232321190.2650456@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8218310631728891154=="

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

Hi,
I send results of 2 tests ran on Pentium 4 HyperThreading (which is not 
true multicore CPU) - machine: Dell PowerEdge 400SC and Core2 Duo - 
machine: Sony Vaio VGN-FW51JF.

Marcin

--------------------------------------------------------
Pentium 4 HyperThreading
With OpenMP:
     40000:   0,30 (   0,133 Mflops)
    160000:   0,80 (   0,199 Mflops)
    640000:   2,24 (   0,286 Mflops)
   2560000:   8,03 (   0,319 Mflops)
10240000:  31,74 (   0,323 Mflops)

Without OpenMP:
     40000:   0,20 (   0,200 Mflops)
    160000:   0,57 (   0,281 Mflops)
    640000:   2,04 (   0,314 Mflops)
   2560000:   7,99 (   0,320 Mflops)
10240000:  31,78 (   0,322 Mflops)
--------------------------------------------------------
Core2 Duo
With OpenMP:
     40000:   0,22 (   0,178 Mflops)
    160000:   0,66 (   0,243 Mflops)
    640000:   1,84 (   0,348 Mflops)
   2560000:   3,46 (   0,740 Mflops)
10240000:  12,33 (   0,830 Mflops)

Without OpenMP:
     40000:   0,16 (   0,250 Mflops)
    160000:   0,49 (   0,327 Mflops)
    640000:   1,61 (   0,398 Mflops)
   2560000:   5,83 (   0,439 Mflops)
10240000:  23,63 (   0,433 Mflops)
--------------------------------------------------------



W dniu 24.03.2010 04:44, Allin Cottrell pisze:
> As some of you know, we're currently experimenting with openmp in
> gretl. When building from CVS, use of openmp is the default (if
> openmp is supported on the host) unless you pass the option
> --disable-openmp to the configure script. In addition the current
> snapshots for Windows and OS X are built with openmp support
> (using gcc 4.4.3 and gcc 4.2.4 respectively).
>
> This note is just to inform you about the state of play, and to
> invite submission of test results if people would like to do that.
>
> Right now, we use openmp only for gretl's native matrix
> multiplication. So it'll get used (assuming you have at least two
> cores) if you do matrix multiplication in a script, or call a
> function that does matrix multiplication (such as qform), or use a
> built-in command that happens to call matrix multiplication. If we
> decide it's a good idea, we could use openmp directives in other
> gretl code (but as along as we rely on lapack for much of our
> number-crunching, and as long as lapack is not available in a
> parallelized form, the scope for threading will remain somewhat
> limited).
>
> In a typical current use situation, with gretl running on a
> dual-core machine where there's little other demand being placed
> on the processors, the asymptotic speed-up from openmp should be
> close to a factor of two. However, it takes a big calculation to
> get close to the asymptote, and we've found that with small to
> moderate sized matrices the overhead from starting and stopping
> threads dominates, producing a slowdown relative to serial code.
> This is similar to what we found with regard to the ATLAS
> optimized blas; see
> http://ricardo.ecn.wfu.edu/~cottrell/tmp/gretl_speed.html
>
> Anyway, in case anyone would like to test I'm attaching a matrix
> multiplication script that Jack wrote. Right now this is mostly
> useful for people building gretl from source, since you want to
> run timings both with and without MP, which requires rebuilding.
> But if you're currently using a snapshot from before yesterday
> (build date 2010-03-21 or earlier) you could run the script, then
> download a current snapshot and run it again.
>
> Allin
>
>
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel


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




--===============8218310631728891154==--


From G.A.Hughes@ed.ac.uk Wed Apr 14 17:52:58 2010
From: Gordon Hughes <G.A.Hughes@ed.ac.uk>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Wed, 14 Apr 2010 22:52:49 +0100
Message-ID: <E1O2AVz-0004BX-HW@relay05.mail.eu.clara.net>
In-Reply-To: mailman.63.1271260806.21718.gretl-devel@lists.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3784576663864094710=="

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

Can I raise a dissenting voice?  Do you REALLY want to expend the 
effort to distinguishing between NA and NaN in every single procedure 
and (presumably) every function, etc?  It would be even worse if you 
added +/-Inf.  My reaction is that there are better ways to spend 
time in developing the program.

Anyone learning statistics or econometrics rapidly comes across the 
need to deal with missing values of several different 
kinds.  Recognising that lx=log(x) for x <=0 causes a problem is a 
very elementary and early lesson.  Masking it by, for example, 
setting lx=-Inf is likely to mislead.  Since this would be very 
different from what most other programs do, it is likely to generate 
more problems of consistency across analyses performed using 
different packages.

As far as I understand, the original argument was generated by the 
question: should 0*NA be 0 or NA?  My personal view is that it should 
always be NA because it is always possible for the user to override 
this result by explicitly recognising that NA is really NaN and using 
conditional generate statements.  The default of generating a missing 
value when there is any doubt is easily addressed by the user if a 
different result is required, but it is much safer for the unwary.

Gordon Hughes


>If we want to distinguish between true NAs and nan/inf (as we
>probably should), some other design questions come up, as a
>consequence of the fact that we would be allowing non-finite
>values in series and scalar variables. (Unless, that is, we make
>it an error to put non-finite values into such variables.)
>
>I presume that in simple, per observation, calculations such as y
>= log(x) or y = x*z we'd want to let IEEE rules prevail, but what
>about more complex calculations?
>
>At present we automatically exclude observations with NAs from
>regression calculations, means and variances and so on.  Should we
>do the same for nan/inf, or should we let IEEE rules prevail -- or
>should we add a "set" switch to control this?
>
>A practical use case is this:
>
>series lx = log(x)
>ols y 0 lx
>
>where the series x contains non-positive values. Right now the bad
>log x values are converted to NA and skipped. If we leave them as
>nan or -inf then what should we do?
>
>Allin


--===============3784576663864094710==--


From helioxentric@gmail.com Wed Apr 14 19:14:02 2010
From: =?utf-8?q?H=C3=A9lio?= Guilherme <helioxentric@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Thu, 15 Apr 2010 00:13:59 +0100
Message-ID: <i2k5be765951004141613maec1f745ob8c61f7cf78b271b@mail.gmail.com>
In-Reply-To: E1O2AVz-0004BX-HW@relay05.mail.eu.clara.net
Content-Type: multipart/mixed; boundary="===============1255742604069292436=="

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

SSB0b3RhbGx5IGFncmVlIHdpdGggR29yZG9uLiBTcGVjaWFsbHkgb24gMCpOQSA9IE5BIHRvIGF2
b2lkIHVud2FudGVkIHJlc3VsdHMuPGJyPkkgZGlkIHJlYWQgQWxsaW4mIzM5O3MgZXhwbGFuYXRp
b24gb24gdGhpcywgYW5kIGhlIGlzIGFsc28gcmlnaHQuIE1heWJlIHRoZXJlIGlzIHRoZSBuZWVk
IHRvIGFzayB0aGUgdXNlciB3aGF0IHRvIGRvIGluIHRoZXNlIHNwZWNpZmljIHNpdHVhdGlvbnMs
IG9yIGlzc3VpbmcgYSB3YXJuaW5nIG9uIHRoZSBhdXRvbWF0ZWQgZGVjaXNpb24uPGJyPgo8YnI+
Rm9yIGFkdmFuY2VkIHVzZXJzLCBzb21lIHBhcmFtZXRlciwgZmxhZyBvciBlbnZpcm9ubWVudGFs
IHZhcmlhYmxlIGNvdWxkIHNldCB0aGUgd2FudGVkIGJlaGF2aW9yLjxicj48YnI+SMOpbGlvPGJy
Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBBcHIgMTQsIDIwMTAgYXQgMTA6
NTIgUE0sIEdvcmRvbiBIdWdoZXMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86
Ry5BLkh1Z2hlc0BlZC5hYy51ayI+Ry5BLkh1Z2hlc0BlZC5hYy51azwvYT4mZ3Q7PC9zcGFuPiB3
cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjog
MHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy
MDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPkNhbiBJIHJhaXNlIGEgZGlzc2VudGluZyB2b2ljZT8g
wqBEbyB5b3UgUkVBTExZIHdhbnQgdG8gZXhwZW5kIHRoZTxicj4KZWZmb3J0IHRvIGRpc3Rpbmd1
aXNoaW5nIGJldHdlZW4gTkEgYW5kIE5hTiBpbiBldmVyeSBzaW5nbGUgcHJvY2VkdXJlPGJyPgph
bmQgKHByZXN1bWFibHkpIGV2ZXJ5IGZ1bmN0aW9uLCBldGM/IMKgSXQgd291bGQgYmUgZXZlbiB3
b3JzZSBpZiB5b3U8YnI+CmFkZGVkICsvLUluZi4gwqBNeSByZWFjdGlvbiBpcyB0aGF0IHRoZXJl
IGFyZSBiZXR0ZXIgd2F5cyB0byBzcGVuZDxicj4KdGltZSBpbiBkZXZlbG9waW5nIHRoZSBwcm9n
cmFtLjxicj4KPGJyPgpBbnlvbmUgbGVhcm5pbmcgc3RhdGlzdGljcyBvciBlY29ub21ldHJpY3Mg
cmFwaWRseSBjb21lcyBhY3Jvc3MgdGhlPGJyPgpuZWVkIHRvIGRlYWwgd2l0aCBtaXNzaW5nIHZh
bHVlcyBvZiBzZXZlcmFsIGRpZmZlcmVudDxicj4Ka2luZHMuIMKgUmVjb2duaXNpbmcgdGhhdCBs
eD1sb2coeCkgZm9yIHggJmx0Oz0wIGNhdXNlcyBhIHByb2JsZW0gaXMgYTxicj4KdmVyeSBlbGVt
ZW50YXJ5IGFuZCBlYXJseSBsZXNzb24uIMKgTWFza2luZyBpdCBieSwgZm9yIGV4YW1wbGUsPGJy
PgpzZXR0aW5nIGx4PS1JbmYgaXMgbGlrZWx5IHRvIG1pc2xlYWQuIMKgU2luY2UgdGhpcyB3b3Vs
ZCBiZSB2ZXJ5PGJyPgpkaWZmZXJlbnQgZnJvbSB3aGF0IG1vc3Qgb3RoZXIgcHJvZ3JhbXMgZG8s
IGl0IGlzIGxpa2VseSB0byBnZW5lcmF0ZTxicj4KbW9yZSBwcm9ibGVtcyBvZiBjb25zaXN0ZW5j
eSBhY3Jvc3MgYW5hbHlzZXMgcGVyZm9ybWVkIHVzaW5nPGJyPgpkaWZmZXJlbnQgcGFja2FnZXMu
PGJyPgo8YnI+CkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBvcmlnaW5hbCBhcmd1bWVudCB3
YXMgZ2VuZXJhdGVkIGJ5IHRoZTxicj4KcXVlc3Rpb246IHNob3VsZCAwKk5BIGJlIDAgb3IgTkE/
IMKgTXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IGl0IHNob3VsZDxicj4KYWx3YXlzIGJlIE5BIGJl
Y2F1c2UgaXQgaXMgYWx3YXlzIHBvc3NpYmxlIGZvciB0aGUgdXNlciB0byBvdmVycmlkZTxicj4K
dGhpcyByZXN1bHQgYnkgZXhwbGljaXRseSByZWNvZ25pc2luZyB0aGF0IE5BIGlzIHJlYWxseSBO
YU4gYW5kIHVzaW5nPGJyPgpjb25kaXRpb25hbCBnZW5lcmF0ZSBzdGF0ZW1lbnRzLiDCoFRoZSBk
ZWZhdWx0IG9mIGdlbmVyYXRpbmcgYSBtaXNzaW5nPGJyPgp2YWx1ZSB3aGVuIHRoZXJlIGlzIGFu
eSBkb3VidCBpcyBlYXNpbHkgYWRkcmVzc2VkIGJ5IHRoZSB1c2VyIGlmIGE8YnI+CmRpZmZlcmVu
dCByZXN1bHQgaXMgcmVxdWlyZWQsIGJ1dCBpdCBpcyBtdWNoIHNhZmVyIGZvciB0aGUgdW53YXJ5
Ljxicj4KPGZvbnQgY29sb3I9IiM4ODg4ODgiPjxicj4KR29yZG9uIEh1Z2hlczxicj4KPC9mb250
PjxkaXY+PGRpdj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+PGJyPgo8YnI+CiZndDtJZiB3ZSB3YW50
IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdHJ1ZSBOQXMgYW5kIG5hbi9pbmYgKGFzIHdlPGJyPgom
Z3Q7cHJvYmFibHkgc2hvdWxkKSwgc29tZSBvdGhlciBkZXNpZ24gcXVlc3Rpb25zIGNvbWUgdXAs
IGFzIGE8YnI+CiZndDtjb25zZXF1ZW5jZSBvZiB0aGUgZmFjdCB0aGF0IHdlIHdvdWxkIGJlIGFs
bG93aW5nIG5vbi1maW5pdGU8YnI+CiZndDt2YWx1ZXMgaW4gc2VyaWVzIGFuZCBzY2FsYXIgdmFy
aWFibGVzLiAoVW5sZXNzLCB0aGF0IGlzLCB3ZSBtYWtlPGJyPgomZ3Q7aXQgYW4gZXJyb3IgdG8g
cHV0IG5vbi1maW5pdGUgdmFsdWVzIGludG8gc3VjaCB2YXJpYWJsZXMuKTxicj4KJmd0Ozxicj4K
Jmd0O0kgcHJlc3VtZSB0aGF0IGluIHNpbXBsZSwgcGVyIG9ic2VydmF0aW9uLCBjYWxjdWxhdGlv
bnMgc3VjaCBhcyB5PGJyPgomZ3Q7PSBsb2coeCkgb3IgeSA9IHgqeiB3ZSYjMzk7ZCB3YW50IHRv
IGxldCBJRUVFIHJ1bGVzIHByZXZhaWwsIGJ1dCB3aGF0PGJyPgomZ3Q7YWJvdXQgbW9yZSBjb21w
bGV4IGNhbGN1bGF0aW9ucz88YnI+CiZndDs8YnI+CiZndDtBdCBwcmVzZW50IHdlIGF1dG9tYXRp
Y2FsbHkgZXhjbHVkZSBvYnNlcnZhdGlvbnMgd2l0aCBOQXMgZnJvbTxicj4KJmd0O3JlZ3Jlc3Np
b24gY2FsY3VsYXRpb25zLCBtZWFucyBhbmQgdmFyaWFuY2VzIGFuZCBzbyBvbi4gwqBTaG91bGQg
d2U8YnI+CiZndDtkbyB0aGUgc2FtZSBmb3IgbmFuL2luZiwgb3Igc2hvdWxkIHdlIGxldCBJRUVF
IHJ1bGVzIHByZXZhaWwgLS0gb3I8YnI+CiZndDtzaG91bGQgd2UgYWRkIGEgJnF1b3Q7c2V0JnF1
b3Q7IHN3aXRjaCB0byBjb250cm9sIHRoaXM/PGJyPgomZ3Q7PGJyPgomZ3Q7QSBwcmFjdGljYWwg
dXNlIGNhc2UgaXMgdGhpczo8YnI+CiZndDs8YnI+CiZndDtzZXJpZXMgbHggPSBsb2coeCk8YnI+
CiZndDtvbHMgeSAwIGx4PGJyPgomZ3Q7PGJyPgomZ3Q7d2hlcmUgdGhlIHNlcmllcyB4IGNvbnRh
aW5zIG5vbi1wb3NpdGl2ZSB2YWx1ZXMuIFJpZ2h0IG5vdyB0aGUgYmFkPGJyPgomZ3Q7bG9nIHgg
dmFsdWVzIGFyZSBjb252ZXJ0ZWQgdG8gTkEgYW5kIHNraXBwZWQuIElmIHdlIGxlYXZlIHRoZW0g
YXM8YnI+CiZndDtuYW4gb3IgLWluZiB0aGVuIHdoYXQgc2hvdWxkIHdlIGRvPzxicj4KJmd0Ozxi
cj4KJmd0O0FsbGluPGJyPgo8YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPgpHcmV0bC1kZXZlbCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1h
aWx0bzpHcmV0bC1kZXZlbEBsaXN0cy53ZnUuZWR1Ij5HcmV0bC1kZXZlbEBsaXN0cy53ZnUuZWR1
PC9hPjxicj4KPGEgaHJlZj0iaHR0cDovL2xpc3RzLndmdS5lZHUvbWFpbG1hbi9saXN0aW5mby9n
cmV0bC1kZXZlbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy53ZnUuZWR1L21haWxtYW4v
bGlzdGluZm8vZ3JldGwtZGV2ZWw8L2E+PGJyPgo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k
aXY+PGJyPgo=

--===============1255742604069292436==--


From cottrell@wfu.edu Wed Apr 14 20:31:16 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] bug with missings, dummies (and panel?)
Date: Wed, 14 Apr 2010 20:31:15 -0400
Message-ID: <Pine.A41.4.58.1004142026120.3100690@f1n11.sp2net.wfu.edu>
In-Reply-To: r2w5b1988aa1004132242r4a45e83byb914fdd221fccd6@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4868042026137051832=="

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


On Wed, 14 Apr 2010, Talha Yalta wrote:

> Sorry for joining late. I think gretl handles missing values
> rather well. I am saying this because I have applied the so
> called Wilkinson Tests to gretl, which assesses the handling of
> missing values among other basic statistical functionality. (The
> test results are available here:
> http://ideas.repec.org/h/ehu/ehucha/01-16.html )
>
> Suppose we have a series called MISS consisting of missing
> values series NEW =MISS+1 returns all missing values because we
> cannot know what happens if 1 is added to a missing (unknown)
> number. series NEW=MISS*0 on the other hand returns zeroes
> because we know (as Allin mentioned) the result here.

Thanks, Talha. It's nice to get third-party confirmation (via
Wilkinson) that gretl is doing the right thing with 0*missing,
even if we're the only econometrics program to do so (though I
doubt that is the case).

Allin



--===============4868042026137051832==--


From cottrell@wfu.edu Wed Apr 14 21:28:20 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Wed, 14 Apr 2010 21:28:19 -0400
Message-ID: <Pine.A41.4.58.1004142033530.3100690@f1n11.sp2net.wfu.edu>
In-Reply-To: E1O2AVz-0004BX-HW@relay05.mail.eu.clara.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2856319973449984061=="

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


On Wed, 14 Apr 2010, Gordon Hughes wrote:

> Can I raise a dissenting voice?  Do you REALLY want to expend the
> effort to distinguishing between NA and NaN in every single procedure
> and (presumably) every function, etc?  It would be even worse if you
> added +/-Inf.  My reaction is that there are better ways to spend
> time in developing the program.

I have no desire to spend a lot of time in this area. I suspect
there's an intractable problem here, which has to be resolved by
fiat. In principle, NA and NaN are different things, which is
particularly apparent in the case of evaluating 0*NA versus 0*NaN.

The statistical programs that we've had reports on to date on this
list resolve the issue by treating NAs as if they were NaNs; gretl
at present resolves it by treating NaNs as if they were NAs.
Neither of these resolutions is "correct". Is it worth trying to
maintain a consistent distinction between the two categories of
non-valid numbers? I don't know, though I do know it would be a
lot of work.

Allin

--===============2856319973449984061==--


From svetosch@gmx.net Thu Apr 15 08:07:23 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] --robust option not documented in 'panel' command
Date: Thu, 15 Apr 2010 14:07:03 +0200
Message-ID: <4BC70167.3040608@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2220691844412438445=="

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

Hi,

I just read in the manual (and saw in the GUI dialog) that there are
robust standard errors for the panel fixed effects estimator.

Shouldn't that be also documented in the built-in command reference for
the panel command? I mean it's ok to refer to the manual for details,
but '--robust' should at least be included in the options list, no?

thanks,
sven

--===============2220691844412438445==--


From svetosch@gmx.net Thu Apr 15 09:50:54 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] the arbond GUI dialog...
Date: Thu, 15 Apr 2010 15:50:29 +0200
Message-ID: <4BC719A5.9050907@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6779624916318242708=="

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

... doesn't seem to remember the settings (AR, lagorder, time dummies)

thanks,
sven

--===============6779624916318242708==--


From svetosch@gmx.net Thu Apr 15 09:57:23 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] other cosmetic issues
Date: Thu, 15 Apr 2010 15:57:08 +0200
Message-ID: <4BC71B34.4060009@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0739002480704133577=="

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

FWIW:

* the time dummies in fixed effects ("dt_1") are labeled differently
from arbond ("T1")

* the tab-key or arrow-key circulation order is odd in the dialog how to
interpret a dataset (undated, time series, panel)

cheers,
sven

--===============0739002480704133577==--


From svetosch@gmx.net Thu Apr 15 10:09:23 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] the arbond GUI dialog...
Date: Thu, 15 Apr 2010 16:09:07 +0200
Message-ID: <4BC71E03.6050609@gmx.net>
In-Reply-To: 4BC719A5.9050907@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3981891657053851221=="

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

Sven Schreiber schrieb:
> ... doesn't seem to remember the settings (AR, lagorder, time dummies)
> 

and neither does the standard 'panel' dialog (time dummies, robust
errors tickboxes)

(sorry for the email flood today, it always happens when I try some new
area in gretl...)

thanks,
sven

--===============3981891657053851221==--


From cottrell@wfu.edu Thu Apr 15 11:45:21 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] --robust option not documented in 'panel' command
Date: Thu, 15 Apr 2010 11:45:21 -0400
Message-ID: <Pine.A41.4.58.1004151144200.2916540@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC70167.3040608@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2956542568028940619=="

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


On Thu, 15 Apr 2010, Sven Schreiber wrote:

> I just read in the manual (and saw in the GUI dialog) that there are
> robust standard errors for the panel fixed effects estimator.
>
> Shouldn't that be also documented in the built-in command reference for
> the panel command?

Yes. That's now added in CVS.

Allin

--===============2956542568028940619==--


From henrique.coelho@gmail.com Thu Apr 15 15:38:10 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] VAR translation problem?
Date: Thu, 15 Apr 2010 16:30:28 -0300
Message-ID: <l2jb3173c601004151230m7d10fb99u409e551c7541cb25@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============6849917416802215568=="

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

RGVhciBHcmV0bCBUZWFtLDxicj48YnI+V2hlbiBJIHJ1biB0aGUgbm9ybWFsaXR5IHRlc3QgZm9y
IGEgVkFSIChtb2RlbCB3aW5kb3csIFRlc3RzIC0mZ3Q7IE5vcm1hbGl0eSBvZiByZXNpZHVhbHMp
IEkgZ2V0IHRoZSByZXN1bHRzIG9ubHkgaW4gRW5nbGlzaC4gSXMgdGhpcyB0aGUgZGVzaXJlZCBi
ZWhhdmlvdXI/PGJyIGNsZWFyPSJhbGwiPjxicj5CZXN0IHJlZ2FyZHMsIDxicj5IZW5yaXF1ZSBD
LiBkZSBBbmRyYWRlPGJyPgoKRG91dG9yYW5kbyBlbSBFY29ub21pYSBBcGxpY2FkYTxicj5Vbml2
ZXJzaWRhZGUgRmVkZXJhbCBkbyBSaW8gR3JhbmRlIGRvIFN1bDxicj48YSBocmVmPSJodHRwOi8v
d3d3LnVmcmdzLmJyL3BwZ2UiPnd3dy51ZnJncy5ici9wcGdlPC9hPjxicj4K

--===============6849917416802215568==--


From cottrell@wfu.edu Thu Apr 15 16:48:16 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VAR translation problem?
Date: Thu, 15 Apr 2010 16:48:15 -0400
Message-ID: <Pine.A41.4.58.1004151647450.2916540@f1n11.sp2net.wfu.edu>
In-Reply-To: l2jb3173c601004151230m7d10fb99u409e551c7541cb25@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4892454787246808036=="

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


On Thu, 15 Apr 2010, Henrique Andrade wrote:

> When I run the normality test for a VAR (model window, Tests ->
> Normality of residuals) I get the results only in English. Is
> this the desired behaviour?

Those strings are now marked for translation in CVS.

Allin

--===============4892454787246808036==--


From henrique.coelho@gmail.com Thu Apr 15 17:10:55 2010
From: Carlos Henrique Co?lho de Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] VAR translation problem?
Date: Thu, 15 Apr 2010 18:10:46 -0300
Message-ID: <3233239989230533339@unknownmsgid>
In-Reply-To: Pine.A41.4.58.1004151647450.2916540@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3034162273438180748=="

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

Thanks Allin!

Best,
Henrique

Enviado de meu iPhone

Em 15/04/2010, às 17:48, Allin Cottrell <cottrell(a)wfu.edu> escreveu:

>
> On Thu, 15 Apr 2010, Henrique Andrade wrote:
>
>> When I run the normality test for a VAR (model window, Tests ->
>> Normality of residuals) I get the results only in English. Is
>> this the desired behaviour?
>
> Those strings are now marked for translation in CVS.
>
> Allin
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel


--===============3034162273438180748==--


From svetosch@gmx.net Fri Apr 16 18:05:05 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Sat, 17 Apr 2010 00:04:42 +0200
Message-ID: <4BC8DEFA.7080701@gmx.net>
In-Reply-To: Pine.A41.4.58.1004142033530.3100690@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6655128869342005534=="

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

Allin Cottrell schrieb:
> On Wed, 14 Apr 2010, Gordon Hughes wrote:
> 
>> Can I raise a dissenting voice?  Do you REALLY want to expend the
>> effort to distinguishing between NA and NaN in every single procedure
>> and (presumably) every function, etc?  It would be even worse if you
>> added +/-Inf.  My reaction is that there are better ways to spend
>> time in developing the program.
> 
> I have no desire to spend a lot of time in this area. I suspect
> there's an intractable problem here, which has to be resolved by
> fiat. In principle, NA and NaN are different things, which is
> particularly apparent in the case of evaluating 0*NA versus 0*NaN.
> 
> The statistical programs that we've had reports on to date on this
> list resolve the issue by treating NAs as if they were NaNs; 

I don't mean to suggest any implication for gretl's development here,
but it seems to me that this statement is not correct as regards Octave
and R; at least from what quick googling revealed to me, since I'm not
an expert in either of those packages. Both Octave (/Matlab) and R seem
to distinguish NA and NaN (and I guess even +-Inf) AFAICS.

FWIW,
sven

--===============6655128869342005534==--


From cottrell@wfu.edu Fri Apr 16 18:14:09 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA and nan: next steps
Date: Fri, 16 Apr 2010 18:14:08 -0400
Message-ID: <Pine.A41.4.58.1004161812050.2326900@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC8DEFA.7080701@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6275930826435890427=="

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


On Sat, 17 Apr 2010, Sven Schreiber wrote:

> Allin Cottrell schrieb:
> > On Wed, 14 Apr 2010, Gordon Hughes wrote:
> >
> >> Can I raise a dissenting voice?  Do you REALLY want to expend the
> >> effort to distinguishing between NA and NaN in every single procedure
> >> and (presumably) every function, etc?  It would be even worse if you
> >> added +/-Inf.  My reaction is that there are better ways to spend
> >> time in developing the program.
> >
> > I have no desire to spend a lot of time in this area. I suspect
> > there's an intractable problem here, which has to be resolved by
> > fiat. In principle, NA and NaN are different things, which is
> > particularly apparent in the case of evaluating 0*NA versus 0*NaN.
> >
> > The statistical programs that we've had reports on to date on this
> > list resolve the issue by treating NAs as if they were NaNs;
>
> I don't mean to suggest any implication for gretl's development here,
> but it seems to me that this statement is not correct as regards Octave
> and R; at least from what quick googling revealed to me, since I'm not
> an expert in either of those packages. Both Octave (/Matlab) and R seem
> to distinguish NA and NaN (and I guess even +-Inf) AFAICS.

OK, they may make _some_ distinction, but if they evaluate 0*NA as
NA (as we've heard) then they are not doing it right.

Allin

--===============6275930826435890427==--


From cottrell@wfu.edu Fri Apr 16 22:07:41 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] RNA
Date: Fri, 16 Apr 2010 22:07:40 -0400
Message-ID: <Pine.A41.4.58.1004162146120.2965578@f1n11.sp2net.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5202341691429292364=="

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


I've looked further into how R handles NA/Nan/Inf (for
floating-point data). It has its own logic but I'm not sure it's
very intuitive, or something we'd want to emulate.

Yes, R does have distinct internal representations for NA and NaN.
But in some ways NaNs are treated as a subset of NAs, while in
other ways NAs are treated as if they were NaNs. If you do

x <- 0/0 # or
x <- log(-1)

you get a value that gives TRUE for both is.nan(x) and is.na(x).
If you do

x <- NA

you get a value that answers TRUE to is.na(x) but FALSE to
is.nan(x).

NaNs are treated like NAs in that they are automatically skipped
by default when running a linear regression via lm(). Infinities
are not treated the same way. That is, if you have data vectors x
and y and you define one of the x-values to log(-1) you get a
warning,

In log(-1) : NaNs produced

but the relevant observation is skipped by lm(), as in gretl. If
you define an x-value to log(0) (producing -Inf) you get no
warning but the regression fails with

Error in lm.fit(x, y, offset = offset, singular.ok = singular.ok,
...) :
  NA/NaN/Inf in foreign function call (arg 1)

And (as we already knew) NAs are treated as NaNs in that 0*NA =
NA.

Allin

--===============5202341691429292364==--


From lee.adkins@okstate.edu Sat Apr 17 12:30:12 2010
From: Lee Adkins <lee.adkins@okstate.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] NA*0? What about dummy variables?
Date: Sat, 17 Apr 2010 11:30:09 -0500
Message-ID: <q2n596c77551004170930o8def52aeq6fbb910219a8f755@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============1874848908299354866=="

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

RGF0ZTogRnJpLCAxNiBBcHIgMjAxMCAxODoxNDowOCAtMDQwMCAoRURUKTxicj4KRnJvbTogQWxs
aW4gQ290dHJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3R0cmVsbEB3ZnUuZWR1Ij5jb3R0cmVs
bEB3ZnUuZWR1PC9hPiZndDs8YnI+ClN1YmplY3Q6IFJlOiBbR3JldGwtZGV2ZWxdIE5BIGFuZCBu
YW46IG5leHQgc3RlcHM8YnI+ClRvOiBHcmV0bCBkZXZlbG9wbWVudCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHUiPmdyZXRsLWRldmVsQGxpc3RzLndmdS5lZHU8
L2E+Jmd0Ozxicj4KTWVzc2FnZS1JRDogJmx0OzxhIGhyZWY9Im1haWx0bzpQaW5lLkE0MS40LjU4
LjEwMDQxNjE4MTIwNTAuMjMyNjkwMEBmMW4xMS5zcDJuZXQud2Z1LmVkdSI+UGluZS5BNDEuNC41
OC4xMDA0MTYxODEyMDUwLjIzMjY5MDBAZjFuMTEuc3AybmV0LndmdS5lZHU8L2E+Jmd0Ozxicj4K
Q29udGVudC1UeXBlOiBURVhUL1BMQUlOOyBjaGFyc2V0PVVTLUFTQ0lJPGJyPgo8YnI+Cjxicj4K
T24gU2F0LCAxNyBBcHIgMjAxMCwgU3ZlbiBTY2hyZWliZXIgd3JvdGU6PGJyPgo8YnI+CiZndDsg
QWxsaW4gQ290dHJlbGwgc2NocmllYjo8YnI+CiZndDsgJmd0OyBPbiBXZWQsIDE0IEFwciAyMDEw
LCBHb3Jkb24gSHVnaGVzIHdyb3RlOjxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7ICZndDsmZ3Q7IENh
biBJIHJhaXNlIGEgZGlzc2VudGluZyB2b2ljZT8goERvIHlvdSBSRUFMTFkgd2FudCB0byAKZXhw
ZW5kIHRoZTxicj4KJmd0OyAmZ3Q7Jmd0OyBlZmZvcnQgdG8gZGlzdGluZ3Vpc2hpbmcgYmV0d2Vl
biBOQSBhbmQgTmFOIGluIGV2ZXJ5IApzaW5nbGUgcHJvY2VkdXJlPGJyPgomZ3Q7ICZndDsmZ3Q7
IGFuZCAocHJlc3VtYWJseSkgZXZlcnkgZnVuY3Rpb24sIGV0Yz8goEl0IHdvdWxkIGJlIGV2ZW4g
CndvcnNlIGlmIHlvdTxicj4KJmd0OyAmZ3Q7Jmd0OyBhZGRlZCArLy1JbmYuIKBNeSByZWFjdGlv
biBpcyB0aGF0IHRoZXJlIGFyZSBiZXR0ZXIgd2F5cyAKdG8gc3BlbmQ8YnI+CiZndDsgJmd0OyZn
dDsgdGltZSBpbiBkZXZlbG9waW5nIHRoZSBwcm9ncmFtLjxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7
ICZndDsgSSBoYXZlIG5vIGRlc2lyZSB0byBzcGVuZCBhIGxvdCBvZiB0aW1lIGluIHRoaXMgYXJl
YS4gSSAKc3VzcGVjdDxicj4KJmd0OyAmZ3Q7IHRoZXJlJiMzOTtzIGFuIGludHJhY3RhYmxlIHBy
b2JsZW0gaGVyZSwgd2hpY2ggaGFzIHRvIGJlIHJlc29sdmVkIApieTxicj4KJmd0OyAmZ3Q7IGZp
YXQuIEluIHByaW5jaXBsZSwgTkEgYW5kIE5hTiBhcmUgZGlmZmVyZW50IHRoaW5ncywgd2hpY2gg
aXM8YnI+CiZndDsgJmd0OyBwYXJ0aWN1bGFybHkgYXBwYXJlbnQgaW4gdGhlIGNhc2Ugb2YgZXZh
bHVhdGluZyAwKk5BIHZlcnN1cyAKMCpOYU4uPGJyPgomZ3Q7ICZndDs8YnI+CiZndDsgJmd0OyBU
aGUgc3RhdGlzdGljYWwgcHJvZ3JhbXMgdGhhdCB3ZSYjMzk7dmUgaGFkIHJlcG9ydHMgb24gdG8g
ZGF0ZSBvbiAKdGhpczxicj4KJmd0OyAmZ3Q7IGxpc3QgcmVzb2x2ZSB0aGUgaXNzdWUgYnkgdHJl
YXRpbmcgTkFzIGFzIGlmIHRoZXkgd2VyZSBOYU5zOzxicj4KJmd0Ozxicj4KJmd0OyBJIGRvbiYj
Mzk7dCBtZWFuIHRvIHN1Z2dlc3QgYW55IGltcGxpY2F0aW9uIGZvciBncmV0bCYjMzk7cyBkZXZl
bG9wbWVudCAKaGVyZSw8YnI+CiZndDsgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBzdGF0
ZW1lbnQgaXMgbm90IGNvcnJlY3QgYXMgcmVnYXJkcyAKT2N0YXZlPGJyPgomZ3Q7IGFuZCBSOyBh
dCBsZWFzdCBmcm9tIHdoYXQgcXVpY2sgZ29vZ2xpbmcgcmV2ZWFsZWQgdG8gbWUsIHNpbmNlIEkm
IzM5O20gCm5vdDxicj4KJmd0OyBhbiBleHBlcnQgaW4gZWl0aGVyIG9mIHRob3NlIHBhY2thZ2Vz
LiBCb3RoIE9jdGF2ZSAoL01hdGxhYikgYW5kIFIgCnNlZW08YnI+CiZndDsgdG8gZGlzdGluZ3Vp
c2ggTkEgYW5kIE5hTiAoYW5kIEkgZ3Vlc3MgZXZlbiArLUluZikgQUZBSUNTLjxicj4KPGJyPgot
Jmd0O09LLCB0aGV5IG1heSBtYWtlIF9zb21lXyBkaXN0aW5jdGlvbiwgYnV0IGlmIHRoZXkgZXZh
bHVhdGUgMCpOQSBhcy08YnI+Ci0mZ3Q7TkEgKGFzIHdlJiMzOTt2ZSBoZWFyZCkgdGhlbiB0aGV5
IGFyZSBub3QgZG9pbmcgaXQgcmlnaHQuPGJyPjxicj4tJmd0O0FsbGluPGJyPgo8YnI+CkV4Y2Vw
dCBpZiAwIGlzIGEgZHVtbXkgdmFyaWFibGUuoCBJbiB0aGF0IGNhc2UgMCpOQSA9IE5BLiwgMCBp
cyBub3QgcmVhbGx5IHplcm8gaW4gb3JkaW5hbCBkYXRhLS1pdCYjMzk7cyBhcmJpdHJhcnkgYW5k
IGp1c3QgaW5kaWNhdGVzIGEgY2F0ZWdvcnkuoCBPdGhlcndpc2UgcmVjb2RpbmcgdGhlIGR1bW15
IHZhcmlhYmxlcyBjaGFuZ2VzIHRoZSBlZmZlY3RpdmUgZGF0YSBzZXQgYW5kIGxlYWQgdG8gdW5l
eHBlY3RlZCByZXN1bHRzLqAgSWYgMCBpcyByZWFsbHkgemVybyBpbiB0aGUgY2FyZGluYWwgc2Vu
c2UgdGhlbiBncmV0bCBoYW5kbGVzIHRoaXMgY29ycmVjdGx5IGFuZCBSL09jdGF2ZSBkbyBub3Qu
oCBJZiAwIGlzIGEgY2F0ZWdvcmljYWwgdmFyaWFibGUgZ3JldGwgZ2V0cyBpdCB3cm9uZyBhbmQg
T2N0YXZlL1IgZ2V0IGl0IHJpZ2h0LqAgT25lIHNvbHV0aW9uIHdvdWxkIGJlIHRvIGRlY2xhcmUg
ZHVtbXkgdmFyaWFibGVzIGFzIGZhY3RvcnMgKGxpa2UgSmVmZiBSYWNpbmUgZG9lcyBpbiBoaXMg
c2VtaXBhcmFtZXRyaWMgbW9kZWxzKSBzbyB0aGF0IHRoZSBoYW5kbGluZyBvZiB0aGUgaW50ZXJh
Y3Rpb25zIGNvdWxkIGJlIHJpZ2h0IGluIGJvdGggaW5zdGFuY2VzLqAgPGJyPgo8YnI+SSBsaWtl
IHdoYXQgZ3JldGwgZG9lcyBmb3IgY2FyZGluYWwgZGF0YS6gIEJ1dCBJJiMzOTttIG5vdCBzdXJl
IHRoaXMgaXMgd2hhdCBJIHdvdWxkIHdhbnQgZm9yIG9yZGluYWwvY2F0ZWdvcmljYWwgZGF0YS48
YnI+PGJyPkxlZTxicj4K

--===============1874848908299354866==--


From cottrell@wfu.edu Sat Apr 17 12:55:49 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA*0? What about dummy variables?
Date: Sat, 17 Apr 2010 12:55:48 -0400
Message-ID: <Pine.A41.4.58.1004171245330.2523478@f1n11.sp2net.wfu.edu>
In-Reply-To: q2n596c77551004170930o8def52aeq6fbb910219a8f755@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4900649731499414891=="

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


On Sat, 17 Apr 2010, Lee Adkins wrote:

> ->OK, they may make _some_ distinction, but if they evaluate 0*NA as-
> ->NA (as we've heard) then they are not doing it right.
>
> Except if 0 is a dummy variable.  In that case 0*NA = NA., 0 is
> not really zero in ordinal data--it's arbitrary and just
> indicates a category. Otherwise recoding the dummy variables
> changes the effective data set and lead to unexpected results.

Good point. Just thinking it through: If one had (D1: female = 1,
male = 0) and (D2: married = 1, unmarried = 0), and for some
individuals D2 was NA, and then one created an interaction D1*D2,
one would wrongly categorize males of unknown marital status as
unmarried males, if 0*NA = 0. I'll have to think about that.

Allin

--===============4900649731499414891==--


From svetosch@gmx.net Sat Apr 17 17:43:51 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] NA*0? What about dummy variables?
Date: Sat, 17 Apr 2010 23:43:13 +0200
Message-ID: <4BCA2B71.6060001@gmx.net>
In-Reply-To: Pine.A41.4.58.1004171245330.2523478@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4736427317906152308=="

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

Allin Cottrell schrieb:
> On Sat, 17 Apr 2010, Lee Adkins wrote:
> 
>> ->OK, they may make _some_ distinction, but if they evaluate 0*NA as-
>> ->NA (as we've heard) then they are not doing it right.
>>
>> Except if 0 is a dummy variable.  In that case 0*NA = NA., 0 is
>> not really zero in ordinal data--it's arbitrary and just
>> indicates a category. Otherwise recoding the dummy variables
>> changes the effective data set and lead to unexpected results.
> 
> Good point. Just thinking it through: If one had (D1: female = 1,
> male = 0) and (D2: married = 1, unmarried = 0), and for some
> individuals D2 was NA, and then one created an interaction D1*D2,
> one would wrongly categorize males of unknown marital status as
> unmarried males, if 0*NA = 0. I'll have to think about that.
> 
>

Yep, this whole thread started when I was handling dummies and got
unexpected results like that.

Now Lee points out that gretl assumes that NAs are (unknown) numbers on
a cardinal scale. But if you allow me to rephrase myself a little (and
without referring to NaN's this time, which is a related but slightly
different issue):
I am actually also worried about assuming _any_ type of number for NAs.
What does the abbrev. "NA" stand for in English? I can think of at least
two meanings: "not available" or "not applicable". The interpretation of
"not available" may well allow to treat NAs as numbers, but I really
think that "not applicable" will usually not be hiding a meaningful
number underneath. And it seems to me that missing values in
economic/social statistics quite often carry the meaning of "not
applicable". At least they did in my unbalanced panel data set where I
encountered the problems.

All in all, while the cleanest solution may be to introduce and properly
differentiate NAs, NaNs, Infs and all the rest, wouldn't the easiest way
simply be to make any operation on NA return NA, including 0*NA=NA?

cheers,
sven

--===============4736427317906152308==--


From cottrell@wfu.edu Sun Apr 18 17:41:52 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl and openmp
Date: Sun, 18 Apr 2010 17:41:51 -0400
Message-ID: <Pine.A41.4.58.1004181739390.2744826@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BC62321.8040904@wrzosy.nsb.pl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3784440559909720343=="

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


On Wed, 14 Apr 2010, Marcin B�^Bażejowski wrote:

> I send results of 2 tests ran on Pentium 4 HyperThreading (which is not
> true multicore CPU) - machine: Dell PowerEdge 400SC and Core2 Duo -
> machine: Sony Vaio VGN-FW51JF.

Thanks, Marcin. Your Core2 results help to confirm what Jack and I
found: it takes a pretty big matrix to reach the break-even point
for openmp.

Allin




--===============3784440559909720343==--


From marcin@nsb.pl Mon Apr 19 09:20:33 2010
From: Marcin =?utf-8?q?B=C5=82a=C5=BCejowski?= <marcin@nsb.pl>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl and openmp
Date: Mon, 19 Apr 2010 15:20:30 +0200
Message-ID: <4BCC589E.7080107@wrzosy.nsb.pl>
In-Reply-To: Pine.A41.4.58.1004181739390.2744826@f1n11.sp2net.wfu.edu
Content-Type: multipart/mixed; boundary="===============2953361798908540385=="

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

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9
VVRGLTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPHRpdGxlPjwvdGl0bGU+CjwvaGVh
ZD4KPGJvZHkgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI2ZmZmZmZiI+CkhpLDxicj4KaW4gbXkg
b3BpbmlvbiB0aGUgbW9zdCBwcm9kdWN0aXZlIHVzZSBvZiBvcGVubXAgd291bGQgYmUgZGl2aWRp
bmcgbG9vcAppbnRvIHRocmVhZHMuIE1heWJlIHVzZXIgY291bGQgZGVmaW5lIHdpaGljaCBsb29w
IHNob3VsZCBydW4gcGFyYWxsZWwuPGJyPgo8YnI+ClJlZ2FyZHMsPGJyPgpNYXJjaW48YnI+Cjxi
cj4KPGJyPgpXIGRuaXUgMTguMDQuMjAxMCAyMzo0MSwgQWxsaW4gQ290dHJlbGwgcGlzemU6Cjxi
bG9ja3F1b3RlCiBjaXRlPSJtaWQ6UGluZS5BNDEuNC41OC4xMDA0MTgxNzM5MzkwLjI3NDQ4MjZA
ZjFuMTEuc3AybmV0LndmdS5lZHUiCiB0eXBlPSJjaXRlIj4KICA8cHJlIHdyYXA9IiI+Ck9uIFdl
ZCwgMTQgQXByIDIwMTAsIE1hcmNpbiBC77+9XkJhxbxlam93c2tpIHdyb3RlOgoKICA8L3ByZT4K
ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgIDxwcmUgd3JhcD0iIj5JIHNlbmQgcmVzdWx0
cyBvZiAyIHRlc3RzIHJhbiBvbiBQZW50aXVtIDQgSHlwZXJUaHJlYWRpbmcgKHdoaWNoIGlzIG5v
dAp0cnVlIG11bHRpY29yZSBDUFUpIC0gbWFjaGluZTogRGVsbCBQb3dlckVkZ2UgNDAwU0MgYW5k
IENvcmUyIER1byAtCm1hY2hpbmU6IFNvbnkgVmFpbyBWR04tRlc1MUpGLgogICAgPC9wcmU+CiAg
PC9ibG9ja3F1b3RlPgogIDxwcmUgd3JhcD0iIj4KVGhhbmtzLCBNYXJjaW4uIFlvdXIgQ29yZTIg
cmVzdWx0cyBoZWxwIHRvIGNvbmZpcm0gd2hhdCBKYWNrIGFuZCBJCmZvdW5kOiBpdCB0YWtlcyBh
IHByZXR0eSBiaWcgbWF0cml4IHRvIHJlYWNoIHRoZSBicmVhay1ldmVuIHBvaW50CmZvciBvcGVu
bXAuCgpBbGxpbgoKCgogIDwvcHJlPgogIDxwcmUgd3JhcD0iIj4KPGZpZWxkc2V0IGNsYXNzPSJt
aW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KR3JldGwtZGV2ZWwgbWFpbGluZyBsaXN0CjxhIGNsYXNz
PSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpHcmV0bC1kZXZlbEBsaXN0
cy53ZnUuZWR1Ij5HcmV0bC1kZXZlbEBsaXN0cy53ZnUuZWR1PC9hPgo8YSBjbGFzcz0ibW96LXR4
dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vbGlzdHMud2Z1LmVkdS9tYWlsbWFuL2xpc3Rp
bmZvL2dyZXRsLWRldmVsIj5odHRwOi8vbGlzdHMud2Z1LmVkdS9tYWlsbWFuL2xpc3RpbmZvL2dy
ZXRsLWRldmVsPC9hPjwvcHJlPgo8L2Jsb2NrcXVvdGU+Cjxicj4KPGJyPgo8cHJlIGNsYXNzPSJt
b3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gCk1hcmNpbiBCxYJhxbxlam93c2tpCjxhIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cud3J6b3N5Lm5zYi5wbC9+
bWFyY2luLyI+aHR0cDovL3d3dy53cnpvc3kubnNiLnBsL35tYXJjaW4vPC9hPgpHRyMgMjAzMTI3
CjwvcHJlPgo8L2JvZHk+CjwvaHRtbD4K

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

YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6TWFyY2luIEI9QzU9ODJhPUM1PUJDZWpv
d3NraQ0KbjtxdW90ZWQtcHJpbnRhYmxlOkI9QzU9ODJhPUM1PUJDZWpvd3NraTtNYXJjaW4NCmVt
YWlsO2ludGVybmV0Om1hcmNpbkB3cnpvc3kubnNiLnBsDQpub3RlOkdHOiAyMDMxMjcNCngtbW96
aWxsYS1odG1sOlRSVUUNCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K

--===============2953361798908540385==--


From cottrell@wfu.edu Mon Apr 19 19:52:43 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] gretl and openmp
Date: Mon, 19 Apr 2010 19:52:42 -0400
Message-ID: <Pine.A41.4.58.1004191941260.2892022@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BCC589E.7080107@wrzosy.nsb.pl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1122605149846990466=="

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


On Mon, 19 Apr 2010, Marcin B�^Bażejowski wrote:

> in my opinion the most productive use of openmp would be dividing loop
> into threads. Maybe user could define wihich loop should run parallel.

That would certainly be nice, but it would require quite a lot of
thought.

As things stand (if I understand the mechanism correctly) you have
to specify at compile time which code sections are to be
parallelized via openmp. In principle it's possible that gretl
could call a C compiler to build a gretl-loop as a C function with
user-specified parallel code -- a sort of "instant plugin". That
functionality would necessarily be limited to platforms that offer
an openmp-aware C compiler, preferably gcc. It would also require
more knowledge than I currently possess regarding "Just in Time"
compilation ;-)

Allin


--===============1122605149846990466==--


From cottrell@wfu.edu Tue Apr 27 17:55:07 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] time for 1.9.0?
Date: Tue, 27 Apr 2010 17:55:06 -0400
Message-ID: <Pine.A41.4.58.1004271746070.2650432@f1n11.sp2net.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9201830295730956457=="

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


I'm thinking that it's probably time to put out gretl 1.9.0,
which, in light of discussions here a while back, will be the
first (and possibly the last, but we'll see) in a series leading
towards gretl 2.0. (And as such it will spit out warnings for
script constructions that are deprecated and will be removed in
2.0.)

Looking at the change log, we seem to have accumulated enough
fixes and features to justify a release:
http://gretl.sourceforge.net/ChangeLog.html

If anyone knows of any show-stopper bugs that really should be
fixed before releasing 1.9.0, please speak up. And I'd be grateful
if people could find the time to beat on current CVS/snapshot
in case any recent changes have broken things.

Allin Cottrell





--===============9201830295730956457==--


From r.lucchetti@univpm.it Wed Apr 28 09:03:00 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Wed, 28 Apr 2010 15:02:57 +0200
Message-ID: <alpine.DEB.2.00.1004281457150.24370@ec-4.econ.univpm.it>
In-Reply-To: Pine.A41.4.58.1004271746070.2650432@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8896016345700414687=="

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

On Tue, 27 Apr 2010, Allin Cottrell wrote:

>
> I'm thinking that it's probably time to put out gretl 1.9.0,
> which, in light of discussions here a while back, will be the
> first (and possibly the last, but we'll see) in a series leading
> towards gretl 2.0. (And as such it will spit out warnings for
> script constructions that are deprecated and will be removed in
> 2.0.)
>
> Looking at the change log, we seem to have accumulated enough
> fixes and features to justify a release:
> http://gretl.sourceforge.net/ChangeLog.html

I marginally updated the Changelog this morning; yeah, the list is long 
and warrants IMO a new release.

Just to add to my 2 cents to the 1.9-leading-to-2.0 plan: there are still 
some features that I'd like to be in 2.0 which don't have an 
implementation in native code (of course my list is very personal and I'm 
fully open to revise it). I suggest that once that is done, we name that 
version 1.9.9 and we go into "feature freeze" mode (that is, only 
bugfixes). After a reasonable time, we release 2.0.


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

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

--===============8896016345700414687==--


From henrique.coelho@gmail.com Wed Apr 28 14:53:27 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Wed, 28 Apr 2010 15:52:51 -0300
Message-ID: <s2mb3173c601004281152xb4a31ecexb3aca690912bc919@mail.gmail.com>
In-Reply-To: alpine.DEB.2.00.1004281457150.24370@ec-4.econ.univpm.it
Content-Type: multipart/mixed; boundary="===============3744666843804560095=="

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

RGVhciBHcmV0bCBUZWFtLDxicj48YnI+SSB0aGluayB0aGUgUmljY2FyZG8mIzM5O3Mgc3VnZ2Vz
dGlvbiBpcyB2ZXJ5IGdvb2Q6PGJyPjxicj5FbSAyOCBkZSBhYnJpbCBkZSAyMDEwIFJpY2NhcmRv
IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnIubHVjY2hldHRpQHVuaXZwbS5p
dCI+ci5sdWNjaGV0dGlAdW5pdnBtLml0PC9hPiZndDs8L3NwYW4+IGVzY3JldmV1Ojxicj4KCjxi
cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl
IiBzdHlsZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgYm9yZGVyLWxlZnQ6IDFweCBzb2xp
ZCByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+KC4uLikgSSBzdWdnZXN0
IHRoYXQgb25jZSB0aGF0IGlzIGRvbmUsIHdlIG5hbWUgdGhhdCB2ZXJzaW9uIDEuOS45IGFuZCB3
ZSBnbyBpbnRvICZxdW90O2ZlYXR1cmUgZnJlZXplJnF1b3Q7IG1vZGUgKHRoYXQgaXMsIG9ubHkg
YnVnZml4ZXMpLiBBZnRlciBhIHJlYXNvbmFibGUgdGltZSwgd2UgcmVsZWFzZSAyLjAuPGJyPgoK
PC9ibG9ja3F1b3RlPjxkaXY+PGJyPkJlc3QgcmVnYXJkcyw8YnI+SGVucmlxdWU8YnI+PC9kaXY+
PC9kaXY+Cg==

--===============3744666843804560095==--


From cottrell@wfu.edu Wed Apr 28 16:19:26 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Wed, 28 Apr 2010 16:19:25 -0400
Message-ID: <Pine.A41.4.58.1004281618150.2912266@f1n11.sp2net.wfu.edu>
In-Reply-To: s2mb3173c601004281152xb4a31ecexb3aca690912bc919@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1002134327053326364=="

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


On Wed, 28 Apr 2010, Henrique Andrade wrote:

> I think the Riccardo's suggestion is very good:
>
> Em 28 de abril de 2010 Riccardo <r.lucchetti(a)univpm.it> escreveu:
>
> (...) I suggest that once that is done, we name that version 1.9.9 and we go
> > into "feature freeze" mode (that is, only bugfixes). After a reasonable
> > time, we release 2.0.

I agree. As for 1.9.0 I'm trying to shake out a few more bugs but
will put out the release shortly.

Allin

--===============1002134327053326364==--


From henrique.coelho@gmail.com Wed Apr 28 16:34:27 2010
From: Henrique Andrade <henrique.coelho@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Wed, 28 Apr 2010 17:33:56 -0300
Message-ID: <u2mb3173c601004281333vc6031afx154a47fbe66d3176@mail.gmail.com>
In-Reply-To: Pine.A41.4.58.1004281618150.2912266@f1n11.sp2net.wfu.edu
Content-Type: multipart/mixed; boundary="===============6627266759093066165=="

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

RGVhciBBbGxpbiw8YnI+PGJyPkkgdGhpbmsgdGhlIGltcHJvdmVtZW50cyBpbiB0aGUgR3JldGwg
cGxvdCBjb250cm9scyAoZ3JpZCBsaW5lcyBhbmQgYmFycyBvcHRpb25zKSBzaG91bGQgYmUgcGxh
Y2VkIGluIHRoZSBjaGFuZ2UgbG9nIHRvby4gV2hhdCBkbyB5b3UgdGhpbms/PGJyPjxicj5CZXN0
LDxicj5IZW5yaXF1ZTxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTAvNC8yOCBB
bGxpbiBDb3R0cmVsbCA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpjb3R0cmVs
bEB3ZnUuZWR1Ij5jb3R0cmVsbEB3ZnUuZWR1PC9hPiZndDs8L3NwYW4+PGJyPgoKPGJsb2NrcXVv
dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg
Ym9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDog
MWV4OyI+PGRpdiBjbGFzcz0iaW0iPjxicj4KT24gV2VkLCAyOCBBcHIgMjAxMCwgSGVucmlxdWUg
QW5kcmFkZSB3cm90ZTo8YnI+Cjxicj4KJmd0OyBJIHRoaW5rIHRoZSBSaWNjYXJkbyYjMzk7cyBz
dWdnZXN0aW9uIGlzIHZlcnkgZ29vZDo8YnI+CiZndDs8YnI+CiZndDsgRW0gMjggZGUgYWJyaWwg
ZGUgMjAxMCBSaWNjYXJkbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnIubHVjY2hldHRpQHVuaXZwbS5p
dCI+ci5sdWNjaGV0dGlAdW5pdnBtLml0PC9hPiZndDsgZXNjcmV2ZXU6PGJyPgomZ3Q7PGJyPgom
Z3Q7ICguLi4pIEkgc3VnZ2VzdCB0aGF0IG9uY2UgdGhhdCBpcyBkb25lLCB3ZSBuYW1lIHRoYXQg
dmVyc2lvbiAxLjkuOSBhbmQgd2UgZ288YnI+CiZndDsgJmd0OyBpbnRvICZxdW90O2ZlYXR1cmUg
ZnJlZXplJnF1b3Q7IG1vZGUgKHRoYXQgaXMsIG9ubHkgYnVnZml4ZXMpLiBBZnRlciBhIHJlYXNv
bmFibGU8YnI+CiZndDsgJmd0OyB0aW1lLCB3ZSByZWxlYXNlIDIuMC48YnI+Cjxicj4KPC9kaXY+
SSBhZ3JlZS4gQXMgZm9yIDEuOS4wIEkmIzM5O20gdHJ5aW5nIHRvIHNoYWtlIG91dCBhIGZldyBt
b3JlIGJ1Z3MgYnV0PGJyPgp3aWxsIHB1dCBvdXQgdGhlIHJlbGVhc2Ugc2hvcnRseS48YnI+Cjxm
b250IGNvbG9yPSIjODg4ODg4Ij48YnI+CkFsbGluPC9mb250Pjxicj48L2Jsb2NrcXVvdGU+PC9k
aXY+Cg==

--===============6627266759093066165==--


From svetosch@gmx.net Thu Apr 29 04:20:54 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Thu, 29 Apr 2010 10:20:33 +0200
Message-ID: <4BD94151.1050506@gmx.net>
In-Reply-To: Pine.A41.4.58.1004271746070.2650432@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0431091543408600688=="

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

Allin Cottrell schrieb:
> I'm thinking that it's probably time to put out gretl 1.9.0,
> which, in light of discussions here a while back, will be the
> first (and possibly the last, but we'll see) in a series leading
> towards gretl 2.0. 

My understanding was that according to you guys the amount of new
features between 1.8.x and 2.0  should be "massive". That seems to
contradict the possibility that 1.9.0 would be the last of that series, no?


(And as such it will spit out warnings for
> script constructions that are deprecated and will be removed in
> 2.0.)

fine

> 
> Looking at the change log, we seem to have accumulated enough
> fixes and features to justify a release:
> http://gretl.sourceforge.net/ChangeLog.html

yes

cheers,
sven

--===============0431091543408600688==--


From cottrell@wfu.edu Thu Apr 29 08:37:13 2010
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Thu, 29 Apr 2010 08:37:12 -0400
Message-ID: <Pine.A41.4.58.1004290836510.2404656@f1n11.sp2net.wfu.edu>
In-Reply-To: 4BD94151.1050506@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7030468488196122415=="

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


On Thu, 29 Apr 2010, Sven Schreiber wrote:

>
> Allin Cottrell schrieb:
> > I'm thinking that it's probably time to put out gretl 1.9.0,
> > which, in light of discussions here a while back, will be the
> > first (and possibly the last, but we'll see) in a series leading
> > towards gretl 2.0.
>
> My understanding was that according to you guys the amount of new
> features between 1.8.x and 2.0  should be "massive". That seems to
> contradict the possibility that 1.9.0 would be the last of that series, no?

Yes. What Jack said.

Allin

--===============7030468488196122415==--


From talhayalta@gmail.com Fri Apr 30 05:19:14 2010
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] Plot Labels
Date: Fri, 30 Apr 2010 12:19:12 +0300
Message-ID: <q2t5b1988aa1004300219sff8ece1cr232faf877afa0c2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2280403582151041486=="

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

In the "Graph specified vars" menu, all plots except Q-Q plots and X-Y
with control are missing automatic plot titles. I think it could be
worthwhile that all gretl plots have a suitable title by default.

Also, I know that gretl has a tendency to have plot titles in small
letters (although there are exceptions such as the estimated density
plot which has the E capitalized). Is there a reason for this? I don't
know what most people would say but my personal preference is to have
such titles in title format (first letter capitalized).

Cheers
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)
--


--===============2280403582151041486==--


From r.lucchetti@univpm.it Fri Apr 30 05:44:28 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Plot Labels
Date: Fri, 30 Apr 2010 11:44:25 +0200
Message-ID: <alpine.DEB.2.00.1004301142260.12260@ec-4.econ.univpm.it>
In-Reply-To: q2t5b1988aa1004300219sff8ece1cr232faf877afa0c2@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0335259791627616914=="

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

On Fri, 30 Apr 2010, Talha Yalta wrote:

> Also, I know that gretl has a tendency to have plot titles in small
> letters (although there are exceptions such as the estimated density
> plot which has the E capitalized). Is there a reason for this? I don't
> know what most people would say but my personal preference is to have
> such titles in title format (first letter capitalized).

Right-click -> Edit


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

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

--===============0335259791627616914==--


From talhayalta@gmail.com Fri Apr 30 06:02:12 2010
From: Talha Yalta <talhayalta@gmail.com>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Plot Labels
Date: Fri, 30 Apr 2010 13:02:10 +0300
Message-ID: <z2m5b1988aa1004300302re071f37fs2cb9d6270d67a175@mail.gmail.com>
In-Reply-To: alpine.DEB.2.00.1004301142260.12260@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7140981242257118751=="

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

On Fri, Apr 30, 2010 at 12:44 PM, Riccardo (Jack) Lucchetti
<r.lucchetti(a)univpm.it> wrote:
> On Fri, 30 Apr 2010, Talha Yalta wrote:
>
>> Also, I know that gretl has a tendency to have plot titles in small
>> letters (although there are exceptions such as the estimated density
>> plot which has the E capitalized). Is there a reason for this? I don't
>> know what most people would say but my personal preference is to have
>> such titles in title format (first letter capitalized).
>
> Right-click -> Edit
I don't even have to do this because such titles are all in title
format in the Turkish translation ;-)
But seriously, is this something undebatable? How about an option in
the preferences, if not too difficult to implement that is.
Cheers
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)
--


--===============7140981242257118751==--


From svetosch@gmx.net Fri Apr 30 06:16:41 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: [Gretl-devel] trivial cosmetic pseudo-bug
Date: Fri, 30 Apr 2010 12:16:07 +0200
Message-ID: <4BDAADE7.4010108@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3820715272497937342=="

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

Hi,

in the User guide (fresh cvs) on the title page it says "Wake Forest
university" with lowercase u.

-sven

--===============3820715272497937342==--


From r.lucchetti@univpm.it Fri Apr 30 07:04:54 2010
From: Riccardo (Jack) Lucchetti <r.lucchetti@univpm.it>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] Plot Labels
Date: Fri, 30 Apr 2010 13:02:59 +0200
Message-ID: <alpine.DEB.2.00.1004301256130.12260@ec-4.econ.univpm.it>
In-Reply-To: r2k5b1988aa1004300351kf3d08ff5m51dec118806e6deb@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5889476545161362450=="

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

On Fri, 30 Apr 2010, Talha Yalta wrote:

>>>>> Also, I know that gretl has a tendency to have plot titles in small
>>>>> letters (although there are exceptions such as the estimated density
>>>>> plot which has the E capitalized). Is there a reason for this? I don't
>>>>> know what most people would say but my personal preference is to have
>>>>> such titles in title format (first letter capitalized).
>>>>
>>>> Right-click -> Edit
>>>
>>> I don't even have to do this because such titles are all in title
>>> format in the Turkish translation ;-)
>>> But seriously, is this something undebatable? How about an option in
>>> the preferences, if not too difficult to implement that is.
>>
>> Nothing is undebatable, in the proper context. But do you really think gre=
tl
>> should have a capitalisation *policy*?
>
> Why not? I think most people would agree that accurate and
> professional looking visualization is extremely important for a
> scientific package (not that I wish to claim the current plots look
> unprofessional).

I beg to differ. In my humble opinion, "accurate and professional looking=20
visualisation" (which is difficult to define anyway: I am a professional,=20
so are you; I like small letters, you like capital letters. Who's right?=20
Po-tay-to, po-tah-to) has is place, but is dwarfed in importance by=20
computational speed, accuracy, breadth of methods, quality of=20
documentation and so on. If capital letters in plots are so "extremely=20
important" to deserve a formalised policy, my imagination struggles to=20
find something that isn't.


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

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

--===============5889476545161362450==--


From svetosch@gmx.net Fri Apr 30 11:28:38 2010
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-devel@gretlml.univpm.it
Subject: Re: [Gretl-devel] time for 1.9.0?
Date: Fri, 30 Apr 2010 17:28:15 +0200
Message-ID: <4BDAF70F.9030703@gmx.net>
In-Reply-To: Pine.A41.4.58.1004271746070.2650432@f1n11.sp2net.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2031872025695234436=="

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

Allin Cottrell schrieb:

> 
> If anyone knows of any show-stopper bugs that really should be
> fixed before releasing 1.9.0, please speak up. And I'd be grateful
> if people could find the time to beat on current CVS/snapshot
> in case any recent changes have broken things.
> 

With today's cvs version I'm getting a new error (I think it's new, but
it could be that it's triggered by a constellation of input that I
haven't used so far in gretl):

Pressing OK in the VECM dialog gives an error dialog window: "VECM: Rank
0 out ouf bounds." (translated back from German) I didn't specify the
rank to be 0, rather a positive number, of course.

Fairly severe, I'd say...

thanks,
sven

--===============2031872025695234436==--