I've just read about the non-parametric Mann-Kendall test for a trend
(hence my recent postings about Kendall's tau and ties in a series).
It looked pretty easy, so I'm attaching an attempt at a basic
implementation. Full disclosure: I've used the description from
the basic version in section 1.1).
All you have to do is call "MannKendall(x)", where x is your series of
I'd be happy about feedback regarding cross-checks and correctness (for
example in the above document in equ. (4) the case S>0 wrongly appears
twice, and I had to make an educated guess where to switch the
signs...), whether it should become a function package and so on.
very short minimal script here:
matrix heyho = ("a" == "b") ? garbl[3,] : I(2)
There is no object "garbl", but that's by design in the case that the
condition isn't true. Gretl says "[" would be invalid here.
I find it confusing in routine work that the lags() function wants to
have the lag number as the first arg, while the mlag() function wants to
have the input matrix first and afterwards the lag number.
Don't know how, maybe this could be aligned somehow in the future.
when "printing" summary statistics, correlation matrixes, etc., the usual limit of 31 characters for variables is not held. Instead, variables are truncated to 15 characters... In some cases making them indistinguishable. If it was possible to also use the limit of 31 chars here, that would be really nice.
Dr. Frederik Schaff
FernUniversität in Hagen
Department of Business and Economics
Chair of Economic Theory (Prof. A. Endres)
Universitätsstraße 11 (TGZ)
Voice: +49 (0) 2331 987-4454
concerning the heuristics gretl uses when parsing formatted text data: I
just had a case with tab-delimited data where gretl gave up, and all I
had to do is to replace all tabs with semicolons.
The other format information: daily dates were given as dd.mm.yyyy, the
decimal separator was a comma. The date column had the label "Date".
I'm not saying this is a bug and I know heuristics can never be perfect.
Just wanted to let you know that gretl was almost getting there, there
was only one step left.
Further follow-up to Ignacio's comment in
(As a reminder, Ignacio remarked that gretl was considering 1700 as a
leap year, which it wasn't on the Gregorian calendar, and also that
our weekday() function was producing some bad values for eighteenth
In git and snapshots I've now revamped gretl's calendar so that it's
consistently Gregorian by default. At the same time I've added some
apparatus for handling Julian dates, in case that should be needed for
dealing with historical data. Internally, we're now using GLib's
GDate API (with some additional algorithms for handling Julian dates)
in place of the old code based on the unix "cal" program.
The current setup is discussed in a new chapter 16, "Calendar dates",
in the User's Guide. I've partially updated the help for the relevant
calendrical functions in line with the new chapter, but not yet fully
since I'd like to wait and get people's reactions.
So, comments welcome.
For package authors: here's a listing of deprecation warnings produced
by packages currently on the server. If you can find time to update
your package(s) that would be much appreciated!
Note that the warning for using '=' as an equality test is very
explicit so it should be easy to find the location in the code.
* Missing "include" in sample script:
* Use of "catch" on calls to user-defined functions
(generates a warning, really should be an error by now):
* Use of '=' as test for equality (count of warnings
from running sample script):
or is it just me?
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
OK. I understand. Good to know that gretl is doing well.
It is interesting that in this url the calendar for Spain in 1700 is
different from the US calendar.
I assume the "cal" code maybe is doing some adjustments also for some
days in 1756 (and also some other years in the XVIII century). In
particular the gretl function 'weekday' produces negative values for
some days in may 1756 (they should be values only from 0(sunday) to
setobs 7 1755-01-01 --time-series
series d = weekday($obsmajor,$obsminor,$obsmicro)
El 16/02/17 a las 18:00, gretl-devel-request(a)lists.wfu.edu escribió:
> Gretl follows the unix "cal" program on this. In lib/src/calendar.c:
> /* leap year -- account for gregorian reformation in 1752 */
> #define leap_year(yr) \
> ((yr) <= 1752 ? !((yr) % 4) : \
> (!((yr) % 4) && ((yr) % 100)) || !((yr) % 400))
> See also
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