Explicitly specify that matrices with a single dimension produce column vectors

[vaitkus]

Multiple data items in the 'cif_core' dictionary are defined as Matrices with a single dimension. This is slightly ambiguous. For example, the _cell.vector_b data item is defined as having the dimension of [3] which can either be interpreted as a column vector (3x1) or a row vector 1x3. The associated dREL evaluation code seems to produce a column vector. Is this the intended interpretation that is true for all matrices with a single dimension?

If it is, I propose to explicitly specify it in the definition of the Dimension data type or/and the definition of the _type.dimension data item (DDL dictionary). Alternatively, dimensions of each of the matrix items could be modified to explicitly have two dimensions ([3,1] instead of [3]).

[jamesrhester]

The dREL language allows Matrices with a single dimension to act as either row or column vectors in matrix operations, whichever interpretation makes the multiplication well-defined. So I believe this behaviour is covered by dREL rather than DDLm.

[vaitkus]

So in case such data item actually appears in a CIF data file, both forms (i.e. [ [1] [2] [3] ] and [ 1 2 3 ]) should be considered valid and equivalent when checking for uniqueness? The uniqueness question is a legitimate one since such data items do appear as keys of several categories (i.e. DIFFRN_ORIENT_REFLN).

Or are these data items more of dREL-only constructs and should normally not appear in CIF data files?

[jamesrhester]

You know, I don't think anybody has ever asked that question. I would say that the first form [ [1] [2] [3] ] is not a "dREL vector" as it is explicitly a column vector, so cannot be used everywhere that a dREL vector can and is therefore not identical. These items will appear in CIF2 files.

[vaitkus]

Great, thank you for the clarification.

Maybe it would be worthwhile including this clarification in the DDLm using one of the previously proposed ways? After all, this deals less with the way these data should be interpreted by a dREL script and more with the way it should be represented in a data instance file (i.e. CIF2).

[jamesrhester]

Fair enough, it can't hurt to provide this information.

[jamesrhester]

1535c99 contains a proposed amendment.

[vaitkus]

Thank you for the change.

So just a final check to see if I understood correctly. In the context of a Matrix data structure:

• [3,1] allows only column vector values;
• [1.3] allows only row vector values;
• [3] allows both the [3,1] and the [1,3] values for the same data item, but the two values are only considered identical if they have the same dimensions and the same elements?

[jamesrhester]

• [3,1] allows only column vector values;

Correct

• [1.3] allows only row vector values;

Correct

• [3] allows both the [3,1] and the [1,3] values for the same data item, but the two values are only considered identical if they have the same dimensions and the same elements?

[3] allows only values of the form [x y z] to appear in the data file.

[vaitkus]

Understood. But I seem to have made a slight mistake in one of my previous posts since a row vector [3,1] would technically be written as [ [ x, y, z ] ] and not as [ x y z ].

Then, the updated list of Matrix-based columns would be:

• [1,3] is a column vector, i.e. [ [ x ] [ y ] [ z ] ];
• [3,1] is a row vector, i.e. [ [ x y z ] ] (emphasis on the nested [ ]);
• [3] is written as a list, i.e. [ x y z ], but in dREL can be used either as a row or a column vector.

If this is correct, maybe the human-readable definition could be changed to put more emphasis on the way the data is recorded (without being CIF2-specific), i.e.:

A matrix with a single dimension takes the form of a regular list,
but can be interpreted either as a row or a column vector.

[jamesrhester]

Does 24f69f0 look better?

[vaitkus]

Thank you for the change, the definitions seem much clearer. One final suggestion -- maybe an additional example of a one dimensional matrix (vector) could be added in the definition of the _type.dimension data item?

[vaitkus]

Resolved by merging PR #47.