Re: [Gretl-devel] Gretl-devel Digest, Vol 121, Issue 19
by Ignacio Diaz-Emparanza
Oh! I have it. Gretl is considering 1700 as a leap year, when it is not
so. The exact centuries are only leap years when they are a multiple of 400.
El 15/02/17 a las 18:00, gretl-devel-request(a)lists.wfu.edu escribió:
> Send Gretl-devel mailing list submissions to
> gretl-devel(a)lists.wfu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
> or, via email, send a message with subject or body 'help' to
> gretl-devel-request(a)lists.wfu.edu
>
> You can reach the person managing the list at
> gretl-devel-owner(a)lists.wfu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gretl-devel digest..."
>
>
> Today's Topics:
>
> 1. Leap year (Ignacio Diaz-Emparanza)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Feb 2017 17:49:21 +0100
> From: Ignacio Diaz-Emparanza <ignacio.diaz-emparanza(a)ehu.eus>
> To: Gretl development <gretl-devel(a)lists.wfu.edu>
> Subject: [Gretl-devel] Leap year
> Message-ID: <bce7b110-55d3-319a-dfdb-473b5ac4f596(a)ehu.eus>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> ?Are we sure that gretl is treating correctly the leap year in the
> gregorian calendar? I think that 146097 days should be exactly 400
> years, but but when I try to define such a dataset, the last observation
> is december 30. There is a day missing. (gretl from git on Ubuntu 16.04,
> built on january 26)
>
> gretl versi?n 2017a-git
> Sesi?n actual: 2017-02-15 17:40
>
> ? nulldata 146097 #400 a?os (de 365,2425 dias)
> periodicidad: 1, m?x. obs: 146097
> rango de observaciones: 1 a 146097
> ? setobs 7 1617-01-01 --time-series
> Rango de datos completo: 1617-01-01 - 2016-12-30 (n = 146097)
>
>
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
7 years, 7 months
Leap year
by Ignacio Diaz-Emparanza
¿Are we sure that gretl is treating correctly the leap year in the
gregorian calendar? I think that 146097 days should be exactly 400
years, but but when I try to define such a dataset, the last observation
is december 30. There is a day missing. (gretl from git on Ubuntu 16.04,
built on january 26)
gretl versión 2017a-git
Sesión actual: 2017-02-15 17:40
? nulldata 146097 #400 años (de 365,2425 dias)
periodicidad: 1, máx. obs: 146097
rango de observaciones: 1 a 146097
? setobs 7 1617-01-01 --time-series
Rango de datos completo: 1617-01-01 - 2016-12-30 (n = 146097)
--
Ignacio Díaz-Emparanza
Departamento de Economía Aplicada III (Econometría y Estadística)
Universidad del País Vasco - Euskalherriko Unibertsitatea, UPV/EHU
Tfno: (+34) 94 601 3732
http://www.ehu.eus/ea3
7 years, 7 months
crash (GUI script editor)
by Sven Schreiber
Hi,
a reproducible crash with snaphot from Feb 10th on Windows 10:
- Open a (any?) script in the script editor.
- With the mouse select (click-drag) a portion of text, starting at the
beginning of one line, and make sure to select only complete lines (hope
you understand what I mean).
- After successful selection, right-click in the selection -> crash, exit.
thanks,
sven
7 years, 7 months
Restricted estimation in bulti-in ML setups?
by Sven Schreiber
Hi,
I think it is not currently possible to do restricted ML estimation with
the built-in estimators (apart from the special case OLS), otherwise I
would have formulated this as a question and sent to gretl-users
instead. Before someone answers "do your own mle block", I'm aware of
that possibility but that's not the point.
For example in the ordered probit model I have checked that one can test
restrictions on the thresholds (cut points) with a standard "restrict
... end restrict" command block. This raised the question of why
actually it isn't possible (easily...) to impose that restriction in ML
estimation.
Note that the probit is just an example, in principle I guess this would
apply to many (all?) estimators that are built on ML and which already
allow to test a restriction on an element of $coeff.
I could imagine that in some model contexts arbitrarily restricting some
parameter might induce ill-behaved likelihood function shapes. But in
principle it should be OK, no?
Thanks,
sven
7 years, 7 months
@-based string substitution and 'foreign'
by Sven Schreiber
Hello again,
I am trying to become a forward-looking/rational-expectations/precog bug
reporter... Seriously, here is a worry that is inspired from a trick
that Oleh used in one of his scripts with a 'foreign' block, but that
hasn't actually produced any errors in real life, at least for me.
AFAICS gretl currently applies string substitution with @-tagged
unquoted strings everywhere in the script. So a defined string s="be"
can be injected somewhere by writing @s. This feature can be used to
transfer some string values from the gretl environment to the 'foreign'
environment.
However, this might become a problem when the @-character has another
syntactic meaning in the foreign language. For example in Python it
starts a so-called decorator.
Theoretical example without practical meaning:
<hansl>
string p = "heyho"
foreign language=Python
@property
def mypyfunc(...): ...
end foreign
</hansl>
The way I see it, gretl would turn the decorator line "@property" into
"heyhoroperty" which of course breaks the Python code.
If that assessment is correct, not sure what the best solution would be.
As I said, the behavior has been used intentionally by some.
Comments welcome,
Sven
7 years, 7 months
test for equality vs assignment, function packages
by Allin Cottrell
This point has been the subject of discussion not so long ago
(sorry, couldn't find the reference before timing out!). But here I
take it up again.
For a long time, the gretl documentation has stated that testing for
equality should be done using "==" (two consecutive equals signs, as
in most programming languages). But also for a long time, we have
accepted a single equals sign for that purpose. The latter is now
officially deprecated (see
http://gretl.sourceforge.net/Backward.html ) because it makes it
difficult to produce correct error messages in some cases (plus it's
plain sloppy). And in current git you get a warning if gretl reckons
you're using '=' for an equality test.
Here's the problem: it turns out that several function packages use
'=' for testing equality, in some cases within loops that may have
many iterations. So if we keep the warning in place, and don't
revise those packages, users may end up seeing a huge spew of
warnings from packages that have been approved for public
consumption -- which doesn't seem good.
We could kick the can down the road by hushing the warning for the
next release. We could identify the packages in question and request
that their authors fix them. And/or we could fix the packages
ourselves (if the authors are non-responsive).
This raises a policy question. On a few previous occasions I have
fixed up somebody else's package (when the author has apparently
dropped out of circulation but the package seems to have some
merit). But is this something we want to get into?
Allin
7 years, 7 months
gretl-git heads-up
by Allin Cottrell
I'm about to merge the new "genr" code that properly handles
nesting of the member-of relation. It has been tested to a fair
extent already, but it will be easier for me to complete the testing
once this code is in the "master" branch.
So, be warned that there may be some new bugs in git for a while,
though hopefully they'll be resolved quickly.
Allin
7 years, 7 months
