At the moment, various integer types are being used in
igraph, ranging from
long int to
igraph_integer_t. This post describes a proposal to clean up the integer types, and in particular, support 64-bit integers properly. This is a quite disruptive breaking change with respect to previous major releases. We therefore want to do this only once, so we want to make sure that we are doing this right. We therefore also solicit feedback from users about this proposal. We plan to do this for release 0.10.
We intend to have four basic (i.e. atomic) data types:
igraph_real_t. This will always be a
double, i.e. a 64-bit floating point number.
igraph_integer_t. This will be an integer type that by default is 64-bit on 64-bit systems and 32-bit on 32-bit systems. It will be configurable to be a 32-bit integer type, even on 64-bit systems, in order to support the R interface, which unfortunately does not support 64-bit integers.
igraph_bool_t. This datatype will represent a boolean. Typically, we can store this in a
chardata type (8-bit). In order to support the R interface, this type is configurable to use a 32-bit integer instead.
igraph_complex_t. This datatype will represent a complex number, consisting of a real part and a complex part, both of which are represented as
In public headers, no other basic data types are allowed. All data types used in
igraph should be defined on the basis of these four basic data types. Internally, it may be necessary to sometimes use other types, for example to interface with external libraries, or to support specific implementations of random number generators. This usage should be limited to what is strictly necessary.
In particular, this means that there should be (nearly) no
long int being used, but only
igraph_integer_t. Similarly, (almost) no
double should be used, only
At the moment there are various array-like data structures that are defined on several basic data types. In particular, these are
stack. We intend to limit these data structures to the four basic data types that are introduced above. For example, for
vector, we would only support the following types:
igraph_vector_real_t, defined as a vector of
igraph_vector_integer_t, defined as a vector of
igraph_vector_bool_t, defined as a vector of
igraph_vector_complex_t, defined as a vector of
In addition, we will have a “default” type:
igraph_vector_twill be identical to an
This default is consistent with the current implementation.
For the other data structures, we would similarly support only the indicated four basic data types, and make the “default” be identical to the data type defined on an
Similarly to the basic data types, in public headers, no other array-like data structures are allowed. All data types used in
igraph should be defined on the basic of these four basic data types. Internally, it may be necessary to sometimes use other types, for example to interface with external libraries. This usage should be limited to what is strictly necessary. Although we may develop some helper data types for this specific purpose, these data types will be strictly private, and only limited to these specific purposes.
In particular, this means that we will remove
igraph_vector_float_t from the library, with of course first a deprecation of these types. Similarly, these types would also be remove for the other array-like data structures.
At the moment, most functions return an
int for signalling an error condition. We will change this so that functions that return an error will return an
igraph_error_t instead, which will be typedef’d to an
int. This does not change the return data type of the functions, but it will clarify the semantics of the function definitions. It also distinguishes it from other functions that do return an actual integer, such as
igraph_vcount, and not an error code.
The R interface only supports
int values. Hence, in order to keep supporting the R interface, we need to make the
igraph_integer_t and the
igraph_bool_t configurable to both be an
int. Since any array-like data structures are defined on the basis of these basic data types, they should automatically change along with it. This should be strictly limited to the R interface only, and should not be used in other settings.
At the moment, the graph is represented using
igraph_vector_t, i.e. using
doubles. At some point, we will change this to work with the integer type, i.e.
igraph_vector_integer_t. This will break much of the existing code, because the interaction with the graph is usually based on handling
This topic is further discussed in various places, starting at Put integer types into order · Issue #1450 · igraph/igraph · GitHub, with some follow up discussions in Fix integer types by vtraag · Pull Request #1626 · igraph/igraph · GitHub, including some more technical details.