Gretl project on the launchpad
by Ivan Sopov
Hello, gretl developers.
I'm trying to start a translation of help files into russian on
launchpad.net as it seems to be the most suitable tool to participate
for all familiars with econometrics but not with gettext, linux. cvs,
etc.
The problem is that there is already a project for gretl on launchpad
and it is strongly prohibited to start more than one project for a
single program. I cannot contact with Constantine Tsardounis for about
a month, so I think it is time to re-assign that project to someone
else. On the irc-channel of launchpad I was told that
Our admins can re-assign the project to new owners but we'd prefer to
hear from the upstream owners. can you get one of them to submit a
question here:
https://answers.edge.launchpad.net/launchpad
But if nobody from main developers wants to register and do something
at launchpad it is possible to assign this function to me and in that
case a letter in this list will probably be enough.
I have prepared a .po-file for genr_funcs.xml and gretl_commands.xml
with the help of po4a utility and got 1511 strings for translation
(strings a rather big).
Good luck, Ivan Sopov.
P.S. My previous letter about using launchpad for translation is
http://lists.wfu.edu/pipermail/gretl-devel/2009-November/002171.html
12 years, 9 months
A suggestion
by Talha Yalta
I am not sure how often people generally use the "notes" interface
accessible from the icon view but I have a feeling that it is not very
often. As a result, I suggest that, upon loading a session, gretl
automatically opens the notes window if there is anything in it. This
way one can include important information or directions which will be
immediately visible to users (for example students) when distributing
such files.
Cheers
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
13 years, 10 months
coupla things
by Allin Cottrell
Two new things in CVS that I think should be
uncontroversial, but please let me know if any
breakage results:
* Up till now it has been impossible to give a scalar
parameter to a user-defined function a default value of
NA. This is partly because NA was used as the internal
representation for "no value set". However, it seemed
to me that in some cases it may be useful to set a
default of NA for a trailing parameter, meaning that
if the user omits a value for that parameter, it
should then be ignored (not used) within the function.
This is now possible, but note, only for parameters
of type "scalar", not "bool" or "int".
* Evaluation of boolean "&&" and "||": up till now
we have evaluated both sides of these booleans
before creating the result. But evaluation of the
right-hand branch is redundant if (a) the operator
is && and the left is FALSE, or (b) the operator
is || and the left is TRUE. Now we skip evaluation
on the right when it's redundant. Besides being
more efficient this fixes a problem with NAs.
Let the scalars x = 2, y = NA. Before the change
if x > 1 || y > 10
would produce an error, since "y > 10" can't be
evaluated. Now it works OK.
Allin
13 years, 11 months
add and omit once again
by Allin Cottrell
Sorry to keep harping on this, but the "add" and "omit" have
been rather messy for a long time, and I'm struggling to
straighten them out, at least partially.
Part of the difficulty is that one could think of "omit" in
either of two ways:
1) It's shorthand for a special case of "restrict", with the
side effect (which one may or may not want) of estimating the
restricted model and making it the "last model".
2) It's a shorthand means of re-estimating the last model
with a smaller specification, with the side effect of
reporting a test for the implied restriction.
Lots of scripts in the gretl package use omit in the second
way, which makes me a bit reluctant to switch the default
behavior to NOT producing a new model.
In CVS I had introduced a --test-only switch but on further
thought that did not seem very clean, since we already had a
--wald switch which suppresses the "produce a new model"
behavior. So here's what I now have in CVS, and on which I'd
value comments:
1) For "omit", if you don't want a new model, use the --wald
flag. This will now produce the F-form of the Wald test by
default, but if you prefer the chi-square version, use the new
--chi-square option. Note that if you have any scripts which
use the --quiet option to "omit" to suppress the new model,
switch to --wald and you should be OK. (As it should, --quiet
now only affects what gets printed, not the substance of what
gets done.)
2) "add" is a bit different, but I've introduced an --lm
option that does an LM test using an auxiliary regression.
That way you don't get a new model, but right now the --lm
option is only for OLS. Otherwise you do get the augmented
model, even if you choose not to print it. I think this is OK,
since "add" (apart from the new LM option) is a sort of
synthetic command anyway: in effect, estimate the bigger model
and do an "omit" on it.
The documentation for add and omit is updated in CVS. If we're
OK with this I'll put a entry into the backward
incompatibility log.
Oh, one other thing: the latest version is not yet in the
snapshots for Windows and OS X. I thought I'd wait to hear
some reactions before doing that.
Allin
13 years, 11 months
the "add" and "omit" commands
by Allin Cottrell
In the course of working on the bug reported by Ignacio
I took a look at some other aspects of add and omit.
These commands have a long history, and from the beginning
they have had a dual aspect: they run a test but also
"return" a new model, which becomes the current model
in place of the model being tested. I don't think I'd
make them that way if I were writing them today, but
anyway...
A relatively recent addition is the --wald option, in
which case the current model is not replaced. In addition,
there has been undocumented behavior whereby if you
give the --quiet option the current model is not
replaced. This seems to me unruly, and in CVS I've
modified add and omit thus:
* The --quiet flag infuences the printout only, and
has no effect on whether or not the current model is
replaced.
* A new --test-only option can be used to prevent
replacement of the current model. This can be applied
for all variants of "omit", although it's already
implicit in the --wald option.
Does this seem OK?
And one more thing: with a regular "omit", without the
--quiet flag, the full estimation results for the
reduced model are printed first, then the test. This
can confuse the unwary (e.g. my students), because
the first F-test they see in the output is the
"overall" F-test for the reduced model, not the
"omit" test itself. To get around this I've modified
the model printout so that it does the equivalent of
--simple-print, leaving off the auxiliary statistics
including the overall F-test. (If you save the model
in the GUI and then view it in its own right, you
get the full printout as usual.)
Again, does this seem OK?
Allin
13 years, 11 months
Very small bug
by Vitalie Ciubotaru
Hi,
I want to report a tiny bug. Please, see the following console output:
gretl console: type 'help' for a list of commands
? help blabla
"blabla" is not a gretl command.
? help
"blabla" is not a gretl command.
?
The last line of output is wrong: instead of printing all valid
commands, it just repeats the previous error message.
I came across this annoyance in version 1.9.5 and then re-built gretl
from today's CVS to make sure it's still there. It is.
Regards,
Vitalie Ciubotaru
13 years, 11 months
a small bug
by Talha Yalta
There seems to be a small bug in the reporting of the RESET results.
The p values for the squares only and cubes only options switch places
in the window showing all the 3 variants (as opposed to the individual
test results).
Cheers
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
13 years, 11 months
Re: [Gretl-devel] [Gretl-users] CVS status update
by Sven Schreiber
Am 19.07.2011 21:03, schrieb Allin Cottrell:
>
> http://sourceforge.net/blog/further-update-on-cvs-outage/
>
[moved to devel list]
I don't really understand their strategy:
"1. We plan on re-implementing the CVS service offering using current
best practices
2. We plan on discouraging new projects from using the CVS service and
directing them to something that is more current
3. We plan on helping projects interested in migrating to a more current
SCM platform through documentation and direct assistance as needed"
So two out of three measures to improve CVS hosting reliability involves
moving people away from CVS? This sounds like the acknowledgment that
they won't be able to offer a reliable CVS service.
Some time ago I had suggested to move to SVN (subversion), but in the
meantime I have changed my mind to an attitude of "don't change a
working setup". But maybe the times of a working setup are over?
-sven
13 years, 11 months
firstobs() and lastobs()
by Allin Cottrell
I'm thinking it might be good to revise the functions
firstobs() and lastobs() so they restrict their checks for
non-missing values to the current sample range (right now they
scan the entire dataset).
This would be backward incompatible, but I'd be surprised if
it would cause much trouble. Although it's so stated in the
manual, I think it's unintuitive for function writers that
firstobs() and lastobs() can give you observation indices that
are outside of the sample passed by the caller, and therefore
inaccessible.
Any support/objections?
Allin
13 years, 11 months
Re: [Gretl-devel] [Gretl-users] smpl in a function
by Cottrell, Allin
Hi Peter,
Thanks for following this up. Here's the deal:
First, you got a misleading error message, "Bad character
'b' in date string". That is fixed in my source tree and
wll be fixed in CVS as soon as sourceforge CVS is up again
(unfortunately it's broken right now). However, the other
part of the error message, namely
error in new starting obs
was quite correct: your function tried to push the start of
the sample range outside of the range passed in by the
caller, which is not allowed.
This is because of the way that firstobs() and lastobs()
work at present -- as noted in the Function Reference.
That is, firstobs() gives the observation number for the
first non-missing value of its series argument, but this
may occur before the start of the current sample range.
There's a case for changing that, so that firstobs() and
lastobs() do not return values outside of the current
sample, but that would be backward incompatible so I'm
not going to make the change uniterally; I'll raise the
question on the devel list.
I'm attaching a modified (skeletal) version of your script
that shows how to deal with sampling inside a function.
If we decide to change firstobs() and lastobs() this will
still work, although the conditional stuff with the '?'
operator would become redundant.
Allin
13 years, 11 months
