Integrate convert_dyn_45_to_44 into convert_oo_.m

@stepan-a Is convert_oo_.m a one-way utility that only allows converting to newer values? Or is it also to support backward-compatibility (two-way)? convert_dyn45_to_44.m was introduced following the discussion on http://www.dynare.org/DynareWiki/OutputVariables and only allows preserving backward compatibility. It is not intended to bring older version into the new format. We may want to use one tool that allows converting freely between formats.

Discussing with @houtanb, I realize that I have a semantic issue with backward and forward compatibility... I think that our responsibility, with respect to our users, is to ensure that old results (oo_, M_, ...) can be used with more recent versions of Dynare. @houtanb's code can be used to convert freely between formats, but I do think that it is not reasonable to commit on the reversed compatibility (results obtained with new versions of Dynare loadable with older versions of Dynare). This is (far) too much work...

I think so to, but I think @stepan-a and @MichelJuillard insisted on this as a precondition for the changes outlined in the http://www.dynare.org/DynareWiki/OutputVariables. See our email exchange in November 2014 where @MichelJuillard said

In commit fecec9c74c89df2a127179749409f4bbcf3222ca, you change oo_.RecursiveForecast in order to remove the initial point as in other results.

This is fine with me but it modifies global variables on which people may count for code that they have written around Dynare. We need to describe these changes more clearly than we did in the past (a separate section of the
Wiki?) and we need to provide a Matlab utility allowing to go back easily to the previous output organization (something like dyn.4.5to4.4.m). We need to build this utility cumulatively while making changes.

Could you do it for all similar changes that you propose?

and My inclination would be to include in the conversion utility all changes to global variables that are not clearly bugs (behaviour contrary to what is written in the documentation).

I guess that we need both features:

if a user has developped Matlab code for his 4.4 version, he wants to convert M_, oo_, options_ created by a 4.5 parser into 4.4 layout
in order to load results created by 4.4 version in a run with 4.5, we need the inverse conversion I wonder what is the most efficient: releasing a different utility for each version and indicate the versions in its name or a cumulative utility where the user need to pass the version numbers as arguments?

I am not convinced that a utility to address the first point raised by @MichelJuillard is the best approach. Ideally users should change their matlab code at some point (also such a utility does not address the case, or very inefficiently, where the user's matlab code is called in the middle of the Dynare run, ie not for post treatment of the generated data) and our responsibility would be to document what is changing from one version to another. But we can try to do it both ways...

So we need routines like

convert_44_to_45, convert_45_to 46, ...

and

convert_45_to_44, convert_46_to_45, ...

and a general routine that calls them (recursively if needed, for instance for a conversion from 4.4 to 4.6). The routine should be able to convert options_, oo_ and M_. @houtanb Can you modify your routine to do that? Also we do not need the last digit in the version numbers because we do not change oo_, options_ and M_ in the stable version.

If I understand correctly, we're only providing conversions from 4.4 forward, is that correct? No need to do 4.3 and earlier?

@houtanb Version 4.4 is the first one that changes the output structure. All versions before 4.4 should be the same.

I'm not so sure that nothing has changed between 4.3 and 4.4, but let's do one thing at the time. First let's do it for 4.4 and 4.5 and establish standard practice for the future. Then we may want to look back to 4.3-4.4

matlab/convert_oo_ is a recursive function that works in both directions (i.e. converting up from, for example, 4.3 to 4.5 or converting down from, for example, 4.5 to 4.3).

The procedure is that for every new release of Dynare, we need to:

modify convert_oo_ to change the MAX_VER variable.
create two new functions: convert_dyn_NEW_VER_to_LAST_VER.m and convert_dyn_LAST_VER_to_NEW_VER.m

These functions can all be modified easily to return updated versions of M_ and options_ as well, in which case we'd rename it to something like convert_dynare_structs

removed milestone

changed milestone to %4.6

Given that we have not worked on this for four years and no user has ever complained, I would suggest to not pursue this ticket any further and close it.

I agree. I’m going to remove the conversion functions, since it’s not clear that they’re useful, and we don’t have the time to maintain them.

assigned to @sebastien and unassigned @JohannesPfeifer

mentioned in issue #1656 (closed)

closed via commit 55d7397d

mentioned in commit 55d7397d

mentioned in commit 26597bf0

Integrate convert_dyn_45_to_44 into convert_oo_.m

Designs

Child items ...

Activity