3:50 a.m.
I recently made some changes so that array indexing in the
context of the "restrict" command starts at 1 in all cases
(previously there was a mixture of 0-base and 1-base).
Working again with matrices lately, I recall that gretl matrices
also use 1-based indexation. So we're consistent.
But is this "right"? Would we be better to standardize on
0-based indexing in all cases? My initial thought was that
1-base is more intuitive for the "punters", but I have to say it
seems odd for matrices. Ox uses 0-base; does R do that too?
Allin.
1:08 p.m.
Hi,
Pr, 2006 08 21 23:50 -0400, Allin Cottrell rašė:
I recently made some changes so that array indexing in the
context of the "restrict" command starts at 1 in all cases
(previously there was a mixture of 0-base and 1-base).
Working again with matrices lately, I recall that gretl matrices
also use 1-based indexation. So we're consistent.
But is this "right"? Would we be better to standardize on
0-based indexing in all cases? My initial thought was that
1-base is more intuitive for the "punters", but I have to say it
seems odd for matrices. Ox uses 0-base; does R do that too?
R uses 1-base indexing. If x is vector, x[1] is the first element, if m
is array, or matrix, or data frame, m[1,] is the first row, m[,1] is the
first column. In context of linear hypothesis testing, if restriction is
A\beta=b, with \beta being the regression coefficients, you must provide
matrix B and vector b.
Vaidotas
1:48 p.m.
On Tue, 22 Aug 2006, Vaidotas Zemlys wrote:
R uses 1-base indexing. If x is vector, x[1] is the first element, if
m
is array, or matrix, or data frame, m[1,] is the first row, m[,1] is the
first column.
Thanks. Well then, we're not out of line with all other
programs. (I suppose ox is really a programming language rather
than an "econometrics package" as such, and in programming
languages 0-base indexing is certainly the norm.)
Allin.
4:12 p.m.
On Tue, August 22, 2006 15:48, Allin Cottrell wrote:
On Tue, 22 Aug 2006, Vaidotas Zemlys wrote:
> R uses 1-base indexing. If x is vector, x[1] is the first element, if m
> is array, or matrix, or data frame, m[1,] is the first row, m[,1] is the
> first column.
Thanks. Well then, we're not out of line with all other
programs. (I suppose ox is really a programming language rather
than an "econometrics package" as such, and in programming
languages 0-base indexing is certainly the norm.)
And even that, not always: IIRC, FORTRAN is 1-based too, and so should be
gauss and matlab. I think base 1 is ok, it's one less thing for people without
a C background to worry about if they want to port their procedures into gretl
scripts.
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
4:56 p.m.
On Tue, 22 Aug 2006, Riccardo Jack Lucchetti wrote:
> Thanks. Well then, we're not out of line with all other
> programs. (I suppose ox is really a programming language rather
> than an "econometrics package" as such, and in programming
> languages 0-base indexing is certainly the norm.)
And even that, not always: IIRC, FORTRAN is 1-based too, and
so should be gauss and matlab. I think base 1 is ok, it's one
less thing for people without a C background to worry about if
they want to port their procedures into gretl scripts.
OK, agreed, we'll go with 1-based.
Attached: a little script that does the first, easy part of
the Verbeek GMM example.
Allin.
3:23 p.m.
New subject: Bug
I just downloaded the current Windows snapshot and installed on a
Windows XP (with Spanish language). I would like to report a bug:
If I open a dataset (data3-6, for example) and select Model/OLS and
then click on the help button, gretl hungs. The same occurs with all
the models except with Model/Maximum Likelihood and Model/System of
equations that show the help in English. I think may be something with
the Spanish help files, only working those items that are not
translated jet, so offering the help in English.
1:03 a.m.
New subject: Bug
On Thu, 24 Aug 2006, etpdihei(a)ehu.es wrote:
I just downloaded the current Windows snapshot and installed
on a Windows XP (with Spanish language). I would like to
report a bug: If I open a dataset (data3-6, for example) and
select Model/OLS and then click on the help button, gretl
hungs. The same occurs with all the models except with
Model/Maximum Likelihood and Model/System of equations that
show the help in English...
Ok, thanks for letting me know. I'll check that and see what's
wrong.
Allin.
4:04 p.m.
New subject: 'seed'
¿Another bug?
With the current Windows snapshot (build 8/22/2006) I was checking if
the new "seed" option in the /add/normal/random variable/normal dialog
box works. Datafile data9-9 was opened, I selected the above entry in
the menu, I put "3" in the seed box, and generated a normal (0,1)
variable with name "norm", I repeated the operation changing the name
to norm2, and the result was:
Obs norm norm2
1976:1 1,232701 -0,017542
1976:2 -1,862191 0,237066
1976:3 1,277692 1,959801
1976:4 0,033582 -1,375184
1977:1 -0,739636 0,817394
1977:2 ...
The funny thing is that if I close gretl and repeat exactly the same
procedure, exactly the same values are generated.
I also tried opening a new gretl session an calling the first
variable "norm2", and the second "norm", the result was
Obs norm2 norm
1976:1 1,232701 -0,017542
1976:2 -1,862191 0,237066
1976:3 1,277692 1,959801
1976:4 0,033582 -1,375184
1977:1 -0,739636 0,817394
1977:2 ...
¿Is this behavior correct?
4:38 p.m.
New subject: 'seed'
On Tue, August 29, 2006 18:04, Ignacio Diaz-Emparanza wrote:
¿Another bug?
With the current Windows snapshot (build 8/22/2006) I was checking if
the new "seed" option in the /add/normal/random variable/normal dialog
box works. Datafile data9-9 was opened, I selected the above entry in
the menu, I put "3" in the seed box, and generated a normal (0,1)
variable with name "norm", I repeated the operation changing the name
to norm2, and the result was:
Obs norm norm2
1976:1 1,232701 -0,017542
1976:2 -1,862191 0,237066
1976:3 1,277692 1,959801
1976:4 0,033582 -1,375184
1977:1 -0,739636 0,817394
1977:2 ...
The funny thing is that if I close gretl and repeat exactly the same
procedure, exactly the same values are generated.
I also tried opening a new gretl session an calling the first
variable "norm2", and the second "norm", the result was
Obs norm2 norm
1976:1 1,232701 -0,017542
1976:2 -1,862191 0,237066
1976:3 1,277692 1,959801
1976:4 0,033582 -1,375184
1977:1 -0,739636 0,817394
1977:2 ...
¿Is this behavior correct?
Well, yes (unless I've misunderstood your point). That's the whole point of
setting a seed, you ensure the same set of psuedo-rv get generated each time.
The seed gives you the "starting point" of the generator, and from that point
on each pseudo-rv you generate comes from a deterministic sequence.
Compare with:
set seed 3
genr norm=normal()
set seed 3
genr norm2=normal()
print norm norm2 --byobs
and you get
Obs norm norm2
1:01 1.232701 1.232701
1:02 -1.862191 -1.862191
1:03 1.277692 1.277692
1:04 0.033582 0.033582
...
The thing is, you typically set the seed once and for all within a session; it
may be slightly misleading to have the choice to set the seed each time you
generate a pseudo-rv. Maybe it'd be better to move the text box for setting
the seed under "Tools/Preferences/General"?
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
9:53 p.m.
New subject: 'seed'
On Tue, 29 Aug 2006, Riccardo Jack Lucchetti wrote:
On Tue, August 29, 2006 18:04, Ignacio Diaz-Emparanza wrote:
> ¿Another bug?
>
> With the current Windows snapshot (build 8/22/2006) I was checking if
> the new "seed" option in the /add/normal/random variable/normal dialog
> box works. Datafile data9-9 was opened, I selected the above entry in
> the menu, I put "3" in the seed box, and generated a normal (0,1)
> variable with name "norm", I repeated the operation changing the name
> to norm2, and the result was:
>
> Obs norm norm2
>
> 1976:1 1,232701 -0,017542
> 1976:2 -1,862191 0,237066
There was something wrong about this dialog: the seed was
actually set only if it differed from the previous seed --
that's why the two series above are not identical. Not a bug
exactly, but probably not what users would expect.
I am taking Jack's suggestion (or a variant of it), and will
move the "set random set" option to the Tools menu; and I'm
making it so that it always sets the seed, if you click "OK".
With the new setup, you can go to /Tools/Seed for random numbers
and set, say, "3", then generate a normal series. If you
generate another normal series without revisiting the seed
dialog, it will differ from the first. But if you revisit the
seed dialog, leave the value at "3" and click "OK", then
generate another normal series, it will be identical to the
first.
Does this seem like the right behaviour?
Allin.
6448
days inactive
6455
days old
9 comments
5 participants
participants (5)
-
Allin Cottrell -
etpdihei＠ehu.es -
Ignacio Diaz-Emparanza -
Riccardo Jack Lucchetti -
Vaidotas Zemlys