1:04 p.m.
Further follow-up to Ignacio's comment in
http://lists.wfu.edu/pipermail/gretl-devel/2017-February/007439.html
(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
century dates.)
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.
Allin
1:21 p.m.
Am 21.02.2017 um 19:04 schrieb Allin Cottrell:
dealing with historical data. Internally, we're now using
GLib's
GDate API (with some additional algorithms for handling Julian dates) in
So, comments welcome.
My spontaneous reaction is that gretl (== Allin) shouldn't have to solve
these issues, because this is something that some other library should
provide. If they do it wrong, gretl should basically just shrug and do
nothing.
I mean, now you're fixing the ancient calendar for the entire
open-source world? Where are all the historians?
(My excuses to all econometric medievalists out there...)
cheers,
sven
3:58 p.m.
On Tue, 21 Feb 2017, Sven Schreiber wrote:
Am 21.02.2017 um 19:04 schrieb Allin Cottrell:
> dealing with historical data. Internally, we're now using GLib's
> GDate API (with some additional algorithms for handling Julian dates) in
> So, comments welcome.
My spontaneous reaction is that gretl (== Allin) shouldn't have to solve
these issues, because this is something that some other library should
provide. If they do it wrong, gretl should basically just shrug and do
nothing.
;-) Actually, "some other library" is doing most of the work here
(the GDate API in GLib, which we already needed for other reasons).
I just added a couple of simple algorithms to handle Julian dates.
I mean, now you're fixing the ancient calendar for the entire
open-source
world? Where are all the historians?
Not exactly "ancient"; we don't do BC, and I have no plans to go
there! I was thinking more of (say) Bank of England interest-rate
data from the first half of the 18th C, when England was still on
the Julian calendar.
(My excuses to all econometric medievalists out there...)
Hmm, if I'm remembering correctly Jack was telling me about some
Italian econometric medievalists last summer, as we drove south from
Ancona on a fine June evening. Their data might make a nice test
case, if we can get hold of it.
Allin
2:15 a.m.
On Tue, 21 Feb 2017, Allin Cottrell wrote:
Hmm, if I'm remembering correctly Jack was telling me about some
Italian
econometric medievalists last summer, as we drove south from Ancona on a fine
June evening. Their data might make a nice test case, if we can get hold of
it.
I've been in touch with Paolo Malanima, who has lots of long-term dataset$
(incredibly interesting if you're into development economic and economic
history). Those are mainly yearly data, though. There's nothing I know of
at higher frequencies, let alone daily data. I seriously doubt there's
any need for a piece of software that can correctly deal with infra-week
periodicities for the Middle Ages. Simply, there are no data at that
disaggregation level.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:51 a.m.
On Wed, 22 Feb 2017, Riccardo (Jack) Lucchetti wrote:
On Tue, 21 Feb 2017, Allin Cottrell wrote:
> Hmm, if I'm remembering correctly Jack was telling me about some Italian
> econometric medievalists last summer, as we drove south from Ancona on a
> fine June evening. Their data might make a nice test case, if we can get
> hold of it.
I've been in touch with Paolo Malanima, who has lots of long-term dataset$
(incredibly interesting if you're into development economic and economic
history). Those are mainly yearly data, though. There's nothing I know of
at higher frequencies, let alone daily data. I seriously doubt there's
any need for a piece of software that can correctly deal with infra-week
periodicities for the Middle Ages. Simply, there are no data at that
disaggregation level.
There are infra-week (but generally incomplete) financial market data
going back to the 12th century -- see for example
http://chnm.gmu.edu/worldhistorysources/r/170/whm.html
How many people want to make use of such data is another matter.
Allin
10:46 a.m.
On Wed, 22 Feb 2017, Allin Cottrell wrote:
On Wed, 22 Feb 2017, Riccardo (Jack) Lucchetti wrote:
> On Tue, 21 Feb 2017, Allin Cottrell wrote:
>
>> Hmm, if I'm remembering correctly Jack was telling me about some Italian
>> econometric medievalists last summer, as we drove south from Ancona on a
>> fine June evening. Their data might make a nice test case, if we can get
>> hold of it.
>
> I've been in touch with Paolo Malanima, who has lots of long-term dataset$
> (incredibly interesting if you're into development economic and economic
> history). Those are mainly yearly data, though. There's nothing I know of
> at higher frequencies, let alone daily data. I seriously doubt there's
> any need for a piece of software that can correctly deal with infra-week
> periodicities for the Middle Ages. Simply, there are no data at that
> disaggregation level.
There are infra-week (but generally incomplete) financial market data going
back to the 12th century -- see for example
http://chnm.gmu.edu/worldhistorysources/r/170/whm.html
How many people want to make use of such data is another matter.
Wow!
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
2825
days inactive
2826
days old
5 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber