**ras [-f] <matrix> [r <group_exp>] [c <group_exp>] <rowcon> <colcon> [<year>] <r | c> [<count>] [-<tolerance>]**where:

-f|c: specifies the flow (default) or the coefficient mode, ras|psras|rdras: specifies the method of scaling to be used, matrix: is the name of the matrix whose elements are to be balanced, (r rgroup): (c cgroup): are options that determine which rows and columns are included, rowctrl: colctrl: are vectors that contain the row and column totals, yr: optionally specifies the year for which the matrix is to be balanced. If a year is not specified, the matrix is balanced over the period specified by the current *fdates*.r|c: optionally specifies whether the sum of the row totals or the sum of the column totals controls the calculations if the two are not the same. -maxiter: optionally determines maximum number of iterations. The default is 100. -precon: optionally specifies that name of a file containing the preconditions that are to be imposed. -tolerance: optionally specifies the tolerance for the convergence test. The default value is 0.000002. Balance the named matrix by the rAs method so that matrix will have the row sum of <rowcon> and the column sum of <colcon>. It actually does not matter whether <rowcon> and <colcon> are columns or rows, though in the above equation they are to be thought of as columns. If the <year> parameter is missing, the command works over the current

*fdates*range. If the sum of the elements of <colcon> does not equal the sum of the elements of <rowcon>, the vector to govern is specified by the ‘r’ or ‘c’ at the end of the command. The other vector will be scaled to have the right total. The rows will then be scaled to get the correct row totals, then the columns scaled to get the correct column totals. Every five iterations, a report is printed with details on the row and column in which the maximum scaling occurs. When the maximum scale factor differs from 1.0 by less than 0.00002, convergence is declared to have been reached. The last scaling will be of the rows. The <count> parameter at the end determines maximum number of iterations; the default value is 100. The default tolerance is 0.000002, but an alternative may be specified. If convergence does not occur after the maximum number of iterations, the program reports the problem and continues to the next command. Once the balance is achieved, the columns are scaled to sum to 1.0. The reason for this normalizing and how to deal with it if it is not wanted is explained below.The optional arguments [r <group_exp>] and [c <group_exp>] allow you to focus on doing a ras on a submatrix, where <group_exp> is a legal group expression. If you specifiy the ‘r’, the group expression will determine which rows of the matrix are scaled. If you specify the ‘c’, the group expression will determine which columns of the matrix are scaled.

In our experience, the matrices most frequently in need of balancing are the distribution matrices, such as those that determine how personal consumption expenditure by budget category is to be distributed to industries. For this reason, the

*ras*command, after balancing, automatically ensures that the column sums are 1.0. Of course, if the matrix is the intermediate coefficient matrix, one does not want the columns to sum to 1.0. What do we do then? Let us suppose that am is an initial coefficient matrix, q, is the vector of outputs, cs is the vector of column sum controls, and rs is the vector of row sum controls. Then we would do:flow am q coef am cs ras am rs cs r flow am cs coef am q

Note that the scaling algorithm used by the

*ras*command is simple scaling. If the control total is C and the vector is X, then the scaling factor S is applied to each element, as is calculated as:Related Topics:

*Ordinary RAS*,*coef*,*flow*,*psras*,*rdras*

**rdras [-f] <matrix> [r <group_exp>] [c <group_exp>] <rowcon> <colcon> [year] <r | c> [<count>]**This command works identically to the

*ras*command, except in the case where some of the matrix cells are negative. In this case, it performs right-direction scaling on the rows and columns. The essence of right-direction scaling is that both positive and negative numbers are scaled in the same direction. A scaling factor*s*is found such that when multiplying the positive numbers by*s*and dividing the negative numbers by*s*, the numbers add to the correct total. This algorithm also is used when applying group fixes in*Interdyme*.Note that the right-direction scaling is a bit more complicated than the simple scaling technique used by the

*ras*command. Right direction scaling preservers the relative ordering of the elements, and scales them all in the same direction, the “right” direction. Assume that*A*is the sum of all positive elements of the vector*X*,*B*is the sum of all negative elements, and*C*is the control total. The problem is formulated so as to find the number*S*for which the following equation is true:This can be rewritten as the quadratic equation in

*S*:To solve for

*S*, we use the general quadratic formula to obtain:Related Topics:

*Ordinary RAS*,*move*,*psras*,*ras*

This command is used to perform recursive OLS regression. This means that if we have limits ::

limits <date1> <date2> <date3>then the indicated regression will be performed from <date2> to <date3>, then from <date2>-1(the period before <date2>) to <date3>, then from <date2>-2 to <date3>, and so on back to <date1> to <date3>. The regression coefficients are made into time series and stored in the workspace. <b1> is the series for the first regression coefficient; <b2>, for the second; and so on. The regression coefficients are stored in the date corresponding to the first date in their regression. Thus, b1{date1} would be <b1> for the regression over the period <date1> to <date3>. Similarly, the standard errors of the regression coefficients are stored in s1, s2, s3, etc.

If a

zipcommand preceeds therecurcommand, no regressions will be displayed, but thezipcommand will be turned off at the end of therecurcommand, for you surely will want to create graphs after therecurand they cannot be made withzipon.Example:

zip limit 1980.1 1985.1 1991.2 recur gnp$ = g$,v$,fe$,fi$ gdates 1980.1 1985.1 fadd bounds.fad (1 - 5)where BOUNDS.FAD is the file

ti Estimate and 2-Sigma Limits for Coefficient %1 f upper = b%1 + 2*s%1 f lower = b%1 - 2*s%1 gr b%1 upper lower

Both forms of the *r* command regress the dependent variable <y> on the independent variables <x1>, ..., <xn>. The first form automatically supplies a constant term, while the second does not. Independent variables may be expressions, as on the right side of an *f* command. The dependent variable should be a single variable. If the line ends with a ‘,’ then the command continues on the next line.

If lagged values of the dependent variable occur among the explanatory variables, then they will be supplied automatically from previously calculated values when forecasting. Regression coefficients and other values are stored in the “rcoef” variable in the workspace bank.

Related Topics: Ordinary Regression,

catch,mode,punch,recursive

- (ren)ame <old_series_name> <new_series_name>
This command is usually used to rename a series in the workspace bank to another name. For example, it is used in the example on 2SLS to rename to predicted values from the first stage regression which will be used on the right hand side in the second stage regression.

Related Topics: 2SLS, and 3SLS,

*del*

**return [arg]**This command interupts execution of the

*G7*script. If*G7*is in the midst of processing a*do*loop or an*add*file, then the arguments determine the next actions of*G7*. Arguments may be given in upper or lower case. Optional arguments are:OK: The default argument. Exits a *do*loop or*add*file, but processing continues.ESC: Processing halts entirely, but no error messages are shown. ERR: Processing halts entirely, with error messages displayed. Examples:

return ERR

**(rows)cale <matrix> <row> [y|n]**This command is another method to convert flow matrices to coefficients. <matrix> is the name of a matrix whose rows are to be multiplied by the elements of the vector <row>. The last argument indicates whether or not to skip the diagonal elements. The default for this argument is ‘n’. Note that this command is different than the

*flow*command, as each element of the vector multiplies all elements in the corresponding row of the matrix instead of the corresponding column. This command thus could be used to implement across-the-row coefficient change, with the coefficient change indicator vector in <row>. The command takes effect over the current*fdates*.Example:

rowscale am ami y

In this example, am is the A matrix. ami is a vector which indicates the time path of coefficient change and which is equal to 1 in the base year of the A-matrix. In the current example, we specify that the diagonal elements must not be moved.

The format of the *rp123* command is identical to that of the *p123* command. The only difference is that the *rp123* command writes the series to the WK1 file by row. In other words, rows are series, and columns are dates. If you have very many series, with not so many observations (<250), *rp123* is more suitable than *p123*.

**rs create <filename> [<Number_of_Columns> <Maximum_Number_of_Sectors>]**The

*create*function opens the key file and reads in up to 20 columns of aggregation information (6 is the default). An optional argument can be supplied to limit the reading to more or less columns than the default. In principle, the routines handle aggregation or disaggregation between any two of the schemes read from the file. With six aggregation schemes, this results in 36 possible combinations of aggregation.The beginning of a sample file is displayed below:

575 495 360 432 85 BEA82 1 1 1 1 1 10100 Dairy farm products 2 2 2 2 1 10200 poultry and eggs 3 3 3 3 1 10301 Meat animals 4 4 3 3 1 10302 Miscellaneous livestock-horses,bees,ho 5 5 4 4 1 20100 Cotton 6 6 5 5 1 20201 Food grains: wheat,rye,rice,buckwheat 7 7 5 6 1 20202 Feed grains: corn,oats,barley,hay,sorg 8 8 5 6 1 20203 Grass seeds 9 9 6 7 1 20300 Tobacco 10 10 7 8 1 20401 Fruits 11 11 7 8 1 20402 Tree nuts 12 12 7 9 1 20501 Vegetables 13 13 7 10 1 20502 Sugar crops

The purpose of these tools is to provide a convenient way to aggregate and disaggregate data from various sectoral levels. The routine begins by reading a file that contains concordances between various sectoral aggregation schemes. The column heading on the first line must specify the number of sectors in that aggregation scheme. This number of sectors is also the “handle” that is used to refer to that column in the resector routines.

Please see the demo section of the Inforum web site for examples of the

*resector*capabilities.**rs formagg <Number_From> <Number_To>]**This is the first function that should be called after creation. It performs the most important initialization tasks. It sets up all of the information that is needed to aggregate from the scheme indicated as <Number_From> to the scheme indicated as <Number_To>. It sets up concordance lists and “split lists” that will be used by other functions listed below. In some programs, you may need to issue this command several times, especially if you need to use some of the “cross-aggregation” techniques described below.

One of the functions of initialization is to set up lists of correspondences between sectors, as well as lists of splits, where one sector from one scheme corresponds to one or more sectors from the other scheme. Since this initialization is time and memory consuming, an explicit function called

*formagg*performs this task, and this function is called for only needed aggregation relationships.*formagg*takes as its arguments the maximum sector numbers of the source and destination schemes. Until*formagg*has been called with a certain aggregation pair, no other functions using that pair are allowed.**rs aggvector <Number_From> <Number_To> <Input_Vector> <Output_Vector> <Split_Vector>]**- This function is designed to aggregate or split a vector from one aggregation scheme to a vector of another aggregation scheme. <Number_From> should be the number of sectors of the source vector, and <Number_To> should be the number of sectors of the destination vector, as shown in the heading in the key file that was read from the create routine. <Split_Vector> must be of the same aggregation level as the destination vector. It is used by the routine where there is a one-to-many relationship going from source to destination sectors. If you purely are aggregating, the <Split_Vector> will not be used and its values may be set to arbitrary levels.
**rs ctrlvec <Number From> <Number_To> <Detailed Vector> <Aggregate_Vector>**- This function controls a detailed vector to a more aggregate vector.
**rs rdctrlvec <Number_From> <Number_To> <Detailed Vector> <Aggregate_Vector>**- This function controls a detailed vector to a more aggregate vector, using right-direction scaling.

Sometimes conversion of a sectoral scheme is more complicated than merely a combination of aggregations and splits. For example, there may exist a many-to-many relationship, where a <SplitVector> of either sectoring level would not provide enough information on how the flows should be allocated. The name “cross-aggregation” indicates the method of translation used by this function, whereby the source vector is split to the level of a more detailed intermediary vector, which then can be aggregated directly to the destination vector. It must be possible to aggregate the intermediate sectoring level both to the source and to the destination levels for this function to work.

In the argument list, <Number_From> is the number of sectors of the source vector, <Number_To> is the number of sectors of the destination vector, and <Number_In_Between> is the number of sectors of the intermediary vector. <Input_Vector> is the source vector and <Output_Vector> is the destination vector. In this function, <Split_Vector> is a vector of length <<Number_In_Between>> that is used to split the source vector.

This function is similar to *aggvector* but aggregates the <Input_Matrix by row to obtain the <Output_Matrix>. The routine also will accept a packed matrix as the input, though the <Output_Matrix> must be a full matrix.

This function aggregates a matrix both by rows and columns. Earlier editions of the routine required both the source and destination matrix to be square, and the same aggregation mapping was applied to both dimensions. The current routine operates on rectangular matrices, and different aggregation mappings may be applied to the rows and columns.

This function controls a more detailed matrix to an aggregate matrix.

This function controls all cells within a block of the more detailed matrix to a single cell of the less detailed matrix. The function handles all of the different cases: single cell to single cell, row vector to single cell, column vector to single cell, and sub-block to single cell. The function is useful for updating a more detailed matrix such as a benchmark IO table to a more aggregate (and more current) matrix. The routine might work only if the matrix is square.

This function works much like crossaggvector but aggregates rows of a matrix.