negative dates (BC)
Moderators: EViews Gareth, EViews Moderator
negative dates (BC)
I would find it very useful (probably I am almost alone with this), if it were possible to set years before Christ as well.
-
- Fe ddaethom, fe welon, fe amcangyfrifon
- Posts: 13317
- Joined: Tue Sep 16, 2008 5:38 pm
Re: negative dates (BC)
Interesting.
Can I ask what sort of data you're dealing with?
Econometrics doesn't usually have data going back so far....
Can I ask what sort of data you're dealing with?
Econometrics doesn't usually have data going back so far....
Follow us on Twitter @IHSEViews
Re: negative dates (BC)
At the moment I am working with Babylonian price data dating from 384BC. Now, in order to make graphs, I have to put everything to another software so that the dates on axis x are correct.
It may be surprising but more and more cliometrists are using Eviews. Historial economics and econometrics is a rising star now. There is even a professional econometric software already, which can handle negative dates (I do not write here which). But I would be very happy to see that Eviews can do the same.
It may be surprising but more and more cliometrists are using Eviews. Historial economics and econometrics is a rising star now. There is even a professional econometric software already, which can handle negative dates (I do not write here which). But I would be very happy to see that Eviews can do the same.
Re: negative dates (BC)
I think you should use integer dates in any case, since you may experience irregular time intervals at some point in your research. If you create an "Unstructured/undated" workfile, you can generate a series to represent the time variable for your analysis. Then you can use XY-line as the graph type, where X being the time and Y being the variable of interest.
-
- EViews Developer
- Posts: 161
- Joined: Wed Sep 17, 2008 10:39 am
Re: negative dates (BC)
I have to admit I thought that we were being pretty open ended when we allowed dates back to 1 AD!
It's actually non-trivial for us to allow dates to go back further because we use values between -1.0 and 0.0 to represent the mysterious 'integer dates'. This means that extending back to allow dates before 1st Jan 1AD would require a change in the date format which could create compatibility issues between versions.
The absence of year zero would also cause us quite a few headaches. If you place a label on a graph every ten years, you're going to end up with labels like:
-11BC, -1BC, 10AD, 20AD
which are a bit odd.
For the moment, I doubt there's enough demand for BC dates to justify the resources we would needed to implement them.
In the mean time, your best bet is probably to create a series of integers ranging from -384 to whatever year your data goes forward to (remembering to skip past zero), and then tell EViews to use this is an 'id series' for the workfile (see the docs on structuring a workfile).
This will attach labels to each observation which we will use in spreadsheets and graphs.
The downside is that EViews won't understand that the labels are dates. This means the axis labelling in graphs will be less smart and that we won't be able to easily match your data against other dated data (eg. in frequency conversion).
It's actually non-trivial for us to allow dates to go back further because we use values between -1.0 and 0.0 to represent the mysterious 'integer dates'. This means that extending back to allow dates before 1st Jan 1AD would require a change in the date format which could create compatibility issues between versions.
The absence of year zero would also cause us quite a few headaches. If you place a label on a graph every ten years, you're going to end up with labels like:
-11BC, -1BC, 10AD, 20AD
which are a bit odd.
For the moment, I doubt there's enough demand for BC dates to justify the resources we would needed to implement them.
In the mean time, your best bet is probably to create a series of integers ranging from -384 to whatever year your data goes forward to (remembering to skip past zero), and then tell EViews to use this is an 'id series' for the workfile (see the docs on structuring a workfile).
This will attach labels to each observation which we will use in spreadsheets and graphs.
The downside is that EViews won't understand that the labels are dates. This means the axis labelling in graphs will be less smart and that we won't be able to easily match your data against other dated data (eg. in frequency conversion).
-
- Non-normality and collinearity are NOT problems!
- Posts: 3775
- Joined: Wed Sep 17, 2008 2:25 pm
Re: negative dates (BC)
Let me just point out that real econometricians use the terms CE and BCE, rather than AD and BC.
Re: negative dates (BC)
Thanks for the useful suggestions, I completely understand that having such functionality would finally casue more problems that it would solve.
Return to “Suggestions and Requests”
Who is online
Users browsing this forum: No registered users and 19 guests