dseries issueshttps://git.dynare.org/Dynare/dseries/-/issues2021-05-13T14:15:31Zhttps://git.dynare.org/Dynare/dseries/-/issues/47bug in double for dates at yearly frequency2021-05-13T14:15:31ZMarco Rattobug in double for dates at yearly frequencyfor a dates object
```
dd=dates('2001Y');
```
the double of it provides `2000`
```
dd.double
ans =
2000
```for a dates object
```
dd=dates('2001Y');
```
the double of it provides `2000`
```
dd.double
ans =
2000
```5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dseries/-/issues/45Compatibility issue with MATLAB R2014a2021-01-27T17:30:42ZSébastien VillemotCompatibility issue with MATLAB R2014aIf one runs:
```
x = dseries(ones(2,2),'1Y',{'A1'; 'A2'});
y = { 'A1', 'A2'};
x{y{:}}.data(2:end, :)
```
The result is correct under MATLAB R2020b:
```
ans =
1 1
```
But it is incorrect under MATLAB R2014a:
```
ans =
1
`...If one runs:
```
x = dseries(ones(2,2),'1Y',{'A1'; 'A2'});
y = { 'A1', 'A2'};
x{y{:}}.data(2:end, :)
```
The result is correct under MATLAB R2020b:
```
ans =
1 1
```
But it is incorrect under MATLAB R2014a:
```
ans =
1
```
Note that this is not a purely theoretical problem. It causes the failure of `tests/smoother2histval/fs2000_simul.mod` under R2014a.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/54Add method for cleaning up after x11 run2023-05-27T12:46:33ZJohannes PfeiferAdd method for cleaning up after x11 runRuns of x11 will create various files with random names and endings like `d10,err,log,out,spc` in the main folder. We should add a routine that allows cleaning it.Runs of x11 will create various files with random names and endings like `d10,err,log,out,spc` in the main folder. We should add a routine that allows cleaning it.6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/51Allow specifying xls_sheet2023-09-27T15:16:54ZJohannes PfeiferAllow specifying xls_sheetCurrently, `load_data.m` contains
```
if isglobalinbase('options_')
% Check that the object is instantiated within a dynare session so that options_ global structure exists.
% Should provide latter a mechanism to pass...Currently, `load_data.m` contains
```
if isglobalinbase('options_')
% Check that the object is instantiated within a dynare session so that options_ global structure exists.
% Should provide latter a mechanism to pass range and sheet to dseries constructor...
range = evalin('base','options_.xls_range');
sheet = evalin('base','options_.xls_sheet');
else
% By default only the (whole) first sheet is loaded.
range = [];
sheet = [];
end
```
This does not work with `makedataset` in `mom.run`, because `xls_sheet` is a subfield of `options_mom_`, which is not even a global variable.7.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/57Filter out data series with NaN passed to x132023-08-30T12:13:31ZJohannes PfeiferFilter out data series with NaN passed to x13`x13` does not handle missing values. The `print`-method already removes leading and trailing `NaN`. But we do not check for intermediate `NaN`, which will trigger `x13` to fail. It would be preferable to return a meaningful message in t...`x13` does not handle missing values. The `print`-method already removes leading and trailing `NaN`. But we do not check for intermediate `NaN`, which will trigger `x13` to fail. It would be preferable to return a meaningful message in this case.https://git.dynare.org/Dynare/dseries/-/issues/56Fix handling of leading missing values in x132023-08-31T09:36:42ZJohannes PfeiferFix handling of leading missing values in x13The x13 `print` method discards leading NaN in the data:
```
p1 = firstobservedperiod(o.y);
p2 = lastobservedperiod(o.y);
...
fprintf(fid, ' data = %s', sprintf(data2txt(o.y(p1:p2).data)));
```
However, the `run`-method passes the result...The x13 `print` method discards leading NaN in the data:
```
p1 = firstobservedperiod(o.y);
p2 = lastobservedperiod(o.y);
...
fprintf(fid, ' data = %s', sprintf(data2txt(o.y(p1:p2).data)));
```
However, the `run`-method passes the results back as a `dseries` starting with the first `NaN`-period `o.y.init` instead of `o.y.firstobservedperiod`:
```
o.results.(savedoutput{i}) = dseries(data(:,2), o.y.init, savedoutput{i});
```
It seems all occurrences of `o.y.init` in `run` should be `o.y.firstobservedperiod`https://git.dynare.org/Dynare/dseries/-/issues/55Make subsref robust to deeper levels of nesting2023-05-23T17:22:49ZJohannes PfeiferMake subsref robust to deeper levels of nestingExecuting
```
load data_series.mat
ts = dseries(data_series,'1999Q1');
o = x13(ts);
o.transform('function','log');
o.automdl('savelog','amd');
o.x11('save','(d10)');
% run
o.run();
```
stores results in a `dseries` object in `o.results....Executing
```
load data_series.mat
ts = dseries(data_series,'1999Q1');
o = x13(ts);
o.transform('function','log');
o.automdl('savelog','amd');
o.x11('save','(d10)');
% run
o.run();
```
stores results in a `dseries` object in `o.results.d10`. However, trying to read out the subfield `o.results.d10.data` does not work as expected. Instead of a double, it will still return a `dseries`. The problem seems to derive from `subsref` only expecting two levels of nesting. This, by the way, also creates an infinite recursion problem in the Matlab variable editor, as shown in the screenshot.
![image](/uploads/da523510a35c57b65dddacdb36f50494/image.png)
[data_series.mat](/uploads/25ee186c37cf504f9c0b515bff8b5881/data_series.mat)https://git.dynare.org/Dynare/dseries/-/issues/53Fix crash after using insert2023-05-12T16:06:53ZJohannes PfeiferFix crash after using insertSee https://forum.dynare.org/t/dseries-insert-doesnt-carry-the-new-index/22386/5
```
clear all
load acetylene.mat
ds_example = dseries(y)
size(ds_example)
ds_nan = dseries(NaN, ds_example.dates, "inserted_Variable")
ds_example1 = insert(...See https://forum.dynare.org/t/dseries-insert-doesnt-carry-the-new-index/22386/5
```
clear all
load acetylene.mat
ds_example = dseries(y)
size(ds_example)
ds_nan = dseries(NaN, ds_example.dates, "inserted_Variable")
ds_example1 = insert(ds_example, ds_nan{1}, 1) % we succesfully insert a variable
size(ds_example1) % check what we’ve done
ds_example1{1} % works
ds_example1{end} % doesn’t work (ds_example1{2} and ds_example1{‘Variable_1’} don’t work either)
```
crashes with
> Index exceeds the number of array elements. Index must not exceed 1.
>
> Error in indexing (line 305)
> r.ops = o.ops(idx);
, presumably due to a problem with populating the command history.https://git.dynare.org/Dynare/dseries/-/issues/52Decide whether to support unicode files2022-07-26T15:59:21ZJohannes PfeiferDecide whether to support unicode filesThe unicode file [GMM_data.csv](/uploads/8011ad7b1edbbb4996f72ba452b50231/GMM_data.csv) does not work due to a byte order mark (BOM) at the beginning. We use `importdata`, which assumes we are loading an ASCII file:
```
temp=importdata('...The unicode file [GMM_data.csv](/uploads/8011ad7b1edbbb4996f72ba452b50231/GMM_data.csv) does not work due to a byte order mark (BOM) at the beginning. We use `importdata`, which assumes we are loading an ASCII file:
```
temp=importdata('GMM_data.csv', ',');
double(temp.textdata{1}(1))
```
In contrast, `readtable` correctly detects unicode and drops the BOM:
```
temp2=readtable('GMM_data.csv');
double(temp2.Properties.VariableNames{1}(1))
```https://git.dynare.org/Dynare/dseries/-/issues/50Change behaviour of eq and ne methods2023-12-14T20:02:25ZStéphane Adjemianstepan@adjemian.euChange behaviour of eq and ne methodsIn `dseries` class, to make them consistent with comparison methods introduced in 507ec822 (`lt`, `le`, `gt` and `ge`).In `dseries` class, to make them consistent with comparison methods introduced in 507ec822 (`lt`, `le`, `gt` and `ge`).Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/49Add time aggregation methods consistent with chained indexes2021-07-09T10:07:12ZStéphane Adjemianstepan@adjemian.euAdd time aggregation methods consistent with chained indexes2021-09-10https://git.dynare.org/Dynare/dseries/-/issues/48Add interpolation methods to convert dseries objects to lower frequencies2021-07-15T09:15:23ZStéphane Adjemianstepan@adjemian.euAdd interpolation methods to convert dseries objects to lower frequencieshttps://git.dynare.org/Dynare/dseries/-/issues/46Should not fail when an empty dates object is concatenated with a dates objec...2021-05-13T14:15:31ZHoutan BastaniShould not fail when an empty dates object is concatenated with a dates object with a certain frequecyCurrently this fails:
```
[dates('1y') dates()]
```
I would propose to let it pass, having the resulting output be:
```
ans = <dates: 1Y>
```
@stepan-a what do you think?Currently this fails:
```
[dates('1y') dates()]
```
I would propose to let it pass, having the resulting output be:
```
ans = <dates: 1Y>
```
@stepan-a what do you think?https://git.dynare.org/Dynare/dseries/-/issues/44Integration with DBnomics2020-06-25T09:43:31ZSébastien VillemotIntegration with DBnomicsAllow the construction of series using identifiers or other criteria.
Inspiration could be taken from the API of the [rdbnomics package](https://github.com/dbnomics/rdbnomics).Allow the construction of series using identifiers or other criteria.
Inspiration could be taken from the API of the [rdbnomics package](https://github.com/dbnomics/rdbnomics).https://git.dynare.org/Dynare/dseries/-/issues/43columns() function is missing in dseries2020-03-02T08:52:07ZMichelJuillardcolumns() function is missing in dseriesWhen one attempts to use ``dseries`` standalone without Dynare, one gets the following error:
```
To use 'columns', the following product must be licensed, installed, and enabled:
Database Toolbox
Error in dseries/vobs (line 28)
s = c...When one attempts to use ``dseries`` standalone without Dynare, one gets the following error:
```
To use 'columns', the following product must be licensed, installed, and enabled:
Database Toolbox
Error in dseries/vobs (line 28)
s = columns(o.data);
Error in dseries/display (line 34)
if ~vobs(o)
```
because the columns() function is offered by Dynare in ``missing/rows_columns/columns.m``Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/42Extend dseries constructor for Excel files2021-11-11T13:21:39ZMichelJuillardExtend dseries constructor for Excel filesUsers want to load data from an Excle file by specifying sheet name and rang. I suggest to introduce the following syntax:
```
dseries(FILENAME, OPTION_NAME_1, OPTION_VALUE_1, OPTION_NAME_2, OPTION_VALUE_2,...)
```
The new options would ...Users want to load data from an Excle file by specifying sheet name and rang. I suggest to introduce the following syntax:
```
dseries(FILENAME, OPTION_NAME_1, OPTION_VALUE_1, OPTION_NAME_2, OPTION_VALUE_2,...)
```
The new options would be ``xls_sheet`` and ``xls_range`` as for Dynare ``estimation`` command
It would be good to also introduce option names for the existing options: ``initial_dates``, ``range_of_dates``, ``list_of_names`` (or, better, ``variable_names``), ``tex_names`` (or better ``variable_tex_names``)
and permit the syntax
```
dseries(DATA_MATRIX, OPTION_NAME_1, OPTION_VALUE_1, OPTION_NAME_2, OPTION_VALUE_2,...)
```
Note that we can distinguish between the existing constructors and the new proposed ones as the second argument is a ``date`` in the existing constructor and a ``char array`` or ``string`` in the new onehttps://git.dynare.org/Dynare/dseries/-/issues/41Logic for detection of bitwidth (32 or 64) for x13as binary is incorrect2019-10-03T14:59:33ZSébastien VillemotLogic for detection of bitwidth (32 or 64) for x13as binary is incorrectThe function `src/utilities/is/is64bit.m` is used to decide whether we use a 32-bit or 64-bit binary of x13as.
The logic of this test is doubly wrong.
First, it claims to check whether MATLAB or Octave is 32-bit or 64-bit, but it does ...The function `src/utilities/is/is64bit.m` is used to decide whether we use a 32-bit or 64-bit binary of x13as.
The logic of this test is doubly wrong.
First, it claims to check whether MATLAB or Octave is 32-bit or 64-bit, but it does it by checking the maximum size of matrix indices (there are 64-bit version of Octave which have a 32-bit index).
But, fundamentally, testing the bitwidth of MATLAB/Octave is not what we want, since x13as is an independent executable. We should rather test whether the operating system is 32- or 64-bit, as is currently done for the preprocessor binary.https://git.dynare.org/Dynare/dseries/-/issues/40Incompatibility with MATLAB < R2013b and with Octave2018-12-10T22:42:30ZSébastien VillemotIncompatibility with MATLAB < R2013b and with OctaveThe file `src/@dseries/dseries.m` contains a call to `istable`, which was introduced in MATLAB R2013b (and which does not exist under Octave).The file `src/@dseries/dseries.m` contains a call to `istable`, which was introduced in MATLAB R2013b (and which does not exist under Octave).https://git.dynare.org/Dynare/dseries/-/issues/38Inconsistency in similary actions2018-12-10T23:02:36ZHoutan BastaniInconsistency in similary actionsOriginally reported in #37
The problem code is the following. The first block works without problem, the second fails.
```
zero = dseries(zeros(8,1), '2011q1');
% Modifying all of b (this works)
a = dseries((1:8)', '2011q1');
b...Originally reported in #37
The problem code is the following. The first block works without problem, the second fails.
```
zero = dseries(zeros(8,1), '2011q1');
% Modifying all of b (this works)
a = dseries((1:8)', '2011q1');
b = a;
b = b + 1;
assert(~all(a - b == zero));
% Modifying only part of b (this does not work as it modifies a as well)
a = dseries((1:8)', '2011q1');
b = a;
b(dates('2012q2'):dates('2012q4')) = b(dates('2012q2'):dates('2012q4')) + 1;
assert(~all(a - b == zero), 'a and b should not be equal here');
```
This is a problem because seemingly similar code works inconsistently without the user's knowledge.
I understand there are no good solutions to this: either slow down the code by making copies everywhere, thus returning it to the old, structure-style class setup that Matlab had, or accept to have this bug. We may have to choose an un-ideal option here.....
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dseries/-/issues/39Fix x13 on Octave2018-12-12T13:48:11ZStéphane Adjemianstepan@adjemian.euFix x13 on OctaveThree unit tests are failing because when reading the files produced by the X13 binary. The problem seems to be that the behaviour of `importdata` is different under Octave and Matlab.Three unit tests are failing because when reading the files produced by the X13 binary. The problem seems to be that the behaviour of `importdata` is different under Octave and Matlab.Sébastien VillemotSébastien Villemot