dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2022-10-14T10:00:45Zhttps://git.dynare.org/Dynare/dynare/-/issues/1866Fix or document interaction of steady_state_model-block and initval and endval2022-10-14T10:00:45ZJohannes PfeiferFix or document interaction of steady_state_model-block and initval and endval`make_y` translates the contents of `initval` and `endval` to `oo_.endo_simul`. The last block's contents are stored in `oo_.steady_state`. But if there is a `steady_state_model`-block or a `_steadystate`-file, we execute in `make_y`
```...`make_y` translates the contents of `initval` and `endval` to `oo_.endo_simul`. The last block's contents are stored in `oo_.steady_state`. But if there is a `steady_state_model`-block or a `_steadystate`-file, we execute in `make_y`
```
if options_.steadystate_flag
[oo_.steady_state,M_.params,~] = ...
evaluate_steady_state_file(oo_.steady_state,oo_.exo_steady_state,M_, ...
options_,~options_.steadystate.nocheck);
end
```
This part will overwrite the contents of the block by a computed steady state. This behavior has been in Dynare for at least 10 years, but is clearly wrong. @MichelJuillard @stepan-a Do you know what the purpose of that automatic call to the steady state file is?https://git.dynare.org/Dynare/dynare/-/issues/1865Fix x13 on Mac2022-11-16T17:06:56ZJohannes PfeiferFix x13 on MacA user at https://forum.dynare.org/t/x13-seasonal-adjustedment-does-not-work-on-mac/20898 reports an issue with compiling x13, which seems to be due to a conflicting GCC versions. The fix to
> Library not loaded: '/usr/local/opt/gcc/lib/...A user at https://forum.dynare.org/t/x13-seasonal-adjustedment-does-not-work-on-mac/20898 reports an issue with compiling x13, which seems to be due to a conflicting GCC versions. The fix to
> Library not loaded: '/usr/local/opt/gcc/lib/gcc/11/libgfortran.5.dylib'
is most likely to statically link `libgfortran`Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1864SMM: add support for filters like HP-filter.2022-08-23T08:47:32ZJohannes PfeiferSMM: add support for filters like HP-filter.See https://forum.dynare.org/t/smm-dynare-toolbox-with-binomial-draws/20849/3See https://forum.dynare.org/t/smm-dynare-toolbox-with-binomial-draws/20849/3https://git.dynare.org/Dynare/dynare/-/issues/1863Filter out non-convergence in PKF2022-11-17T09:58:19ZJohannes PfeiferFilter out non-convergence in PKFUpon non-convergence, we seem to save the invalid results from the last iteration. See https://forum.dynare.org/t/occbin-estimation-bk-conditions-are-not-satisfied/20721/20Upon non-convergence, we seem to save the invalid results from the last iteration. See https://forum.dynare.org/t/occbin-estimation-bk-conditions-are-not-satisfied/20721/20https://git.dynare.org/Dynare/dynare/-/issues/1862PKF: fix smoother_redux with state_uncertainty2022-07-26T17:57:17ZJohannes PfeiferPKF: fix smoother_redux with state_uncertaintyIn this case, matrix dimensions are not conformable: [NKM.mod](/uploads/f8e167b20fac119e10c371c249a5e18a/NKM.mod)In this case, matrix dimensions are not conformable: [NKM.mod](/uploads/f8e167b20fac119e10c371c249a5e18a/NKM.mod)https://git.dynare.org/Dynare/dynare/-/issues/1861Occbin: correctly set options_.nk2022-08-03T11:59:14ZJohannes PfeiferOccbin: correctly set options_.nkSee the report at https://forum.dynare.org/t/occbin-smoother-fails-after-successful-estimation/20789 which reports a crash with
```
Unable to perform assignment because the size of the left side is 0-by-17-by-0 and the size of the right ...See the report at https://forum.dynare.org/t/occbin-smoother-fails-after-successful-estimation/20789 which reports a crash with
```
Unable to perform assignment because the size of the left side is 0-by-17-by-0 and the size of the right side is 1-by-17-by-2.
Error in DsgeSmoother (line 455)
aaa(:,oo_.dr.restrict_var_list,:)=aK;
Error in occbin.DSGE_smoother (line 120)
[alphahat,etahat,epsilonhat,ahat,SteadyState,trend_coeff,aK,T0,R0,P,PK,decomp,Trend,state_uncertainty,M_,oo_,bayestopt_] = DsgeSmoother(xparam1,gend,Y,data_index,missing_value,M_,oo_,options_,bayestopt_,estim_params_,occbin_options);%
T1=TT;
```
and elaborates
> UPDATE: Part of the issue is that “options_.nk” is unset and is empty, for some reason. Manually setting options_.nk = 1 before running the smoother helps. However, there is still an error because the dimensions of aK are completely wrong - aK is of size (1, 17, 2), when it is expected to be (1, 17, 69) (as I have 68 observations).
>
> UPDATE 2: setting nk>1 fixes the problem. For example, setting nk=2 leads to aK have the dimensions 2 17 70. This seems to be caused by line 436 in “missing_DiffuseKalmanSmootherH3_Z.m”, which generates Occbin output only if nk> 1 (and otherwise does not invoke Occbin correctly).https://git.dynare.org/Dynare/dynare/-/issues/1860Small inconsistency in printing identification results2022-08-23T07:14:16ZWilli Mutschlerwilli@mutschler.euSmall inconsistency in printing identification resultsAt the summer school 2022, during the identification presentation, there was weird behavior and inconsistencies of the printing of identification results in the command window, particularly for prior_mc>1
The mod files are available at h...At the summer school 2022, during the identification presentation, there was weird behavior and inconsistencies of the printing of identification results in the command window, particularly for prior_mc>1
The mod files are available at https://www.dynare.org/summerschool/2022Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1859New interface for dynamic and static files representing the model2023-10-02T15:40:12ZSébastien VillemotNew interface for dynamic and static files representing the modelThe preprocessor currently creates `dynamic` and `static` files for representing the model (forgetting about the `bytecode` case which is sligthly different), which have the following two characteristics:
- the Jacobian matrix that they ...The preprocessor currently creates `dynamic` and `static` files for representing the model (forgetting about the `bytecode` case which is sligthly different), which have the following two characteristics:
- the Jacobian matrix that they return is a dense one
- in the `dynamic` file, the column indices for the dynamic (endogenous) variables are organized so as to avoid columns of zeros; said otherwise, if there are `n` variables, there are less than `3×n` columns (for endogenous) in the dynamic Jacobian. This design decision makes sense since the matrix is dense, but it complicates the computations with the Jacobian matrix.
The proposal is to change the design and have the `dynamic` and the `static` files:
- return a sparse Jacobian
- for the `dynamic` file, use exactly `3×n` columns for the endogenous in the Jacobian (and also for higher order derivatives)
It is expected that having a sparse Jacobian will improve performance, at least for large models.
Since the `static` and `dynamic` files are used at many places in the code, the transition cannot be done overnight, and the idea is to have the old and the new interface coexist for some time. The old interface would be removed at some point (unless it turns out that there is a real use case for dense Jacobians).
The interaction with block decomposition also needs to be taken into account when doing this transition. Currently, when block decomposition is requested, the preprocessor outputs `static` and `dynamic` files that have the same name as in the case without block decomposition, but a different interface. This is bad design. The preprocessor should use different names for those files when using block decomposition. We could even go as far as always providing the two versions of those files (with and without block decomposition), so that the `block` option of the `model` block would no longer affect preprocessor output (but only the algorithms used for computations). An even further step could be to always use block decomposition for perfect foresight, and drop the other code paths (but we probably don’t want to do that for the stochastic case). In particular, this could help with large backward models, for which we only need (dynamic) derivatives with respect to contemporaneous variables, an optimization which is already automatically done when using block decomposition.
Steps:
- [x] Change the preprocessor so that it produces the new `static` and `dynamic` files in parallel to the old ones
- [x] Change the preprocessor so that it always outputs the block decomposed files (with the new interface) in parallel to the non-block decomposed ones? (see also preprocessor#41)
- [x] Start using the new interface in the MATLAB/Octave code
- [ ] Drop the perfect foresight algorithms that do not use block decomposition? (i.e. `block` becomes the default, and only choice, for perfect foresight). This would probably require #1858 to be done first.
- [ ] Drop the old interface (if it is confirmed that dense Jacobians have no real use case)Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1858Use MEX to create stacked Jacobian in two-boundaries blocks with block decomp...2022-09-13T15:50:11ZSébastien VillemotUse MEX to create stacked Jacobian in two-boundaries blocks with block decompositionThe `perfect_foresight_problem` MEX was introduced so as to speed-up the construction of the stacked Jacobian for deterministic problems (when there are both leads and lags).
However, when doing block decomposition, there is no equivale...The `perfect_foresight_problem` MEX was introduced so as to speed-up the construction of the stacked Jacobian for deterministic problems (when there are both leads and lags).
However, when doing block decomposition, there is no equivalent MEX for constructing the stacked Jacobian for two-boundaries blocks. This is an obvious opportunity for optimization.
It remains to be seen how much can be factorized with the existing `perfect_foresight_problem` MEX. The bytecode case may also need special treatment.https://git.dynare.org/Dynare/dynare/-/issues/1857Document data-command or replace it2022-08-10T15:09:00ZJohannes PfeiferDocument data-command or replace itCurrently, to get a `dseries`object loaded into estimation, we use
```
ts = dseries('fsdat_simul.m');
data(series=ts, first_obs=1950Q3, last_obs=2000Q3);
```
(see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/dates/fs2000.mod...Currently, to get a `dseries`object loaded into estimation, we use
```
ts = dseries('fsdat_simul.m');
data(series=ts, first_obs=1950Q3, last_obs=2000Q3);
```
(see https://git.dynare.org/Dynare/dynare/-/blob/master/tests/dates/fs2000.mod). But that `data`-command is not documented as it belongs to the new estimation interface (https://git.dynare.org/Dynare/dynare/-/issues/226). The documentation at https://archives.dynare.org/DynareWiki/NewEstimation seems outdated.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1856Provide an interface to fsolve options, in the context of steady(solve_algo=0)2022-08-23T07:14:15ZSébastien VillemotProvide an interface to fsolve options, in the context of steady(solve_algo=0)`steady(solve_algo=0)` uses `fsolve` to solve the nonlinear system (both on MATLAB and Octave). Only a few of `fsolve` options can be controlled through the Dynare interface (tolerances and maximum number of iterations).
We should provi...`steady(solve_algo=0)` uses `fsolve` to solve the nonlinear system (both on MATLAB and Octave). Only a few of `fsolve` options can be controlled through the Dynare interface (tolerances and maximum number of iterations).
We should provide an interface for more `fsolve` options. One possibility is to implement an interface for selected options (one of our institutional partners needs an interface to `UseParallel`). Another possibility is to implement a generic mechanism, like the already existing `optim` option of `estimation`.6.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1855Occbin: clarify combinations of filters and initializations2022-06-07T13:07:29ZJohannes PfeiferOccbin: clarify combinations of filters and initializationsIt's not clear that the defaults for the normal Kalman filter match Occbin. See e.g. https://forum.dynare.org/t/time-varying-effective-lower-bound/19908/10
In particular, we need to decide on a default for `qz_criterium` and provide an e...It's not clear that the defaults for the normal Kalman filter match Occbin. See e.g. https://forum.dynare.org/t/time-varying-effective-lower-bound/19908/10
In particular, we need to decide on a default for `qz_criterium` and provide an error for non-applicable `kalman_algo` and `lik_init`.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1854Provide error handling to piece-wise linear Kalman filter2022-05-20T08:21:51ZJohannes PfeiferProvide error handling to piece-wise linear Kalman filterFor example, `kalman_update_algo_1` contains
```
[~, out, ss] = occbin.solver(M_,oo_,options_);
if isequal(out.regime_history(1),regimes_(1))
error_flag=0;
break
end
```
There are two issues:
1. `options_.noprint` is not set loca...For example, `kalman_update_algo_1` contains
```
[~, out, ss] = occbin.solver(M_,oo_,options_);
if isequal(out.regime_history(1),regimes_(1))
error_flag=0;
break
end
```
There are two issues:
1. `options_.noprint` is not set locally so that any problem in `occbin.solver` will trigger a hard-error
2. Even if one suppresses the error, the required fields will not be set. `kalman_update_algo_1` always expects a solution.Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1853Incorrect pruning at order 2 with particle filtering2022-05-13T11:20:01ZSébastien VillemotIncorrect pruning at order 2 with particle filteringAn anonymous user noticed that our implementation of pruning at order 2 with particle filtering is probably incorrect. The problem is located in MEX `local_state_space_iteration_2`.
More precisely, when computing next period pruned vari...An anonymous user noticed that our implementation of pruning at order 2 with particle filtering is probably incorrect. The problem is located in MEX `local_state_space_iteration_2`.
More precisely, when computing next period pruned variables, instead of adding the term `+ghxu·ŷ₁⊗ε` (as indicated in the comment), the code actually adds `+ghxu·ŷ₂⊗ε`. See https://git.dynare.org/Dynare/dynare/-/blob/master/mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L118
The paper by Kim et al. (2008), and also our MATLAB/Octave implementation of pruned simulations (in `matlab/simult_.m`), both use `ŷ₁` at that place.
I’d be grateful if someone else could confirm this diagnostic. Cc @stepan-a @JohannesPfeifer @normann6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1852Build failure with g++-12: 'unique_ptr' was not declared in this scope2022-05-02T15:15:20ZFX CoudertBuild failure with g++-12: 'unique_ptr' was not declared in this scopeTrying to build dynare 5.1 from source (with various patches for Octave 7 compatibility), with G++ 12.1.0-RC1 (which will be released in a week) gives the following errors:
```
2022-05-01T00:28:25.3736860Z In file included from ExprNod...Trying to build dynare 5.1 from source (with various patches for Octave 7 compatibility), with G++ 12.1.0-RC1 (which will be released in a week) gives the following errors:
```
2022-05-01T00:28:25.3736860Z In file included from ExprNode.cc:28:
2022-05-01T00:28:25.3737050Z DataTree.hh:120:10: error: 'unique_ptr' was not declared in this scope
2022-05-01T00:28:25.3737150Z 120 | vector<unique_ptr<ExprNode>> node_list;
2022-05-01T00:28:25.3737220Z | ^~~~~~~~~~
2022-05-01T00:28:25.3737510Z DataTree.hh:38:1: note: 'std::unique_ptr' is defined in header '<memory>'; did you forget to '#include <memory>'?
2022-05-01T00:28:25.3737590Z 37 | #include "SubModel.hh"
2022-05-01T00:28:25.3737660Z +++ |+#include <memory>
2022-05-01T00:28:25.3737720Z 38 |
2022-05-01T00:28:25.3737830Z DataTree.hh:120:21: error: template argument 1 is invalid
2022-05-01T00:28:25.3737960Z 120 | vector<unique_ptr<ExprNode>> node_list;
2022-05-01T00:28:25.3738030Z | ^~~~~~~~
2022-05-01T00:28:25.3738140Z DataTree.hh:120:21: error: template argument 2 is invalid
2022-05-01T00:28:25.3738340Z DataTree.hh:120:29: error: expected unqualified-id before '>' token
2022-05-01T00:28:25.3738430Z 120 | vector<unique_ptr<ExprNode>> node_list;
2022-05-01T00:28:25.3738500Z | ^~
2022-05-01T00:28:25.3740470Z DataTree.hh: In member function 'ExprNode* DataTree::AddUnaryOp(UnaryOpcode, expr_t, int, int, int, const std::string&, const std::vector<int>&)':
2022-05-01T00:28:25.3740680Z DataTree.hh:398:13: error: 'make_unique' was not declared in this scope
2022-05-01T00:28:25.3740940Z 398 | auto sp = make_unique<UnaryOpNode>(*this, node_list.size(), op_code, arg, arg_exp_info_set, param1_symb_id, param2_symb_id, adl_param_name, adl_lags);
2022-05-01T00:28:25.3741010Z | ^~~~~~~~~~~
2022-05-01T00:28:25.3741300Z DataTree.hh:398:13: note: 'std::make_unique' is defined in header '<memory>'; did you forget to '#include <memory>'?
2022-05-01T00:28:25.3741500Z DataTree.hh:398:36: error: expected primary-expression before '>' token
2022-05-01T00:28:25.3741720Z 398 | auto sp = make_unique<UnaryOpNode>(*this, node_list.size(), op_code, arg, arg_exp_info_set, param1_symb_id, param2_symb_id, adl_param_name, adl_lags);
2022-05-01T00:28:25.3741790Z | ^
2022-05-01T00:28:25.3741980Z DataTree.hh:398:45: error: 'node_list' was not declared in this scope
2022-05-01T00:28:25.3742180Z 398 | auto sp = make_unique<UnaryOpNode>(*this, node_list.size(), op_code, arg, arg_exp_info_set, param1_symb_id, param2_symb_id, adl_param_name, adl_lags);
2022-05-01T00:28:25.3742320Z | ^~~~~~~~~
2022-05-01T00:28:25.3742610Z DataTree.hh: In member function 'ExprNode* DataTree::AddBinaryOp(expr_t, BinaryOpcode, expr_t, int)':
2022-05-01T00:28:25.3742810Z DataTree.hh:424:13: error: 'make_unique' was not declared in this scope
2022-05-01T00:28:25.3742970Z 424 | auto sp = make_unique<BinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, powerDerivOrder);
2022-05-01T00:28:25.3743040Z | ^~~~~~~~~~~
2022-05-01T00:28:25.3743330Z DataTree.hh:424:13: note: 'std::make_unique' is defined in header '<memory>'; did you forget to '#include <memory>'?
2022-05-01T00:28:25.3743520Z DataTree.hh:424:37: error: expected primary-expression before '>' token
2022-05-01T00:28:25.3743680Z 424 | auto sp = make_unique<BinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, powerDerivOrder);
2022-05-01T00:28:25.3743760Z | ^
2022-05-01T00:28:25.3743950Z DataTree.hh:424:46: error: 'node_list' was not declared in this scope
2022-05-01T00:28:25.3744110Z 424 | auto sp = make_unique<BinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, powerDerivOrder);
2022-05-01T00:28:25.3744190Z | ^~~~~~~~~
2022-05-01T00:28:25.3744490Z DataTree.hh: In member function 'ExprNode* DataTree::AddTrinaryOp(expr_t, TrinaryOpcode, expr_t, expr_t)':
2022-05-01T00:28:25.3744680Z DataTree.hh:451:13: error: 'make_unique' was not declared in this scope
2022-05-01T00:28:25.3744830Z 451 | auto sp = make_unique<TrinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, arg3);
2022-05-01T00:28:25.3744890Z | ^~~~~~~~~~~
2022-05-01T00:28:25.3745170Z DataTree.hh:451:13: note: 'std::make_unique' is defined in header '<memory>'; did you forget to '#include <memory>'?
2022-05-01T00:28:25.3748160Z DataTree.hh:451:38: error: expected primary-expression before '>' token
2022-05-01T00:28:25.3748320Z 451 | auto sp = make_unique<TrinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, arg3);
2022-05-01T00:28:25.3748400Z | ^
2022-05-01T00:28:25.3748640Z DataTree.hh:451:47: error: 'node_list' was not declared in this scope
2022-05-01T00:28:25.3748820Z 451 | auto sp = make_unique<TrinaryOpNode>(*this, node_list.size(), arg1, op_code, arg2, arg3);
2022-05-01T00:28:25.3748910Z | ^~~~~~~~~
```https://git.dynare.org/Dynare/dynare/-/issues/1851Investigate failures of block decomposition when computing steady states2022-08-23T07:14:15ZJohannes PfeiferInvestigate failures of block decomposition when computing steady statesThe file [solve_v8.mod](/uploads/ebfe2f378975dc36bacb9cded885af23/solve_v8.mod) fails computing the terminal steady state with trust region, while it works with `fsolve`. Part of the problem is that `dogleg` returns `NaN` due to `0*Inf`....The file [solve_v8.mod](/uploads/ebfe2f378975dc36bacb9cded885af23/solve_v8.mod) fails computing the terminal steady state with trust region, while it works with `fsolve`. Part of the problem is that `dogleg` returns `NaN` due to `0*Inf`.
[parameter.mat](/uploads/54b16134b65e3a1606bcffb16cfe981a/parameter.mat)
[steadystate.mat](/uploads/52ef9c6f06f434910020d5e5f3a6e0cd/steadystate.mat)
This seems to be caused by blocks computed from the Dulmage-Mendelsohn decomposition having singular Jacobians.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1850Fix perfect_foresight_problem.cc for case without leaded variables2022-05-20T08:21:51ZJohannes PfeiferFix perfect_foresight_problem.cc for case without leaded variablesThe file contains the error message
> mexErrMsgTxt("M_.lead_lag_incidence should be a real dense matrix with 2+M_.maximum_endo_lag rows and M_.endo_nbr columns");
but `M_.lead_lag_incidence` is `1 + M_.maximum_endo_lag +M_.maximum_endo...The file contains the error message
> mexErrMsgTxt("M_.lead_lag_incidence should be a real dense matrix with 2+M_.maximum_endo_lag rows and M_.endo_nbr columns");
but `M_.lead_lag_incidence` is `1 + M_.maximum_endo_lag +M_.maximum_endo_lead`, not `2+M_.maximum_endo_lag`
[test4.mod](/uploads/933fb136ea3b9a64301b60f49d09c067/test4.mod) should trigger the issue.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1849Make default value of mh_jscale dependent on number of estimated parameters2023-09-06T12:38:57ZJohannes PfeiferMake default value of mh_jscale dependent on number of estimated parametersWe currently employ the default `mh_jscale=0.2`. This hardly ever fits as the optimal value is typically decreasing in the number of estimated parameters. I would propose to use the optimal value of Gelman et al. (1995) for the normal s...We currently employ the default `mh_jscale=0.2`. This hardly ever fits as the optimal value is typically decreasing in the number of estimated parameters. I would propose to use the optimal value of Gelman et al. (1995) for the normal symmetric random walk Metropolis-Hastings of `2.38^2/npar` as the default. That would break backward compatibility on files where the default was used, but would employ a more sensible starting value depending on the number of parameters estimated.6.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1848Problems of the example for Occbin mod file2022-03-28T13:51:52Zsongkaihonglalala704156579@qq.comProblems of the example for Occbin mod filein the mod file, the euler equation (or equation 1 with relax), we only assume the investment equation is not binding in the current period, but in your codes it seems assume both current and next period the INEG condition is relaxed. I ...in the mod file, the euler equation (or equation 1 with relax), we only assume the investment equation is not binding in the current period, but in your codes it seems assume both current and next period the INEG condition is relaxed. I think this is a mistake and looking forward to your reply.https://git.dynare.org/Dynare/dynare/-/issues/1847Expand *_calibration to higher order2023-09-27T15:04:53ZJohannes PfeiferExpand *_calibration to higher orderCurrently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/2Currently, we only support first order. See also https://forum.dynare.org/t/gsa-of-irfs-with-a-higher-order-approximation/19758/27.x