Postby mamo » Mon Nov 12, 2018 3:37 am
I think, there are two issues here which should not be mixed up: first, structure-consistent references of panel data: the panel structure of the series in the targeted wf conforms with the structure of the referring wf page in use. Second structure-inconsistent copying (and reference) of panel data: the panel structure of the series in the source (which can be db or another wf) does not conform with the structure of the receiving wf page (or the referring wf page in use).
Regarding the first issue, my example programs suggest that structure-consistent wf2db-referencing works well. Therefore, it seems that some relevant pieces of information about the data structure of the series are stored in a db.
In contrast, wf2wf-referencing to panel data seems to work somehow differently: the panel structure is not properly kept, rather the show-command re-iterates though the first cross-section. This appears to be a bit odd: why is this so, in view of the fact that the necessary information about the data structure is already available in the target wf referred to?
Coming to the second issue, this is what your code provides an example for: copying a series originally structured as a panel from a db into a dated wf page which is not a panel. In this case, only the first cross-section is kept in the receiving page. (By definition, the dated receiving page does have only one crossid).
Another example of copying between inconsistent data structures would be copying an undated series from a db to a dated workfile, or vice versa. Obviously, what happens in such cases is that the series in the receiving wf page is filled with data from the source series successively, starting with the first observation in the receiving structure .
One may consider these implications of the copy (and related) command(s) as incoherent. But one would probably not conclude from such a incoherences that EVEIWS DBs do neither support undated nor dated series correctly.
Obviously, there is always an issue with structure-inconsistent copying: the allocation of the original series in the receiving structure is not clearly defined. There are basically two approaches to deal with this problem. First, one could simply inhibit copying between inconsistent data structures. Secondly, one could apply rules-of-thumb to define how the series to be copied is allocated to the data structure of the receiving page. EVIEWS has obviously chosen the second approach, trusting users that they understand the implications of copying across inconsistent data structures.
When a panel series is copied into a dated (but not panel) structure, the rules of thumb EVIEWS has implemented seem to imply that data for @crossids>1 are not copied. This is fine. Still, however, you may want to consider to amend the rules of thumbs by making sure that the panel structure of the original series is repeated to the extent possible in the structure of the receiving wf page.
To conclude, in dealing with the two issues mentioned above, the following complementary adjustments in future updates of EVIEWS would make the task of dealing with panel data across workfiles much easier:
First, make sure that structure-consistent references of panel data across workfiles work in the same way as they do in the cases of structure-consistent references from a workfile to a series stored in a db. The degree of consistence between panel structures is not always clearly defined. This may require some additional pragmatic rules of thumb, and here, the second proposal would apply:
Second, provided the receiving page does have a proper panel structure (# crossids>1), make sure that structure-inconsistent db2wf or wf2wf copies of panel data allocate the first crossid to the first crossid of the receiving page, the second one to the second crossid of the recieving page, and so forth, to the extent this is feasible.
Best, mamo