Alternative Index Specification

The indexing specification of a collection is a characterization, more generally, of the name space used to identify members of the collection. For example, we might choose to refer to the members of a collection of 4 quads, [Q,``Q``,``Q``,``Q``], using any of the following schemes:

a: 0,1,2,3

b: “Larry”, “Mark”, “Peter”, “Ray”

c: 27, 13, 102, 77

d: 14, 36, 37, 92

e: (0,0), (0,1), (1,0), (1,1)

f: 0x00000000, 0x00000001, 0x00010000, 0x00010001

The a scheme might be considered the “default” or “natural” naming scheme. b is a naming scheme based upon strings. c is a naming scheme based upon some arbitrary integer enumeration. Likewise for d. e is a naming scheme based upon rectangular indexing. f is a naming scheme that might be used in a pyramid of resolution of quads with 16 or fewer layers in which a 32 bit quantity is broken into two 16-bit pieces, one for the row and column of each layer in the pyramid.

Some observations about these naming schemes. In some, a, e and f there is an easily specified rule for generating the names. In the others, the names must be explicitly enumerated. In some, a, b, d, e and f the names are sorted. In some, a, e and f, the names are “compact” meaning that given the names of any two succesive members, there is no name that can be drawn from the same pool from which the other names come that falls between them.

From these observations, we conclude that an indexing spec can be either implicit or explicit. An implicit spec is one in which there is a simple rule for constructing each id in the name space. An explicit indexing spec is one in which each id in the name space must be explicitly specified. In addition, for an explicit spec, we also need to know if the names are sorted (and maybe even how to sort them by virtue of a call-back function to compare names), and if the names are compact.

SAF’s notion of an indexing specification should be evolved to include these notions. Nonetheless, immediate support for user-defined IDs is essential. Therefore, we have provided functions in SAF for a client to specify alternative indexing specifications for a given collection. These functions will permit a SAF client to declare/describe and write/read alternative IDs. However, all relations involving the collection must still be specified in terms of the default indexing. Later, we can enhance the relations interface for SAF to support a client that specifies its relations in terms of these alternative IDs.

Implementation Details

These are details that are probably of no concern to the general user. This info is for someone who cares about the lower levels of SAF and how Alternative Indexing was implemented. The two SAF object data types SAF__IndexSpec and SAF__AltIndexSpec both map to the same SSlib object, namely ss_indexspec_t. Every collection record has a variable length array of links to ss_indexspec_t objects. The first item in that array is the default index spec for that collection. If there are any alternate index specs for a collection, typically there would be only one, since these would be the one way that the client refers to their node ids (or elem ids or face ids, etc).

Members

• saf_declare_alternate_indexspec [Public function]
• saf_describe_alternate_indexspec [Public function]
• saf_find_alternate_indexspecs [Public function]
• saf_read_alternate_indexspec [Public function]
• saf_write_alternate_indexspec [Public function]